BAPI_OUTB_DELIVERY_CHANGE — Change outbound delivery header, item and pick data

BAPI_OUTB_DELIVERY_CHANGE acts on an outbound delivery document (the LIKP/LIPS pair) and functionally mirrors transaction VL02N. It is used to change header data such as planned goods issue date, route, or shipping point flags, and item data such as delivery quantity, batch, or storage location, and to update picking quantities without opening the delivery in the GUI. It is the standard interface call for warehouse and transport systems that need to push picking confirmations, quantity corrections, or date changes back into SAP once a delivery already exists. It is not used to create deliveries and it is not used to post goods issue; those are separate BAPIs. It operates on one delivery per call.

The BAPI does not commit the database update itself. Like almost all classic BAPIs, it stages the change and returns control to the caller, who must explicitly call BAPI_TRANSACTION_COMMIT to make the change durable, or BAPI_TRANSACTION_ROLLBACK to discard it. Programs ported from a batch input recording or copied from an older interface sometimes assume the SD BAPIs auto-commit because some do inside certain frameworks; this one does not when called directly. The practical symptom of a missing commit is a call that returns a clean RETURN table with no errors, yet the delivery shows no change when reopened in VL02N a moment later, because the update was rolled back at the end of the LUW with no error raised at all.

RETURN is a table, not a single structure, and this BAPI can populate several rows in one call: one message per rejected item alongside header-level messages. Checking only whether RETURN is initial, or only scanning for TYPE equal to E, is the single most common defect seen in interfaces built on this BAPI. Type A (abort) and type X (exit) entries occur and must be treated as hard failures, and a call can return TYPE S or W messages describing a partial success, such as one item's quantity accepted and another rejected for an unrelated reason like a batch not found or a quantity exceeding the open quantity. Interfaces that treat 'no exception raised by the function module' as success miss all of this, because the function module itself rarely raises a classic ABAP exception; the failure is communicated entirely through RETURN. Correct handling loops the full table, treats E, A, and X as failure requiring rollback, and logs S and W entries against the specific item number carried in the message's system fields so a partial rejection can be traced back to the delivery line that caused it.

BAPI_OUTB_DELIVERY_CHANGE remains valid and in active use on S/4HANA for classic outbound delivery processing; it has not been withdrawn or formally deprecated in favor of a single replacement API. Environments running embedded or decentralized EWM increasingly drive picking and confirmation through the warehouse-side integration rather than calling this BAPI directly from external systems, but for straightforward header and quantity corrections against a standard delivery it is still the interface most consultants reach for, and it behaves the same way it did on ECC.

A rejected change or a message about quantities and status belongs to the logistics execution functional consultant, who should provide the delivery number, the exact RETURN table content, and the delivery's current status in VL02N. A change that returns clean but never persists, or fails only under concurrent load, belongs to the interface developer, who should show the commit logic and any lock-retry handling around the call.

The interactive transaction mirrored is VL02N, with VL03N for display-only checks. Underlying tables are LIKP and LIPS for delivery header and items, and VBUK and VBUP for header and item status. The natural sibling on the create side is BAPI_OUTB_DELIVERY_CREATE_SLS, and on the goods-issue side is BAPI_OUTB_DELIVERY_CONFIRM_DEC, both of which share the same RETURN and commit conventions described here.