PRPS table — PRPS WBS Element Master Data Table

Each row in PRPS is one WBS element: a single node in a project's work breakdown structure, whether that is the top element of the project or a leaf-level element several levels down. The row carries identifying and organizational data only - what the element is called, which project it belongs to, which company code and controlling area it is assigned to, who is responsible, what level it sits at - and a generated object number that acts as the key into every other part of the system that needs to know something happened against this WBS element. It does not carry planned costs, actual costs, or budget figures. Those live in separate CO and PS value tables keyed by the same object number. A WBS element that has been created but never posted to still has a full row here.

Always restrict on MANDT implicitly through the standard client handling, but do the real filtering on PSPHI when the goal is every element of one project, or on PBUKR plus PKOKR when scoping by organizational unit. Selecting on POSID with a wildcard is risky because the display format depends on the project profile's edit mask, so the same element can appear with or without separator characters depending on where the value came from. Never scan PRPS without at least one of PSPHI, PBUKR, or a PSPNR range - on a system with a long-running PS implementation this table can carry a large number of rows across many projects and years. If the entry point is a cost or budget posting, start from OBJNR and go backward into PRPS rather than starting from POSID text matching.

A user reports that a WBS element cannot be used for posting. Look up PRPS by POSID (or PSPNR if already known) to get OBJNR, then check JEST for that object number to see the active system status - a status like technically complete or closed with the posting-blocking business transaction attached will confirm why postings are rejected, independent of anything in PRPS itself which never shows status directly.

PRPS continues to exist as a transparent table in S/4HANA and remains the primary master data table for WBS elements under classic Project Systems. Newer project management capabilities introduced in S/4HANA, such as enterprise project management built on different data objects, do not replace PRPS for projects created and maintained through the traditional PS transactions - those still write to PRPS exactly as in ECC. No compatibility view is needed for basic reads against this table in a classic PS context.

The PS module consultant or project controller owns questions about WBS master data content, hierarchy structure, and status. Cost and budget value discrepancies reached through PRPS-OBJNR joins are usually a joint PS/CO question, since the values themselves are owned by controlling but the object structure they post against is owned by PS.

PROJ carries the project definition that every PRPS row's top element points to via PSPHI. PRHI carries the actual parent-child hierarchy pointers between WBS elements. WBS elements are created and changed through the standard project maintenance transactions, which write to PRPS, PRHI, and the network/activity tables together. Budget is planned and revised through the PS budgeting transactions, writing to BPGE and BPJA. Actual and plan cost totals are updated by CO postings and settlement runs into COSPD and related totals tables, all keyed by the same OBJNR found in PRPS.