Sales Order Missing From Delivery Due List

The warehouse or shipping team reports that an order the customer is chasing simply never turns up when they run the delivery worklist. They say something like: the order is confirmed, the customer service rep can see it in VA03, stock is available, but it never lands in the list we use to create deliveries every morning. Sometimes they add that it worked yesterday for the same customer and same plant, so they assume it is a batch job problem or a system slowness issue rather than something wrong with the order itself. Occasionally the complaint arrives as the order shows in the list but greyed out or with zero quantity, which is really a variant of the same underlying issue rather than a different one.

Pull the order's schedule line confirmed quantity and confirmed date, the header and item delivery block fields, the credit status field, and the shipping point and route fields on the item, then compare those against the exact selection parameters of the VL10 variant the shipping team ran. A mismatch on any one of those fields against the variant's filter is the proof; screenshot the schedule line tab and the VL10 selection screen side by side for the handover.

If the cause is an unconfirmed schedule line, this is a stock or ATP data issue, not configuration; either resolve the stock situation or re-run the availability check and rebook if quantity has since arrived. If the cause is a delivery block or credit hold, releasing it is a data-level action taken by the person authorized to release blocks, done in the order itself or through the credit release transaction, never by editing configuration. If the cause is a missing shipping point or route, redetermine it on the item after correcting the master data behind it (shipping point determination table entries, route determination condition records), which is a data fix even though the determination logic itself is configuration. If the cause is a wrong item category or schedule line category assignment, that is configuration and requires a transport through the usual change path, since fixing it on one order only masks the next occurrence. If the cause is a VL10 variant restriction, correct or extend the variant, or have the shipping team use the correct one; this is a user-level setting change, not a transport.

The reflex fix is to widen the VL10 date range and rerun the report a few times, assuming the job just has not picked it up yet, or to manually create the delivery in VL01N by typing in the order and item directly, bypassing the due list altogether. Both mask the real cause instead of fixing it: manual creation in VL01N will still fail or create a wrong delivery if the schedule line is genuinely unconfirmed or the order is credit-blocked, and it does nothing to stop the next order behind it from hitting the same block silently.

Order-desk or customer service owns block releases and credit holds; the SD configuration team owns shipping point, route, and item category determination; the warehouse or logistics execution team owns which VL10 variant they run and its selection parameters. The handover note should state the order and item number, the schedule line confirmed status, any block code found, and which VL10 variant was used when the item was reported missing.