VL 609 — VL 609 — Delivery Has Not Yet Been Picked or Put Away Completely

VL 609 states that the delivery has not yet been put away or picked completely. In outbound delivery processing it commonly appears when post goods issue is attempted while picking is incomplete. In decentralized warehouse or EWM integration it can also appear in inbound queues that confirm warehouse execution back to ERP. SAP support examples show the message in VL02N, IDoc processing and SMQ2 delivery-confirmation queues. The important detail is that SAP is checking delivery execution status, not merely whether a user entered a quantity. The relevant overall and item status must be consistent with the goods-movement step being requested.

A delivery item may have a picked quantity below the delivery quantity, including zero. Partial picking may be incompatible with the requested PGI behavior or with item/category configuration. Warehouse confirmation can arrive in a sequence that leaves ERP status incomplete. Custom exits or delivery-update code can interfere with status updates. In decentralized or EWM scenarios, a queue can be retried after downstream state has changed, causing confirmation and ERP delivery status to disagree. IDoc-based shipping confirmation may also send picking quantities that do not match the delivery. Another common cause is assuming that a partial-delivery business rule automatically allows partial PGI; those are separate checks.

Open the delivery and compare delivery quantity, picked quantity and item/overall picking status. Check whether the item is relevant for picking and whether the warehouse process has completed the required task. In VL02N, inspect status details rather than relying only on the header. For EWM or decentralized warehouse integration, inspect the SMQ2 queue name and the confirmation document, then verify whether warehouse tasks and goods issue are already complete on the warehouse side. For IDoc scenarios, inspect the inbound shipping confirmation quantities and statuses. If the error started after custom code changes, review delivery user exits or BAdIs that modify quantities or status before save.

Complete or correct the picking process first. If only part of the delivery should ship, adjust the delivery quantity or use the supported partial-delivery process so that picked and goods-issue quantities are consistent. In EWM integration, correct the warehouse execution inconsistency and reprocess the queue only after ERP and EWM represent the same business state. If an inbound confirmation carries zero or incorrect picking quantity, fix the sending process rather than changing the ERP status manually. Where custom delivery logic caused the inconsistency, remove or correct that logic and recreate a clean test flow from delivery creation through picking and PGI.

Users sometimes try to force PGI by changing a status field, copying quantities blindly or repeatedly reprocessing the queue. That can create duplicate confirmations, stock discrepancies or delivery status that no longer reflects warehouse reality. Another risky workaround is to mark the delivery complete even though the warehouse has open work. VL 609 is protecting process consistency. The reliable fix is to make the physical/logical picking state and the ERP delivery state agree before the goods issue or confirmation is retried.

SD/LE owns the outbound delivery and PGI behavior. WM/EWM owns picking execution and warehouse confirmation. Integration teams own IDoc or qRFC transfer when the warehouse and ERP states diverge. ABAP is involved if custom delivery exits or interface code manipulate quantities or statuses. In an EWM-connected landscape, both teams should inspect the same document number and timestamp because each system can be individually 'correct' while the cross-system sequence is wrong.

Do not treat a nonzero picked quantity as equivalent to complete picking. Check every relevant item and overall status. Do not retry a stuck confirmation repeatedly without checking whether goods issue or picking was already posted on the warehouse side. Partial delivery configuration does not automatically guarantee partial PGI behavior. For IDocs, confirm the quantity unit and item mapping. When a queue is involved, fix the root document first and then reprocess in sequence. After recovery, validate stock, delivery status and subsequent billing so the technical retry did not leave a hidden logistics inconsistency.