PA0001 table — PA0001 Organizational Assignment Infotype Table

One row represents a single validity-delimited organizational assignment for one employee: which position and job they hold, which organizational unit they belong to, which cost center is charged, which company code, personnel area and subarea, employee group and subgroup apply, and which personnel, time and payroll administrators are responsible, all valid for a specific BEGDA to ENDDA window. An employee normally has several rows over their employment history, created whenever a personnel action or a direct infotype change delimits the previous record and opens a new one. Unlike infotype 0000 (Actions), which records why a change happened, PA0001 records what the resulting structural position looked like. It is read constantly by payroll, reporting and authorization checks because structural authorizations and cost assignment both hang off it.

PA0001 is client-dependent, so MANDT is implicit in every selection through the client field, never open it across clients directly. Always restrict by PERNR and by a date, either a single key date against BEGDA/ENDDA or an explicit range, before pulling anything at volume: an unrestricted select across a large workforce with years of history returns one row per delimitation event per employee, not one row per employee. STAT2 or the employment status stored on infotype 0000 is not on this table, so do not try to filter active employees from PA0001 alone; join PA0000 or use the standard read logic. Subtype is almost always blank for standard organizational assignment, so filtering on SUBTY is rarely needed and can silently exclude rows if it is set incorrectly.

Symptom: an employee's payroll run picked up the wrong cost center. Select PA0001 by PERNR for a date range spanning the payroll period in question, ordered by BEGDA, and look at KOSTL and the validity boundaries. If a record was delimited mid-period, or the wrong ORGEH/PLANS/KOSTL combination is active on the payroll's own key date rather than the date the change was intended to take effect, that record is the source, not a payroll configuration issue.

PA0001 continues to exist unchanged in its classic infotype 0001 form in S/4HANA on-premise HCM; it was not replaced by a new table, and compatibility CDS views exist for reporting on top of it rather than instead of it. Where Employee Central is the system of record and this is integrated into an on-premise payroll or a side-by-side scenario, PA0001 is typically populated by replication rather than direct PA30 maintenance, and the authoritative organizational assignment lives in Employee Central's own job information object, with PA0001 acting as a target structure kept in sync by an integration job.

In a classic on-premise setup, the PA/OM functional consultant and the local HR administrator own the data on PA0001, maintained through PA30 or personnel actions. Where Employee Central is the source, the EC functional consultant owns the master data and the integration consultant owns the mapping and timing of replication into PA0001; discrepancies should be chased upstream to EC before anyone touches the ECC/S4 side.

PA0000 (Actions) drives most PA0001 changes and explains why a record was delimited. PA0002 (Personal Data) and PA0008 (Basic Pay) share the same PERNR and validity pattern and are the tables most often joined alongside it. HRP1000 and HRP1001 hold the organizational structure and relationships that PLANS, ORGEH and STELL point into. Written and read through PA30, PA20, PA40 and, for the organizational structure side, PPOME; in EC-integrated landscapes it is also written by the replication or middleware job rather than by a transaction at all.