PO10 — Organizational Unit Maintenance in OM

PO10 maintains one org unit at a time through the classic infotype list, the same underlying mechanism used by PP01 for any OM object type but pre-filtered to object type O (org unit). It lets a consultant create, change, copy or delimit records for infotype 1000 (Object), 1001 (Relationships), 1002 (Description), 1008 (Account Assignment) and others. The structural fact that explains most of the confusion around it: PO10 is not aware of the surrounding org structure the way PPOME is. It shows and edits the selected org unit's own infotype records only, so a change here that affects a relationship to another object (a reporting line, a cost center assignment) has to be made consistently on both sides or the hierarchy becomes inconsistent without any error being raised.

PO10 sits in the Organizational Management part of the HR master data process, alongside PO13 for positions and PP01 for any other object type. Consultants reach for it when a single infotype record needs a targeted correction, for example fixing a wrong description or a mis-dated 1000 record, without opening the full graphical hierarchy in PPOME. It is also the transaction of choice behind batch input recordings and LSMW loads for org unit creation because its screen sequence is simple and stable. Once integration with SuccessFactors Employee Central is in place, PO10 is used mainly for inspection and emergency correction rather than as the primary maintenance path, since the org structure is normally owned and edited upstream in Employee Central and replicated down.

Start with SE16 on HRP1000, filter OTYPE equal O, OBJID equal the org unit number, and PLVAR equal the plan version in question (normally 01 for active). Check for overlapping BEGDA and ENDDA ranges, which indicate two active records fighting over the same period. Cross-check HRP1001 with the same OTYPE and OBJID to see relationship records, filtering on RSTAT for status and SCLAS or SOBID for the related object, to confirm whether a reporting line or cost center link was actually saved or left dangling on one side.

PO10 is unchanged on S/4HANA on-premise; the underlying HRP tables and infotype logic carry over as-is. PPOME remains the primary day-to-day interface for org structure work, and PO10 stays available for single-object correction and batch loads exactly as in ECC. In an HCM for S/4HANA or SuccessFactors hybrid landscape, the practical change is not to the transaction itself but to who owns the data: if the org structure is replicated from Employee Central, PO10 is best treated as a read and verify tool rather than the primary edit path.

Functional OM/PA consultant territory for normal maintenance and troubleshooting. Escalate to the integration consultant when the org structure is fed from SuccessFactors Employee Central and a PO10 change disappears after replication. ABAP involvement is rare and limited to custom logic in the replication path. A good handover includes the org unit ID, plan version, the infotype and period affected, and whether the system is receiving replicated org data.

PO13 is the direct analog for positions and is worth reviewing alongside PO10 since relationship errors usually involve both object types together. PP01 is the generic infotype maintenance transaction underneath both, useful when the object type needed is neither org unit nor position. PA20 and PA30 show the employee side of the assignment, useful for confirming whether an org unit change actually reached the personnel administration record through the integration switch.