PRHI table — WBS Hierarchy Pointer Table

One row in PRHI represents a single node's position in the internal tree structure of a project - typically a WBS element, including the top-level node that corresponds to the project definition. The row does not describe what the WBS element is or does; that content lives in PRPS (WBS element master data) and PROJ (project definition). PRHI exists purely as a performance and navigation structure: it records the hierarchy level of the node and its relationship to the node directly above it and to neighbouring nodes at the same level, so that hierarchy-aware processing (structure display, structure reports, mass processing by level) does not need to reconstruct the tree from PRPS's level indicator each time it runs. It is written and maintained automatically whenever a project structure is created, changed, or reorganized through standard project maintenance transactions such as the project builder. No one maintains it by hand in a healthy system, and no functional process is designed to update it directly.

Always restrict by MANDT first. PSPNR alone is not a useful restriction because it is an internal number shared across every project in the client and gives no indication of which project a given value belongs to. The safe pattern is to resolve the project definition's internal number from PROJ by its external project ID, pull the member WBS elements from PRPS where the parent-project field matches that internal number, and only then use that specific set of PSPNR values to filter PRHI. Querying PRHI without first scoping to a known project or WBS element set means scanning a table that grows with every project and every restructuring event in the system, with no natural selective key to stop on.

Symptom: a WBS element shows up in the wrong place, or is missing, in a structure report or the project builder tree view, while it is clearly still active in PRPS. Selection: find the project definition's internal number in PROJ from its external ID, list the project's WBS elements from PRPS with their STUFE values, then pull the matching rows from PRHI for those PSPNR values and compare stored level and parent links against what PRPS and the actual structure imply. A mismatch confirms the hierarchy pointer table is out of sync with the current structure.

The Project System data model built around PROJ and PRPS carried forward into S/4HANA largely unchanged, and PRHI is expected to still exist as the same kind of internal pointer table serving the same purpose. No confirmed replacement by a CDS compatibility view is known for this specific table, and its content should still be treated as a derived, technical structure rather than a reporting source in either release line.

A hierarchy inconsistency traced to PRHI is a technical PS or ABAP development question, not a functional configuration one. Functional PS consultants should keep working from PROJ, PRPS, and standard structure maintenance transactions, and escalate to the technical team or basis when a structure reorganization or pointer rebuild is needed.

PRPS holds the WBS element master data that PRHI's pointers reference, and PROJ holds the project definition that anchors the top of the hierarchy. Structure changes that update PRHI are triggered through standard project maintenance transactions such as the project builder and WBS element change transactions, and through project structure reorganization utilities rather than any direct table maintenance path.