VL06O — Outbound Delivery Monitor for Collective Processing
VL06O is the outbound delivery monitor, a menu of pre-built list variants (for picking, for goods issue, for loading, incomplete, and others) used to work a queue of deliveries at once rather than editing one document at a time. It does not post anything itself; it launches mass actions that call the same logic as VL02N, VL06O collective picking, or collective goods issue.
This page covers what VL06O actually does structurally, why two users running it often see different results, and the real sequence for using it safely for mass delivery processing. It also gives a diagnostic breakdown of the failure categories that come up in shipping operations and how to tell them apart in the data.
Published 20 Sept 2026· 1,204 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
What it does
VL06O is the outbound delivery monitor, a collective processing transaction that presents deliveries meeting a chosen selection profile and lets the user act on many of them at once - release for picking, post goods issue, print, or hand off to transport planning. It is not a single report but a landing screen that branches into roughly a dozen pre-built list variants (deliveries for picking, deliveries for goods issue, deliveries for loading, incomplete deliveries, and so on), each carrying its own hardcoded status filter. The one structural fact that explains most confusion: two people running VL06O are often running functionally different reports, because they picked different tiles from the initial menu. A delivery that seems to vanish from one list is usually sitting correctly in another, filtered out by design rather than by error.
When it is used
VL06O sits in the middle of the outbound process, after the delivery has been created (from a sales order via delivery creation, or in the background) and before or during goods issue and billing. It is the tool of choice whenever the task is to work a queue of deliveries rather than a single document - a shipping clerk clearing the picking backlog for a warehouse, a supervisor releasing everything due for loading today, or someone chasing deliveries stuck in an incomplete or blocked state. For a single delivery that needs a specific change, VL02N is faster; VL06O is for volume. On S/4HANA, teams increasingly reach for the equivalent Fiori delivery worklist app for the same purpose, but VL06O remains fully functional and is still the default for anyone working from a GUI shortcut or a batch job.
How to use it
The real entry sequence, in order:
- Call VL06O and choose the list variant that matches the task (for picking, for goods issue, for loading, and so on) rather than defaulting to a generic all-deliveries view.
- Enter selection criteria - shipping point, delivery or planned goods movement date, route, shipping condition - narrow enough to avoid a multi-thousand-line result.
- Execute and review the list; sort or filter further in the ALV grid before touching any status fields.
- Select the relevant lines deliberately, not select-all by habit, and choose the mass action offered for that variant: collective picking, collective goods issue, collective printing.
- Check the processing log after execution; a clean list header does not mean every line succeeded, only that the batch job ran to completion.
- Re-run the same variant afterward to confirm the deliveries actually left the queue rather than reappearing with an error status.
Key fields
VL06O itself writes nothing directly; it launches mass actions that update the following tables:
- LIKP — delivery header, including shipping-point/date data and header-level status fields in S/4HANA.
- LIPS — delivery items, picking/goods-movement-relevant quantities and item-level status fields in S/4HANA.
- VBFA — document flow for tracing source sales orders and follow-on goods movement/billing.
- ECC status model — VBUK/VBUP were separate status tables; S/4HANA moved the relevant persistence into LIKP/LIPS.
- Warehouse execution — confirm whether classic LE/WM, Stock Room Management or EWM owns picking/warehouse status before interpreting the list.
How to prove it in the data
To confirm a delivery is missing from a given VL06O variant for a real reason rather than a data error, go to SE16 on LIKP filtered by shipping point and delivery date, then read the corresponding entry in VBUK for the same delivery number to check overall picking status, goods movement status, and billing status. A delivery filtered out of a goods-issue variant almost always already has its goods movement status set to completed; one missing from a picking variant usually has picking status already closed. Cross-check LIPS for the same delivery to see whether the discrepancy is at header or item level - a partially picked delivery can carry a header status that hides one open item.
ECC vs S/4HANA
VL06O remains useful on S/4HANA as an outbound-delivery monitor, but the underlying status persistence changed. VBUK/VBUP were eliminated as persistence tables in S/4HANA; delivery status fields moved into LIKP/LIPS. Do not design new custom selection logic around direct VBUK/VBUP reads even if legacy code or documentation still uses those names conceptually.
Common pitfalls
Failures cluster into a small number of repeatable categories, best checked in this order:
- Wrong list variant chosen - a delivery believed missing is actually excluded by design because a narrower tile was used; re-run under a broader all-deliveries variant to confirm the record exists before assuming a data problem.
- Status filter mismatch - VBUK shows picking, goods movement, or billing status already complete when the user expected the delivery to still be open; check status fields before assuming corruption, since another user or an earlier attempt frequently already processed the line.
- Authorization scoping by shipping point or plant - a user with restricted authorization sees an empty list even though the data exists; verify with a broader-authorization user or a direct SE16 read before escalating as a master data gap.
- Mass action partial failure - a collective goods issue or collective picking run across many deliveries succeeds for most lines and fails for a few, usually on batch determination, negative stock, or incomplete storage location data; read the per-line log, not the batch summary, and do not blindly re-run the whole selection, which reprocesses lines that already succeeded and can trigger duplicate postings or lock contention.
- Selection field confusion - the date field a variant filters on (planned goods movement date versus actual delivery date) is not always the one the user assumes, and a delivery can be silently excluded on that basis rather than being genuinely absent.
Whose problem this is
This is a functional SD or logistics execution problem in nearly every case - wrong variant, wrong status filter, wrong authorization scope. Escalate to ABAP only when a custom list variant or selection report needs to be built or changed. Basis involvement is limited to authorization role content or performance tuning on very large selections. A good handover states which variant was run, the exact selection criteria, the delivery numbers affected, and the status field values already checked in VBUK and VBUP.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/vl06oERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.