PA51 — Display HR Master Data as a Time-Based List

PA51 displays the history of one infotype (and optionally one subtype) for a personnel number as a table, one row per validity period, rather than the single-record card view used by PA20. The structural fact that explains most confusion: PA51 is a read-only reporting view built on the same infotype tables as PA20 and PA30, so it never creates a delimitation or a new record itself. Consultants expect PA20-style prev/next record buttons and instead get a grid where each row is a time slice. Because it is time-based, an infotype with only one current record and no history will show a one-row list that looks identical in content to what PA20 shows, which sometimes leads people to assume PA51 is broken when it is simply working as designed on sparse data.

PA51 is reached for when the question is not 'what is the current value' but 'how has this field changed over time and when'. Typical uses: checking the full history of pay changes on infotype 0008, verifying every organizational reassignment on infotype 0001, or confirming that a chain of time constraint 1 records has no gaps or overlaps. It sits downstream of PA30 and PA40 in the process, used purely for audit and troubleshooting after data has already been entered through an action or direct maintenance. On S/4HANA with SuccessFactors as the system of record, the equivalent history check is usually done in the SuccessFactors UI or through replication monitoring rather than PA51, but PA51 remains the fastest way to see raw infotype history on the ECC or on-premise HCM side.

To confirm what PA51 is showing, go to SE16 or SE16N on the specific infotype table (for example PA0008 for basic pay), filter on PERNR for the employee and, if relevant, SUBTY for the subtype. Sort by BEGDA ascending and inspect ENDDA on each row: a gap exists if one row's ENDDA plus one day does not equal the next row's BEGDA, and an overlap exists if ranges intersect. This is exactly the data PA51 renders as a list, so any discrepancy between the SE16 result and the PA51 screen points to an authorization or period-selection filter rather than a data problem.

PA51 exists on S/4HANA on-premise in essentially the same form as ECC; the transaction and its list-based display logic have not been redesigned. Where SuccessFactors Employee Central is the system of record, infotype data in the on-premise HCM system is largely replicated rather than directly maintained, so PA51 there is mainly a replication-verification tool rather than the primary source of truth. There is no dedicated Fiori app that replaces PA51's specific list-by-period view; equivalent history review in a cloud-first landscape happens in the SuccessFactors interface itself.

This is a functional HCM issue, owned by the HR master data or time administration team, not Basis or ABAP, unless the underlying infotype table shows corruption inconsistent with any user action. A good handover includes the personnel number, infotype and subtype involved, the exact date range entered on the PA51 selection screen, and a screenshot or export of the SE16 result on the raw table for comparison.

PA20 is the natural companion, showing the same infotype data one record at a time and is where most consultants first look before switching to PA51 for the full history view. PA30 is where any correction found through PA51 actually gets made. PA40 is relevant when the gap or overlap traces back to a personnel action that delimited a record incorrectly. PA61 is worth checking when the infotype in question is time management related, since time data has its own constraint rules layered on top of the general infotype framework.