BAPI_OUTB_DELIVERY_CREATE_SLS — Create Outbound Delivery From Sales Orders

BAPI_OUTB_DELIVERY_CREATE_SLS creates outbound deliveries with reference to sales order schedule lines, doing the same job as VL01N when a delivery is generated against one or more open sales order items rather than against a shipment or stock transport order. It belongs to the outbound delivery BAPI family alongside the versions that create deliveries from stock transport orders and from mixed document types. The call takes a set of sales order and item combinations due for delivery, runs the same delivery-relevance checks the online transaction runs - delivery block, shipping point and route determination, complete delivery indicator, quantity available for delivery - and, if the checks pass, generates a delivery document with the same table footprint LIKP/LIPS would show if it had been created manually. It stops at delivery creation. Picking, packing, and goods issue are separate steps handled by other calls.

The interface is built around an input table of sales order references, header-level shipping data, and two export structures: the created delivery numbers and the return table.

The BAPI does not commit the database on its own. A delivery number can be handed back in the export table while the underlying database change still sits in the caller's LUW, and it disappears if the session ends without an explicit BAPI_TRANSACTION_COMMIT call. This is the single most common cause of the it worked once and never again complaint on this BAPI: the test program committed by accident through a subsequent dialog step, the production job did not, and the delivery number returned to the calling interface was never actually persisted. Any downstream process - picking list generation, confirmation, goods issue - that receives that number afterward fails with a not found error, and the failure looks like a data problem rather than what it actually is, a missing commit in the calling program.

The return table must be scanned in full, not sampled. A single call against several sales order items can create some deliveries and reject others in the same invocation, so the return table can contain a mix of success, warning, and error entries belonging to different line items. Code that checks only whether the first entry is type E, or that treats a non-empty created-deliveries table as proof of full success, will silently drop the rejected items and report the interface run as clean. The correct pattern reads every line, correlates entries back to the sales order item they reference where the message variables allow it, and treats type A (abort) as distinct from type E (error) since an abort can mean the whole call was rolled back regardless of what the created-deliveries table shows. Warning-only runs (type W) still require judgment - a delivery created with a warning about incomplete data is not the same as a clean creation, and passing it downstream without flagging the warning moves the problem to whoever runs picking next.

The BAPI remains usable in S/4HANA for creating outbound deliveries from sales order references; there is no dedicated replacement BAPI that has fully superseded it for this specific scenario. S/4HANA's Fiori-based delivery creation apps and background delivery due list processing still rely on the same underlying logistics execution logic this BAPI wraps, so the checks it performs and the way it fails have not materially changed. New integrations are increasingly built against released API layers rather than calling the BAPI directly, but where a direct call is still in use, the commit and return-handling behaviour described here still applies unchanged.

Most failures trace back to order-level or customizing conditions the BAPI simply reports rather than causes.

A rejected delivery creation with a clear customizing message - delivery block, incomplete order, credit hold - is a functional configuration or master data issue and belongs with the SD team. A delivery number that vanishes after creation, or a return table that shows success while nothing downstream can find the document, is an interface defect and belongs with the developer; the functional side's evidence in that case is simply that the order data and delivery-relevant settings were correct at the time of the call.

Mirrors the delivery creation step of transaction VL01N and writes to the same LIKP header and LIPS item tables a manually created delivery would use. Sits downstream of the sales order BAPIs that create the referenced orders, and upstream of the delivery change and confirmation BAPIs that pick, pack, and post goods issue against the delivery it creates, and of billing document creation once the delivery has been confirmed.