BAPI_PO_CREATE1 — BAPI_PO_CREATE1 Purchase Order Creation

BAPI_PO_CREATE1 creates a purchasing document of the standard purchase order type, acting on the same business object as transaction ME21N. It writes header data to EKKO, item data to EKPO, schedule lines to EKET, account assignment to EKKN, and partner data to EKPA, exactly as the online transaction would. It is used for interfaces that generate POs from external procurement systems, e-procurement catalogs, custom conversion programs, or automated replenishment logic where a requisition is converted without a buyer touching ME21N. It supports the same item categories, account assignment categories and document types as the transaction, and inherits the same configuration dependencies, so a PO type that fails validation in ME21N will fail the same way through this BAPI.

The BAPI does not commit the database update itself. A separate call to BAPI_TRANSACTION_COMMIT is required after RETURN has been checked and found clean. If the caller omits this, EXPPURCHASEORDER is still populated with a number in the response, which misleads developers into believing the PO exists, but nothing is written to the database and the number is either wasted or reused on the next call depending on number range buffering. In background jobs this shows up as PDs created according to the interface log but absent from ME23N. Some custom wrappers call COMMIT WORK directly instead of the BAPI wrapper; this generally works but bypasses the update task synchronization the wrapper provides, and under heavy parallel load can produce timing-related lock waits that BAPI_TRANSACTION_COMMIT with WAIT would have avoided.

RETURN is a table of BAPIRET2 structures, not a single flag, and SY-SUBRC after the CALL FUNCTION is essentially always zero for a well-formed RPC call regardless of whether the business logic succeeded. The only reliable check is looping through RETURN and testing the TYPE field for E or A; anything else, including S and I, does not mean failure. A frequent interface bug treats any non-empty RETURN table as an error and aborts, which breaks on the common case of a PO created successfully with an informational message about price determination or a missing tax jurisdiction default. The opposite bug is worse: code that only checks whether EXPPURCHASEORDER is blank as a proxy for success, ignoring RETURN entirely, which lets a PO with a real error message pass silently because some error paths still return a preliminary or blank number. Message number and ID inside RETURN matter for root-causing recurring failures such as release strategy determination or vendor purchasing-org extension, and should be logged, not discarded, even on apparent success.

BAPI_PO_CREATE1 remains valid and released for use on S/4HANA; there is no mandatory replacement forcing migration away from it for classic ABAP-based integrations. For newer extension scenarios, particularly Fiori-based or cloud-adjacent development, SAP-released OData and API services for purchase order processing are the preferred entry point, but they sit on top of largely the same underlying logic rather than superseding this BAPI outright. Field-level behaviour and configuration dependencies carry over from ECC largely unchanged, aside from additional customer fields reachable through the extension include.

A failure inside RETURN pointing to vendor, purchasing org, pricing or release strategy is functional: the fix is master data or configuration, and functional should reproduce the same input manually in ME21N first. A failure where RETURN is clean but data is missing, wrong item mapped, or the commit never happened is developer-side interface code. Whoever raises the ticket should attach the full RETURN table content, not just 'it failed'.

Mirrors transaction ME21N for creation and ME22N/ME23N for the resulting document; writes to EKKO, EKPO, EKET, EKKN and EKPA. BAPI_PO_CHANGE handles subsequent updates to a PO created this way, BAPI_PO_GETDETAIL1 reads it back for verification, and BAPI_PO_RELEASE clears release strategy blocks it may trigger. Upstream, BAPI_PR_CREATE and BAPI_REQUISITION_CREATE generate the requisitions this BAPI often converts into orders.