PA0000 table — PA0000 Actions Infotype Table

One row represents a single personnel action recorded against one employee for one validity period - hiring, organizational reassignment, leave of absence, retirement, or termination. Each action carries an action type and reason and drives the employee's active or inactive status. Every time a change action is executed on the personnel action transaction, a new row is delimited into history; the table therefore never holds a single current record only, it holds the whole action history for the personnel number, with the previous row delimited to end the day before the new start date. This audit trail lets consultants reconstruct the full employment lifecycle of an employee, every entry, re-entry and exit event, and is the reference point that Payroll, Time Management and Benefits all read to decide whether an employee is even eligible for processing in a given period.

Always restrict by client and personnel number first; PA0000 without a PERNR range or an organizational filter pulled from PA0001 is too wide to select directly against in most systems. Validity is carried by BEGDA and ENDDA, so any read needs a key date and a filter of BEGDA less than or equal to that date and ENDDA greater than or equal to it, unless the intent is explicitly to pull the whole history. SEQNR is not optional; two rows can share the same BEGDA and only the sequence number tells which action was entered later that day. Never treat ENDDA = 12/31/9999 alone as proof of active status, because a withdrawn or terminated personnel number still carries an open-ended last row, and only STAT2 confirms whether that row means active or left.

For an employee reported as still receiving pay despite a termination entered last month, select PA0000 for that personnel number ordered by BEGDA descending and take the row with the latest start date. Check STAT2 and MASSN on that row. If STAT2 carries the inactive or withdrawn code and MASSN matches the termination action type, the action is recorded correctly in Personnel Administration and the payroll issue sits downstream, in the payroll status or control record, not in this table.

PA0000 is unchanged in table structure on S/4HANA on-premise and in Employee Central Payroll; the classic infotype framework and the personnel action transaction still write it directly. CDS-based compatibility views exist over the infotype tables for reporting purposes, but the underlying table and its keys did not move. In a pure Employee Central deployment, actions are modeled differently, as Job Information and Employment Details records, and PA0000 rows only appear in a replicated back-end, such as Employee Central Payroll, where integration replication generates the equivalent action record from the Employee Central event.

The Personnel Administration functional consultant owns action type and reason configuration and troubleshoots sequencing problems in the action framework. HR Operations or Employee Services owns the actual data entry and correction of wrong actions. The Payroll consultant is the escalation point when STAT2 disagrees with payroll processing. In a SuccessFactors landscape, the integration consultant owns mismatches between the Employee Central event and the replicated PA0000 record.

Neighbouring infotypes delimited alongside an action include PA0001 (organizational assignment), PA0002 (personal data), PA0007 (planned working time) and PA0008 (basic pay, typically updated on hire or rehire). TEVEN captures dynamic events triggered by the action type. The primary writer is the personnel action transaction; direct infotype maintenance can update PA0000 in exceptional cases outside the action framework, which is itself a common source of the inconsistencies described above.