BAPI_PROJECT_MAINTAIN — BAPI for Maintaining Project Definitions and WBS Elements

BAPI_PROJECT_MAINTAIN maintains the project definition and its WBS element hierarchy, the same objects created and changed through CJ01 and CJ02. A single call can build an entire new project structure, extend an existing one with additional WBS elements, or update basic dates, responsible cost centre, plant, user fields and status-relevant attributes on elements that already exist. It does not touch networks, activities or milestones - those are maintained through the separate network BAPI family. The interface follows the same multi-method pattern used elsewhere in PS and PM: an instruction table tells the BAPI what operation to perform against which object, and one or more data tables carry the actual field values, linked together through temporary numbers the caller assigns, because the real WBS element internal number does not exist yet at the moment the call is built.

BAPI_PROJECT_MAINTAIN does not commit. Like most BAPIs it writes to the update task within the current LUW and leaves the decision to commit or roll back with the caller, who must call BAPI_TRANSACTION_COMMIT (or the equivalent in the calling program) after inspecting RETURN. Forgetting the commit does not raise an error - the call appears to succeed, RETURN may even come back clean, but nothing is persisted to the database once the session ends, and any object numbers reported in the export mapping table become invalid. This is a frequent cause of interfaces that report success to a monitoring log while the project was never actually created.

RETURN must be scanned as a full table, not sampled from the first row. A batch call that creates a project definition plus several WBS elements can produce a mix of message types across different method-table rows: one WBS element fails a required-field check while the others succeed, or a warning fires on a date shift that is easy to mistake for informational noise. Reading only the first entry, or checking whether RETURN is initial instead of scanning for message type E or A, is the classic interface bug - it lets the caller commit a partially built structure. Because each RETURN row correlates to a specific method-table entry, the caller has to map messages back to the object key or temporary number they reference to know precisely which WBS element failed; skipping that mapping means the calling program either commits everything indiscriminately or rejects a batch that in fact mostly succeeded. Function-module return code (sy-subrc) is not a substitute for this - the BAPI itself will return 0 even when RETURN carries fatal errors.

BAPI_PROJECT_MAINTAIN remains the standard integration point for classic project definitions and WBS elements on S/4HANA on-premise; no released public API has fully superseded it for this scope. S/4HANA also introduces separate project types for enterprise-style project management, which are maintained through a different set of objects and are not addressed by this BAPI. When a project shows up as an enterprise project rather than a classic PS project, confirm which project type is in use before assuming this BAPI applies.

Interface correctness - method-table sequencing, commit logic, RETURN parsing - is a developer problem. A PS consultant's job is to confirm what the equivalent manual action in CJ02 does and produce the project profile, status, and field values that reproduce the block, since most failures trace back to a status or configuration restriction the interface is running into, not a code defect.

Mirrors CJ01 (create project) and CJ02 (change project); underlying data lands in the project definition table (PROJ) and WBS element table (PRPS). Networks and activities attached to the same project are maintained through separate calls such as BAPI_NETWORK_MAINTAIN and BAPI_BUS2054_CREATE_MULTI rather than through this BAPI, and interfaces that build a full project-network structure typically call all of them in sequence within the same LUW before a single commit.