PA20 — Display HR Master Data

PA20 displays infotype records for a single personnel number in read-only mode. It shares the exact same screen layout as PA30, the maintenance transaction - same infotype list, same subtype logic, same validity period fields at the bottom. The one structural fact that explains most confusion is that PA20 has no save, insert, delimit or copy function, even though the screen looks identical to PA30 and sometimes retains the same pushbuttons visually. Consultants new to HCM frequently click 'Edit' expecting something to happen, or assume PA20 is a lighter version of PA30 that skips authorization checks. It is not; it reads the same infotype tables through the same access layer, so anything blocking a record in PA30 blocks it in PA20 too.

PA20 is the first stop when investigating a payroll, time evaluation or organizational assignment discrepancy, because it shows exactly what is stored in the infotype tables for a given date without risking an accidental change. Consultants reach for PA20 to confirm what values were active on a specific key date before opening an incident, to check history after a retroactive correction, or to verify that an Employee Central integration replicated the correct value into the OP/S4 backend. For end users, the equivalent read-only need is normally covered by an employee self-service Fiori tile or the Employee Central UI itself; PA20 stays a backend consultant tool once self-service or SuccessFactors becomes the system of record for that data.

Confirming a PA20 discrepancy means comparing what the transaction shows against the raw infotype table. Open SE16N or a query tool on the relevant infotype table, for example PA0008 for pay, filter on PERNR and the BEGDA/ENDDA range that brackets the key date used in PA20, and check for overlapping or gapped records. PA20 only shows the record whose validity spans the selected key date, so a gap or overlap in BEGDA/ENDDA explains a 'record not found' or 'wrong value' complaint. Cross-check the subtype field if the infotype carries subtypes.

PA20 exists unchanged on S/4HANA for on-premise HCM; there is no structural difference in how the transaction reads infotype data compared to ECC. Where Employee Central is the system of record, PA20 remains a backend read tool against the infotypes replicated into the OP or S/4 system, while the actual master data is maintained in the SuccessFactors user interface. A comparable read-only view exists through employee-facing Fiori apps, but those typically cover a narrower set of infotypes than PA20's full technical list.

PA20 issues are functional HR territory in almost every case, since the transaction does not write data and rarely breaks technically on its own. Basis involvement is usually limited to authorization role fixes. A good handover states the personnel number, the infotype and subtype checked, the key date used, and whether the check was rerun with the 'All' period selection, so the functional owner is not repeating the same diagnostic steps.

PA30 is the natural next stop, since it is the maintenance counterpart to PA20 and shares its screen logic; most PA20 findings lead directly into a PA30 correction. PA40 explains how new infotype records get created through personnel actions rather than manual entry. PA51 covers the same read-only need across many personnel numbers or a longer period at once, useful once a PA20 finding looks like it might be systemic rather than isolated. PC00 payroll processing consumes the same infotype tables PA20 displays, which is why payroll discrepancies so often start with a PA20 check on the affected personnel number.