PROJ table — PROJ - Project Definition Header Table

One row in PROJ represents one project definition, the single header node that sits above the WBS element hierarchy for a project. It is not an individual WBS element (that is PRPS) and not a network or activity. PROJ carries the organizational assignment for the whole project - company code, controlling area, plant - the person responsible, the project type and profile, and the object number that ties the project definition into status management and into the CO object framework. Anything that is genuinely project-wide, the external number people search on, the profile that drives which checks and fields apply, the responsible person, lives here. Cost line items, budget figures, dates for individual work packages, and the hierarchy structure itself are stored in separate tables that reference this one.

PROJ is a low-volume table relative to PRPS, roughly one row per project versus many WBS elements per project, so a full scan is rarely the performance problem people fear. Always restrict on MANDT first in any manual selection, then on PSPID if the search is user-driven or PSPNR if the query originates from a WBS element already resolved elsewhere. PSPID is a character field and is frequently padded or entered inconsistently with leading characters or different casing, so a wildcard search on PSPID is safer than an exact match when chasing a reported project number. Do not filter mass reports directly on PBUKR or KOKRS without also checking whether those values are inherited correctly down the hierarchy in the customer's configuration.

Symptom: a project manager insists project Z-100 exists but the project builder returns nothing. Select PROJ where PSPID equals Z-100. No row returned means the project definition was never saved in this client, or exists under a different external ID than the one being searched. A row returned means the project exists; take its OBJNR and check the status object for a deletion flag or a locked status. A project that is deletion-flagged or archived still has a PROJ row in some phases of the archiving process but is excluded from standard reporting, which looks identical to never-created unless the status is actually checked.

PROJ continues to exist in S/4HANA as the project definition table and has not been observed replaced by a compatibility view in the way several FI and CO tables were. The underlying structure of classic Project System, PROJ, PRPS, and the hierarchy tables, is essentially unchanged. What has changed around it is the front end: newer project management scenarios lean on Fiori apps and APIs sitting on top of the same tables rather than replacing them, so a table-level investigation in PROJ still gives an accurate picture of project definition data on S/4HANA.

Master data questions on PROJ, why a project is missing, misnumbered, or shows the wrong responsible person, sit with whoever administers Project System configuration and master data, typically the PS functional consultant. Organizational assignment fields such as company code and controlling area are a joint question between PS and FI or CO configuration owners. Archiving-related disappearances are a basis or data management question, not a functional one, and should be routed there before anyone assumes data loss.

PRPS holds the WBS elements that belong to a PROJ project definition and is written by the same project builder and change transactions. PRHI carries the hierarchy pointers used to reconstruct parent-child relationships between WBS elements and the project definition. Budget tables record overall and annual budget values against the project's object number, and CO planning tables record planned cost data against the same object. The transactions that create and maintain PROJ rows are the standard project create, change, and display transactions along with the project builder.