Delivery Blocked by Unconfirmed Schedule Line

Warehouse or customer service reports that an order 'just sits there' - it was entered days or weeks ago, the customer is asking for status, but nobody can create the outbound delivery. Running the delivery due list for the order returns nothing, or VL01N against the order number gives a message that there is nothing to deliver. Sometimes the complaint arrives the other way: a delivery was created but with zero quantity on the item, and picking or goods issue then makes no sense. Planning frequently reports the paired symptom: stock shows as available in MMBE or the plant is not even short, yet the order line still shows an open, unconfirmed quantity. The common thread across all of these reports is that everyone is looking at the delivery step, when the actual decision was made earlier, at order save or at the last rescheduling run, by the availability check.

Start in VA03 on the schedule lines tab of the affected item - compare order quantity, confirmed quantity, and confirmed date line by line; a zero confirmed quantity with a pushed-out date is the definitive symptom. Run CO09 for the material and plant to see the live ATP situation and which MRP elements are consuming stock ahead of this order. Check MMBE for actual unrestricted stock versus what CO09 shows, to rule out a stock segment mismatch (batch, storage location, blocked stock). Look at MD04 to see whether the requirement from this order is even listed, which points to a transfer-of-requirements gap if it is missing. Review the checking group on the material master (material master MRP3 view) against the checking rule on the schedule line category in customizing. If stock looks fine but the order line is still unconfirmed, check whether a rescheduling (backorder processing) run has been executed since the competing demand was created.

Pull the schedule line table for the order item and show order quantity, confirmed quantity, and confirmed date side by side with the requested delivery date - a gap between requested and confirmed date, or a confirmed quantity below the order quantity, is the evidence. Pair it with CO09 output at the same timestamp to show what stock and MRP elements were competing for the same material and plant, which turns 'the order won't deliver' into a specific, attributable shortage or configuration gap.

If the cause is genuine stock shortage, this is a planning and allocation decision, not a system fix - either expedite supply, reduce the order quantity, or accept the later confirmed date; no configuration change is appropriate. If checking group or checking rule is wrong, correcting the material master checking group is a data fix per material, but changing the checking rule assignment on the schedule line category, or the scope of check content itself, is IMG configuration and needs a transport through the landscape. If transfer of requirements is inactive, the fix is in the requirements class or schedule line category configuration, also transport-based, and should be assessed carefully since it affects every order using that category. If the issue is a stale confirmation after stock was reallocated, running rescheduling (backorder processing) against the order or the affected material is a data-level corrective action, not a config change, and resolves the immediate case without touching customizing. Route or shipping point determination failures behind the scheduling problem are usually a master data or condition record gap and should be fixed at that layer before re-triggering ATP.

The reflex fix is to manually overwrite the confirmed quantity or confirmed date on the schedule line, or to force-create the delivery with the full order quantity regardless of confirmation. This gets a delivery document to exist, but the stock is not actually there to pick, so goods issue fails downstream or the warehouse ships against inventory that belongs to another order. It also breaks the ATP situation for every other order competing for the same stock, since the system's allocation logic no longer matches reality, and the shortage resurfaces as a picking or stock discrepancy problem instead of an order confirmation problem.

Order management or customer service owns the initial escalation since they see the symptom first, but the resolution sits with demand planning or MRP controllers when it is a genuine stock shortage, and with SD configuration when the checking rule, checking group, or transfer of requirements setup is at fault. The handover note should include the order and item number, the schedule line confirmation detail, and the CO09 snapshot at the time of complaint.