HRP1001 table — HRP1001 Organizational Management Relationships Table
HRP1001 stores the relationships between Organizational Management objects in SAP HCM: reporting lines, position-to-org-unit assignments, position holders, job classifications and cost center assignments. Each row is one relationship instance between two objects, valid for a date range. It is the table behind org charts, staffing reports and authorization checks, and is either the source of truth or a replica depending on whether Employee Central owns organizational data.
This page covers HRP1001, the relationships table underneath every SAP Organizational Management structure. It focuses on how relationship type and time constraint govern what a row actually means, and on the join logic and overlapping-record pitfalls that trip up consultants pulling org data for reporting.
Published 15 Sept 2026· 1,030 words
What it stores
One row in HRP1001 represents a single relationship between two Organizational Management objects, valid for a specific time period. Objects are things like org units, positions, jobs, persons, cost centers and work centers, each identified by an object type and object ID in HRP1000. A row does not describe an object itself, that is HRP1000's job, it describes the link between two objects, for example a position reporting to an org unit, a position being held by a person, or a position being classified by a job. Every structural fact in OM, the org chart, the staffing list, the reporting hierarchy, is reconstructed by reading chains of HRP1001 rows and following the object IDs into HRP1000 and into Personnel Administration infotypes for the person side.
Key fields
- OTYPE - object type of the source object (O org unit, S position, P person, C job, K cost center)
- OBJID - object ID of the source object
- PLVAR - organizational plan version, almost always '01' in productive use
- RSIGN - relationship direction sign, A or B, indicating which side of the relationship this row describes
- RELAT - relationship type code (e.g. reports to, belongs to, holder, describes)
- SCLAS - object type of the related object on the other end of the relationship
- SOBID - object ID of the related object
- BEGDA / ENDDA - validity start and end date of the relationship
- ISTAT - status of the record (planned, active, submitted, approved)
- PRIOX - priority, used when more than one relationship of the same type can be active
- SEQNR - sequence number distinguishing multiple rows for the same key combination
How it joins the data model
- HRP1001-OBJID = HRP1000-OBJID (with matching OTYPE and PLVAR) to resolve the source object's description
- HRP1001-SOBID = HRP1000-OBJID (with matching SCLAS and PLVAR) to resolve the related object's description
- HRP1001-SOBID = PA0001-PLANS when RELAT is the holder relationship, to trace a position back to its personnel number
- PA0001-PERNR = PA0000-PERNR and PA0002-PERNR to bring in employment status and name once the person is identified
- HRP1000-OBJID = HRP1001-OBJID chained recursively to walk the org unit hierarchy up or down
How to read it safely
HRP1001 is client-dependent and grows fast because every reorganization, reporting-line change and position reassignment writes a new time-sliced row rather than overwriting the old one. Never select without restricting PLVAR to the live plan version, without that filter simulation and what-if plan versions come back mixed in with production data. Always restrict on a BEGDA/ENDDA window or a single key date, an unrestricted date range returns every historical version of the same relationship. Filter RELAT to the specific relationship type being investigated, the table mixes reporting lines, holder assignments, cost center distributions and job classifications in the same structure, and OTYPE plus SCLAS narrow the object types on each side before joining out to HRP1000.
How to prove it in the data
To confirm who currently holds a position, select HRP1001 for OTYPE S, OBJID equal to the position, PLVAR '01', RELAT for the holder relationship, ISTAT active, and a key date falling inside BEGDA/ENDDA, then read SOBID as the personnel number and cross-check it exists and is active in PA0000 and PA0001 for that same date. If SOBID is blank or the row's ENDDA has already passed, the position is currently vacant regardless of what any downstream report shows.
ECC vs S/4HANA
HRP1001 is unchanged in structure and behaviour on S/4HANA on-premise for customers running classic Organizational Management. Where SuccessFactors Employee Central is the system of record for org structures, position and reporting-line data is maintained in Employee Central and replicated into S/4 through standard master data integration, so HRP1001 in the S/4 system becomes a downstream replica rather than the point of entry, and discrepancies are usually integration lag or mapping issues rather than table-level problems.
Common pitfalls
- Forgetting PLVAR and pulling rows from a simulation or what-if plan version alongside the active plan, producing an org chart that does not match reality
- Treating every row as currently valid because the query ignores BEGDA/ENDDA, when the table keeps full history and a position can have five superseded reporting lines stacked up
- Confusing RSIGN direction, reading a B-side row as if it were the A-side relationship reverses who reports to whom
- Assuming exactly one holder relationship exists per position, some relationship types allow multiple concurrent holders (job sharing, interim coverage) and a query that expects a single row silently drops or duplicates people
- Ignoring ISTAT and including planned or submitted records in a productive headcount or reporting-line report, inflating counts with structures that were never approved
- Reading a vacant position as filled because a holder relationship exists with an ENDDA in the past that the query did not filter out
- Trying to derive the full org hierarchy in a single flat join instead of recursively walking OTYPE O to OTYPE O relationships, which produces wrong parent-child pairs at any level beyond the first
Whose problem this is
The OM functional consultant or HR master data team owns questions about relationship types, time constraints and structural configuration. When Employee Central is the source, the integration team owns replication timing and mapping disputes, and the SuccessFactors OM configuration is the actual point of correction, not the S/4 table.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/hrp1001ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.