PA40 — Personnel Actions Transaction

PA40 does not maintain data itself. It reads the customizing behind the chosen action type and action reason, determines which infotypes must be touched for that event, and then hands control to the same underlying infotype maintenance logic used by PA30, screen by screen, in the sequence configured for that action. This is the structural fact that explains most confusion: an error inside PA40 is almost always an infotype-level error (record already exists, feature returned no value, mandatory field blank) surfacing inside the action wrapper, not a defect in PA40 itself. The action itself is logged as a record in the Actions infotype, giving HR a single date-stamped event that ties together everything that changed in org assignment, basic pay, and personal data at that moment.

PA40 is used whenever a single business event should update multiple infotypes together with one consistent action date and reason: new hire, internal transfer, promotion, leave of absence, rehire, termination. It is reached for instead of PA30 specifically because the action type enforces a sequence and can trigger dependent infotype changes automatically through dynamic actions, something PA30 will not do on its own. In landscapes where SuccessFactors Employee Central is the system of record, hiring and most job changes are initiated there and replicated into the on-premise HCM system, which reduces how often PA40 is used directly for those events; it remains the entry point for actions not covered by the cloud process, and for pure on-premise HCM configurations.

In SE16, open PA0000 filtered on the personnel number and the action date range, and compare the action type and reason field values against what the user reports selecting. Cross-check PA0001 and PA0008 for records with the same begin date to confirm which infotypes actually got a new record versus which were skipped. If an expected infotype has no record for that date, the sequence stopped or the action type customizing does not include that infotype for the employee's grouping, which points back to the action type configuration rather than to PA40 itself.

PA40 is unchanged in its mechanics on S/4HANA; it still resolves the infotype sequence from the same action type customizing and hands off to the same infotype maintenance logic. What changes in practice is the source of the trigger: with Employee Central as the system of record, hire and job change events are initiated in the cloud and replicated into the on-premise system, so PA40 is used less often for those specific events and more for actions the cloud integration does not cover. There is no Fiori app that replaces PA40 one-to-one on the on-premise side.

This is functional HCM PA and OM territory. Action type configuration, infotype sequences, and dynamic actions belong to the PA consultant; Basis has no role unless a transport or authorization object is missing. ABAP is involved only if a custom user-exit or enhancement runs during the action. A good handover includes the personnel number, the exact action type and reason selected, the action date, and the specific infotype screen where the sequence stopped or produced the wrong result.

PA30 is the natural next read since PA40 delegates to the same infotype maintenance screens without the action wrapper, useful for understanding what PA40 is really doing underneath. PA20 is the display equivalent for verifying what a completed action actually wrote. PO13 matters when an action changes organizational assignment, since it maintains the position and org object side of the same event. PA03 is worth checking when an action is rejected for a period already locked by the payroll control record.