PA0002 table — PA0002 Personal Data Infotype Table
PA0002 stores infotype 0002, Personal Data: the employee's name components, date of birth, gender, marital status, nationality and birthplace, one time-sliced record per PERNR per validity period. It is the master source for legal name and biographical data used across payroll, benefits, and statutory reporting, and is read constantly by ESS/MSS and downstream interfaces.
PA0002 holds the personal identity data of an employee record: name, date of birth, gender, marital status and nationality, carried as time-sliced infotype rows. This page covers the fields consultants actually query, the joins into PA0000 and PA0001, and the recurring mistakes made when reading name history or nationality across a transfer or rehire.
Published 15 Sept 2026· 1,030 words
What it stores
Each row in PA0002 is one delimited validity period of infotype 0002 for one personnel number. A single employee normally has several rows over their employment lifetime, each bounded by BEGDA and ENDDA, because any change to a name, marital status, nationality or date of birth creates a new delimited record rather than overwriting the old one. The table therefore carries a full history of who the person legally was at any point in time, not just their current data. It is keyed like every infotype table by PERNR, INFTY, SUBTY, OBJPS, BEGDA, ENDDA and SEQNR, and a change to any personal detail field, even a correction of a misspelled surname, generates a new time slice rather than a field-level update.
Key fields
- PERNR - personnel number, links to PA0000/PA0001 and every other infotype
- INFTY - infotype identifier, constant 0002 for this table
- SUBTY - subtype, generally blank for infotype 0002
- OBJPS, SPRPS - object identifier and lock indicator, standard infotype technical fields
- BEGDA, ENDDA - validity period of this time slice
- SEQNR - sequence number distinguishing parallel records within the same validity period
- NACHN, VORNA - last name and first name
- RUFNM - preferred or nickname used in output correspondence
- GBDAT - date of birth
- GESCH - gender key
- FAMST - marital status key
- NATIO - nationality key, links to the nationality customizing table
- GBORT - place of birth
- AEDTM, UNAME - date of last change and user who made it
How it joins the data model
- PA0002-PERNR = PA0000-PERNR to bring in employment status and action history for the same period
- PA0002-PERNR = PA0001-PERNR to pick up the organizational assignment valid on the same date
- PA0002-PERNR = PA0006-PERNR to combine personal data with address subtype records
- PA0002-PERNR = PA0008-PERNR when personal data changes need to be checked against pay scale or basic pay effective dates
- PA0002-NATIO joins against the nationality entries maintained in table T005 (country customizing), not against T512W or T549Q, which are unrelated to this infotype
How to read it safely
PA0002 is client-dependent, so always restrict on MANDT alongside PERNR. Never select without a PERNR range or a BEGDA/ENDDA window on a productive system; a full scan across all personnel numbers and all time slices returns every historical name and marital status change ever recorded and is one of the more expensive infotype tables to brute-force in a large client. To get the record valid on a specific date, filter BEGDA less than or equal to that date and ENDDA greater than or equal to that date, exactly the pattern used for every other infotype. If SUBTY is populated in a given system due to custom configuration, include it in the key; do not assume it is always blank.
How to prove it in the data
Symptom: payroll output or a statutory form shows the wrong legal name for an employee. Select PA0002 where PERNR equals the employee's number and the pay period end date falls between BEGDA and ENDDA, ordered by BEGDA descending. Compare NACHN and VORNA across the returned time slices against AEDTM and UNAME to see when and by whom the name was last changed, and whether the payroll run date fell inside an older, now-superseded slice.
ECC vs S/4HANA
PA0002 continues to exist as a physical table on S/4HANA on-premise and is read through the standard infotype framework and compatible CDS-based reporting views. In an SAP SuccessFactors Employee Central integrated landscape, PA0002 is typically populated by replication from Employee Central rather than maintained directly in the SAP system, and the authoritative source of personal data moves to Employee Central's own personal information objects; PA0002 then functions as the on-premise payroll-facing mirror.
Common pitfalls
- Reading only the row with the highest BEGDA and assuming it is current: if ENDDA has not been extended to 12/31/9999 due to a delimited termination or a data load error, the 'latest' row may actually be historical, not active.
- Ignoring SEQNR when two records share the same BEGDA and ENDDA: overlapping slices happen after HR data loads or corrections, and picking the wrong SEQNR silently returns stale name data.
- Treating NATIO as a single fixed attribute: nationality is time-sliced exactly like name, and an employee's nationality history can legitimately change after a legal status update, which trips up interfaces built assuming it never varies.
- Confusing marital status (FAMST) changes with actual HR actions: a marital status update in PA0002 does not by itself trigger a personnel action in PA0000, so cross-checking against action type history is necessary before assuming the two are synchronized.
- Assuming a blank RUFNM means no preferred name was ever set, when in fact it may simply not have been maintained for that employee's employment; absence of a value is not evidence of a business decision.
- Correcting a name by directly overwriting BEGDA on an existing record in a support fix rather than delimiting and creating a new slice, which corrupts the history that downstream reporting and legal forms rely on.
Whose problem this is
Personal Administration configuration and infotype screen control for PA0002 sit with the HCM/PA functional consultant. Data correctness for an individual employee's name or nationality is a business process owned by HR administration or the employee self-service change process; in an Employee Central replication scenario, discrepancies are first triaged against the replication log before touching PA0002 directly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/pa0002ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.