BAPI_OUTB_DELIVERY_CONFIRM_DEC — Outbound delivery confirmation BAPI, decimal quantities

BAPI_OUTB_DELIVERY_CONFIRM_DEC posts a confirmation against an outbound delivery that already exists in the system - picking quantity, packing status, or goods issue, depending on how the calling program populates its control fields. It mirrors the confirmation step normally triggered manually in VL02N (single delivery, goods issue tab) or in collective processing through VL06G/VL06P. It is used almost exclusively for integration scenarios: a decentralized warehouse management system, a third-party shipping execution platform, or an EWM landscape not wired through native document flow, sends back the quantities actually picked or shipped, and this BAPI writes that confirmation into the delivery. The 'DEC' suffix marks it as the decimal-enabled successor to an older confirmation interface whose quantity fields were too short for fractional or high-precision units of measure.

The interface separates delivery identification, header-level control, and item-level confirmation data. Only the parameters below are used with confidence; internal structure field names are described rather than named where uncertain.

The BAPI follows the standard SAP pattern of separating business logic from database commit. It does not call COMMIT WORK internally. The calling program is responsible for invoking BAPI_TRANSACTION_COMMIT after checking RETURN for errors. If the caller skips this step, the confirmation appears to succeed inside the same LUW - RETURN can even come back clean - but nothing is written to the database once the session or RFC connection ends. This produces the classic symptom of an interface that logs success on every call but the delivery status in the system never changes, discovered only when someone compares the interface log against VL03N.

RETURN is a table, not a flag, and an empty RETURN table is not proof of success - it can also mean the call did nothing because the delivery, item, or quantity combination did not match any confirmable line. The correct check loops through RETURN and treats any line with TYPE 'E' or 'A' as a hard failure that must block the subsequent commit; 'W' lines are warnings, often quantity tolerance or batch determination notices, that still allow a commit but should be logged; 'S' or 'I' lines confirm what actually happened. The recurring interface bug is checking only the first line of RETURN, or checking SY-SUBRC instead of RETURN, both of which miss errors buried further down the table. A second common bug is calling COMMIT WORK regardless of RETURN content, which persists a partially failed confirmation and leaves the delivery in an inconsistent state that is difficult to reverse cleanly afterward.

On S/4HANA, outbound delivery remains the same document type and this BAPI still works and is not formally deprecated. Where embedded or decentralized EWM is in use, however, the confirmation typically originates from EWM's own warehouse task completion and updates the delivery through standard document flow rather than through an external system calling this BAPI directly, so its use shrinks to non-EWM shipping integrations and legacy custom interfaces. The older, non-DEC version of this BAPI should be treated as obsolete on any current release; new builds should always target the DEC variant.

Most failures trace back to timing, unit conversion, or missing commit discipline rather than the BAPI itself.

Functional (SD or logistics execution) owns the business rules behind confirmation - quantity tolerances, which confirmation step triggers goods issue, batch and serial requirements. Development owns the interface plumbing - commit timing, retry handling, RETURN parsing. When a confirmation is disputed, functional needs the delivery number, item, and confirmed quantity from the source system; development needs the RETURN table content and confirmation that BAPI_TRANSACTION_COMMIT was actually called.

Mirrors the goods issue and confirmation logic in VL02N and the collective processing screens VL06G/VL06P, and reads and writes delivery header and item data underlying tables LIKP and LIPS. Sibling BAPIs cover the surrounding lifecycle: creation of the delivery, changes to delivery data before confirmation, and creation of the billing document once the delivery is confirmed and goods-issued.