Acumatica Employee Screen — A Deep Dive

Employees (EP203000) shares the same layered-identity pattern as Customer and Vendor: an employee is a BAccount at its core, extended by EPEmployee for HR-specific fields, and typically linked to both a Contact record and, if the person logs into Acumatica, a User account. Four related-but-distinct records — BAccount, Contact, User, EPEmployee — sit behind what looks like one screen, and confusing any two of them is the most common mistake in employee-related customizations.

Four records, one person

BAccount carries the shared identity fields also used by Customers and Vendors. Contact carries name/email/phone in the shape CRM expects. User is only present if the employee has system login access — an employee can exist without a User record (a warehouse worker with no Acumatica login, for instance). EPEmployee layers on HR-specific fields: position, department, and financial settings used when the employee submits expense reports through AP-adjacent screens.

Key tabs

• General Info — identity fields shared with the BAccount/Contact layer.
• Financial Settings — the AP-relevant settings used when this employee is reimbursed for expenses, effectively making the employee a lightweight vendor for that purpose.
• HR Info — position, employment type, and organizational assignment (department, branch).
• Attributes — free-form classification, often extended for skills or certifications tracking in custom implementations.

Extending the graph

A common customization is syncing position or department changes to other modules that key off employee assignment — a Project Task's assigned resource, for instance, or a custom approval map that routes based on department. Because the User and EPEmployee records are related but separately maintained, a graph extension that needs to react to "this employee's role changed" usually has to watch both, depending on which side of the customization triggered the change.

public class EmployeeMaint_Extension : PXGraphExtension<EmployeeMaint>
{
    protected virtual void EPEmployee_RowUpdated(PXCache cache, PXRowUpdatedEventArgs e)
    {
        var row = (EPEmployee)e.Row;
        var old = (EPEmployee)e.OldRow;
        if (row?.DepartmentID != old?.DepartmentID)
            NotifyDepartmentChange(row.BAccountID, old?.DepartmentID, row.DepartmentID);
    }
}

Custom fields and tabs via the Customization Project Editor

Adding a field to HR Info is a standard DAC extension on EPEmployee. As with Customer, deciding whether a new field belongs on the BAccount layer or the EPEmployee layer matters if the field is really about the person's identity (shared with Contact) versus specifically about their employment (HR-only) — get this wrong and the field either doesn't show up where expected or leaks into unrelated BAccount-based screens.

Common validation and event-handler use cases

Beyond department-change notifications: enforcing that Financial Settings are complete before an employee can submit an expense claim, restricting position assignment to values valid for the employee's branch, and validating that terminating an employee (status change) cascades to disabling their User account rather than leaving an active login for a departed employee — a gap that's easy to miss if HR and IT processes aren't tightly linked.

Gotchas

Deactivating the User record doesn't automatically change the EPEmployee's HR status, and vice versa — the two need to be kept in sync deliberately if a customization depends on either signal alone meaning "this person is gone." Financial Settings default from an Employee Class much like Customer/Vendor classes, with the same one-time-inheritance caveat. And because EPEmployee reuses BAccount, any restriction group or security feature applied at the BAccount level applies here too, which occasionally surprises teams that expect employee records to be governed purely by role-based security.

Wrapping up

The Employee screen's real complexity is in how many related records back it — BAccount, Contact, User, and EPEmployee all need to be considered together for anything beyond a simple field addition. Customizations that only look at EPEmployee will miss half the picture the moment access or identity is involved.