BAPI_PO_RELEASE — BAPI_PO_RELEASE: releasing a blocked purchase order

BAPI_PO_RELEASE releases a purchase order that is currently blocked by a release strategy, performing the same function as the release step in transaction ME28 or the release tab of ME29N and ME22N. It acts on the purchase order header held in EKKO, updating the release indicator and, where the release strategy is item-based, the corresponding release fields on the relevant items in EKPO. The BAPI does not create or change the purchase order itself; it only advances the release status by one step, or completes the release if only one outstanding code remains. It assumes the purchase order has already been assigned a release strategy through classification of its release-relevant characteristics. If no strategy applies to the document, there is nothing for this call to do.

The interface is deliberately narrow: it identifies the document and, where needed, which approval step is being exercised.

BAPI_PO_RELEASE does not commit its own work to the database. Like nearly all release and workflow BAPIs, it stages the change and hands control back to the caller, who must invoke BAPI_TRANSACTION_COMMIT to make the release persist. If the caller checks RETURN, sees no error, and moves on without committing, the purchase order can appear released within the calling program's own session buffer but reverts to blocked status the moment it is read fresh, and the requester still sees it held. This is the most frequently reported integration defect against this BAPI: the release worked in a manual test, then silently failed to persist inside a batch job or middleware call that omitted the explicit commit.

RETURN is a table, not a single structure, and this BAPI can return more than one line: one message for the release step itself, plus additional lines if the release triggers a workflow notification or a downstream check on budget, contract reference, or account assignment. Code that reads only the first line of RETURN, or checks sy-subrc after the call, misses errors sitting further down the table. The correct pattern is to loop the entire table and treat any line with type E or A as a failure regardless of position; type S or I lines are informational. A common wrapper bug treats an empty RETURN table as proof of success, but an empty table after this call usually means the release code was already satisfied or nothing changed, not that a release was executed. Log the full structure, including message class and number, not just the text, so recurring failure categories such as missing strategy, wrong code, or already-released status can be filtered programmatically instead of by string matching.

BAPI_PO_RELEASE remains the standard way to release a purchase order programmatically in S/4HANA; there is no dedicated newer released API that replaces it for this specific action. The underlying release strategy configuration, classification, release groups, codes, and strategies, is unchanged from ECC. Fiori approval apps for purchase orders invoke the same release logic under the hood rather than a separate service, so behaviour and message content stay consistent with the classic BAPI. Custom workflow and batch release programs built on this BAPI in ECC generally carry forward without redesign.

Most failures trace back to release strategy configuration or sequencing rather than to the BAPI call itself.

Functional consultants own the release strategy configuration: classification, characteristics, release groups and codes, and the approval sequence. A 'no release possible' result or the wrong code being expected is a configuration or master data question, not a coding defect. Developers own how the calling program handles RETURN and the commit call. Ask for the full RETURN table content and the purchase order's current release status fields before assigning fault to either side.

Mirrors transactions ME28 for collective release and ME29N for individual release, and reads and writes the release fields on EKKO and, for item-level strategies, EKPO. Typically paired with BAPI_PO_GETDETAIL1 to check current release status before calling, and sits alongside BAPI_PO_CREATE1 and BAPI_PO_CHANGE in the surrounding create-change-release lifecycle of the purchase order. Release strategy design and testing is normally done through the classification transactions rather than through any BAPI.