VL03N — Display Outbound Delivery

VL03N opens an outbound delivery in display mode: header data (shipping point, route, delivery date), item data (delivery quantity, batch, storage location), and status information for picking, packing, goods movement, and billing, both at header and item level. The structural fact that explains most confusion: a delivery is its own independent document, distinct from the sales order and the billing document, connected to both only through document flow entries. Header status fields and item status fields are tracked separately and do not always move in lockstep, so a delivery can show 'partially processed' at header level while every item is individually complete, or vice versa. VL03N will not let a consultant fix anything found wrong; it is purely diagnostic, which is exactly its value mid-incident.

VL03N sits between delivery creation and billing in the order-to-cash chain. A consultant reaches for it whenever a delivery number is already known and the question is 'what state is this document in' rather than 'what needs to change'. Typical triggers: a billing block investigation that starts from VF01 and needs to trace back to the delivery's goods movement status, a warehouse query about why picking confirmation did not update, or a document flow check from VA02 that lands on a delivery line. VL02N is used instead the moment a field needs correcting, a batch needs reassigning, or goods issue needs to be posted. VL06O or the Fiori delivery list apps are used instead when the starting point is a list of deliveries by criteria rather than one known document number.

Start in SE16N on LIKP filtered by VBELN to confirm the delivery exists and read its header status. Join to LIPS on VBELN to compare delivery item quantity against order quantity. Pull VBUK for the same VBELN to check WBSTK (goods movement status) and the picking status field; a value other than 'C' completed on an item that the user believes is finished points at a partial posting. Query VBFA with VBELV equal to the delivery number and filter VBTYP_N to isolate whether a goods movement or billing document actually followed. Absence of a VBFA row into MKPF/MSEG with a completed status in VBUK is the classic sign of a goods issue that never actually posted.

VL03N is unchanged as a transaction code on S/4HANA and remains fully usable. The underlying tables LIKP, LIPS, VBUK, VBUP, and VBFA are the same tables read on both ECC and S/4HANA. Fiori offers list-based alternatives such as the delivery monitoring and manage outbound deliveries apps for browsing many deliveries at once, but for a single known delivery number, opening it directly in VL03N remains the fastest path and is still what most consultants do inside an S/4HANA system.

This is functional SD / logistics execution territory: reading and interpreting delivery status belongs to whoever owns outbound delivery processing. ABAP gets involved only if a custom user exit or enhancement is suspected of interfering with status determination or goods movement posting. A clean handover states the delivery number, the exact status field values read from VBUK/VBUP, the document flow entries present or missing, and whether the material document exists, so the receiving team does not have to re-run the same navigation.

VL10A and VL10B are the natural upstream reference, since they create the delivery that VL03N later displays, and understanding delivery-due-list logic explains why a delivery split the way it did. VA13 gives the preceding sales order view needed to compare ordered versus delivered quantity. VF03 shows the resulting invoice when the investigation runs forward from delivery to billing. VL09 is the counterpart action when VL03N reveals a goods movement that needs reversing rather than merely reading.