PO13 — Maintain Position (Single Object) in OM
PO13 is the single-object maintenance transaction for Position (object type S) in SAP Organizational Management. It lets a consultant create or change one position's infotypes directly, without going through the org-chart-style PPOME interface. In SuccessFactors Employee Central integration scenarios it is mainly used to inspect or patch position data on the ECC/S4 side, since EC is usually the system of record.
This page covers PO13, the OM transaction for maintaining a single Position object and its infotypes, and explains where the transaction fits when position data is also being replicated from SuccessFactors Employee Central. It focuses on the relationship and integration pitfalls that actually cause tickets rather than the screen layout.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,049 words
Purpose
PO13 maintains infotypes for a single Position object (object type S) in Organizational Management: object infotype 1000 (name, validity), relationships infotype 1001 (reports to, belongs to org unit, held by, based on job), and any position-specific infotypes like vacancy (1007) or account assignment (1008). The structural fact that explains most confusion is that a position is not a person record and not a job record. It is a node in the OM object hierarchy that sits between the org unit and the employee, and its data only becomes visible in Personnel Administration if the integration switch between OM and PA is active and the employee's infotype 0001 points at that position number.
When it is used
PO13 is reached for when a specific position needs a targeted fix: a wrong reporting line, a vacancy flag that does not match reality, a cost center assignment error, or a position that needs to be end-dated or delimited. For building or restructuring whole org units, most consultants use the graphical org chart transaction instead, since PO13 only handles one object at a time and cannot show the surrounding hierarchy. In a SuccessFactors Employee Central landscape, PO13 is used less for creation and more for verification: confirming what actually landed on the OM side after a position was created or changed in EC and replicated inbound, or for emergency correction when replication has failed or been paused.
How to use it in practice
- Enter the position number directly if known, or use the search help to find it by short text, org unit, or job
- Set the validity period for the change (start date matters more here than in most transactions, since OM works with delimited time slices)
- Select the infotype to maintain: 1000 for the position's own data, 1001 for relationships (org unit, job, holder, chief)
- Choose the relationship subtype (A003/B003 for org unit, A007/B007 for job, A008/B008 for holder) when working with infotype 1001
- Save, and check the resulting overlap or gap in validity periods before moving to the next infotype
Key data objects
- HRP1000 - object header data for the position: short text, long text, plan version, validity
- HRP1001 - all relationships from the position to org unit, job, cost center, holder, and chief position, each row tied to a subtype and validity period
- HRP1007 - vacancy status of the position
- HRP1008 - account assignment features inherited from the org unit unless overridden at position level
- T528B / T528T - job and position texts referenced when displaying descriptions, not written by PO13 itself
How to prove it in the data
Pull HRP1001 for the position number and plan version, filtered on relationship subtype and on the validity dates in question, to see exactly which org unit, job, and holder are attached and for what period. Cross-check against HRP1000 for the same object ID and plan version to confirm the position itself is not delimited or missing in that period. If the symptom is that a position change is not reaching Personnel Administration, compare the position number stored in the employee's infotype 0001 record against the position number and validity in HRP1001 subtype B008 (holder) for the same date.
ECC vs S/4HANA
PO13 behaves the same on ECC and S/4HANA; the underlying OM data model and infotype logic have not changed. What changes in a SuccessFactors Employee Central scenario is the role of the transaction: EC becomes the authoritative source for position data, and PO13 on the S/4 side is used for troubleshooting and read access rather than primary maintenance. There is no dedicated Fiori app that replaces PO13 for single-position infotype maintenance; org structure Fiori apps generally work at the org-unit or hierarchy level instead.
Common pitfalls and how to diagnose them
- Missing or broken relationships: a position with no A003/B003 row has no org unit and disappears from the org chart even though the object itself exists in HRP1000. Check HRP1001 for the org unit relationship before assuming the position was never created.
- Vacancy flag out of sync: infotype 1007 can say vacant while a holder relationship still exists in HRP1001, or vice versa, usually after an employee transfer that updated PA but was not reflected back into OM. Check both together, not just the vacancy indicator alone.
- Validity gaps and overlaps: changing a relationship with the wrong start date creates a gap where the position has no org unit or no job for a few days, which then breaks payroll or reporting for that window. Always check the delimited row immediately before the new one.
- Integration switch not active: changes made in PO13 do not appear on the employee's infotype 0001 if the PLOGI ORGA integration switch is off, leading to the false conclusion that the transaction did not save. Confirm the switch setting before chasing a phantom save failure.
- SuccessFactors replication conflict: in EC-integrated landscapes, a manual PO13 change can be silently overwritten by the next inbound replication run, or can itself block replication if it conflicts with the EC record. Check the integration monitoring on the middleware side before treating PO13 as the correct system of record.
Whose problem this is
This is a functional HCM/OM ticket, specifically for whoever owns Organizational Management and the integration with SuccessFactors Employee Central. A good handover states the position number, plan version, the exact infotype and subtype affected, the validity dates involved, and whether the discrepancy was found before or after the last EC replication run.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/po13ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.