Collective Delivery Creation, Scheduling, and Route Determination
How due sales orders are grouped into deliveries using the VL10 transaction family, how scheduling dates are calculated, and how route determination assigns a shipping route to each delivery.
Explanation
In real distribution operations, shipping supervisors rarely create deliveries one order at a time from VA01/VA02 follow-on screens. Instead they run collective processing using the VL10 family of transactions (VL10A for sales orders, VL10B for purchase orders/stock transfers, VL10C for combined due lists, VL10D/E/F/G/H for other selection variants) to pull every order line that is due for delivery within a shipping point, route, or date range and create deliveries in bulk. Understanding why an order line does or does not appear in this due list, and how the delivery's key dates are derived, is one of the most common troubleshooting skills in an SD support role.\n\nScheduling in SD works backward and forward from the requested delivery date on the sales order schedule line. Backward scheduling calculates, in sequence, the goods issue date, the loading date, the transportation planning date, and the material availability date by subtracting pick/pack time, loading time, and transit time (each held in the shipping point and route master data, using the relevant factory calendar). If backward scheduling pushes the material availability date into the past, the system automatically switches to forward scheduling from today, which shifts the confirmed delivery date later than what the customer requested. This is a very common root cause when customers complain that their confirmed date does not match what was promised verbally.\n\nRoute determination assigns a transportation route to the delivery (and often to the order at creation time, then re-checked at delivery creation). The standard determination logic combines the departure shipping point/country, the ship-to party's destination country and transportation zone, a shipping condition from the customer master, the transportation group from the material master, and the total weight group of the document to look up a route in the route determination customizing table maintained in the IMG under Logistics Execution / Enterprise Structure or Basic Functions depending on release. Because weight group depends on total document weight, the same order can determine different routes depending on order quantity, which is a frequent source of 'why did my route change' questions.\n\nDelivery creation also respects delivery blocks (header-level, e.g., credit block or blocked for shipping) and item-level relevance flags (delivery relevance on the schedule line category, complete delivery indicator on the sales document). If any of these are set incorrectly, the order line silently disappears from the due list without an obvious error message, which is why 'delivery not created' tickets require checking blocks, relevance flags, and shipping point/route assignment before assuming a program error.\n\nIn S/4HANA, the underlying logic is largely unchanged from ECC, but Fiori apps such as 'Create Outbound Deliveries - Collective Processing' provide a modernized UI wrapper over the same due list logic, and background job scheduling for collective delivery runs is commonly managed through the Fiori 'Schedule Outbound Deliveries Creation' app rather than classic background job SM36 setup, though SM36 still works in on-premise/private cloud.
Code example
* Example: simplified logic consultants use to explain due-list exclusion\n* (illustrative pseudocode, not an actual ABAP program)\n\nIF sales_order-item-delivery_block IS NOT INITIAL.\n \"Item excluded from VL10 due list - check delivery block reason\n ENDIF.\n\nIF sales_order-header-overall_delivery_block IS NOT INITIAL.\n \"Whole order excluded - check header block (e.g. credit hold)\n ENDIF.\n\nIF schedule_line_category-delivery_relevant = ' '.\n \"Schedule line will never generate a delivery (e.g. free item config)\n ENDIF.\n\n* Scheduling backward pass (conceptual)\ngoods_issue_date = requested_delivery_date.\nloading_date = goods_issue_date - loading_time.\ntransport_planning_date = loading_date - transit_time.\nmaterial_avail_date = transport_planning_date - pick_pack_time.\n\nIF material_avail_date < sy-datum.\n \"Backward scheduling failed - system reschedules forward from today\n ENDIF.Real project scenario
A distribution center running three shifts complained that Friday afternoon orders were confirming for delivery the following Wednesday instead of Monday. Investigation showed the route assigned to those orders used a transit time calendar that excluded Saturday and Sunday, and the shipping point's factory calendar also excluded a regional holiday that fell that week. The consultant traced the dates using the schedule line scheduling tab, identified the calendar mismatch between the route and the shipping point, corrected the transit time customizing for that specific route, and reran the due list to confirm the corrected dates before communicating a fix to the business.
Common mistakes
⢠Assuming a missing delivery is a system bug before checking header and item delivery blocks\n⢠Not accounting for weight-group-driven route changes when order quantities change between order entry and delivery creation\n⢠Confusing requested delivery date with confirmed delivery date after forward scheduling kicks in\n⢠Running VL10 without saving/reviewing the log, missing exception messages for excluded items\n⢠Overlooking that route determination also depends on shipping condition from the customer master, not just the ship-to country\n⢠Not aligning factory calendars between shipping point and route, causing inconsistent transit time calculations
Best practices
⢠Always check both header and item delivery blocks before escalating a missing delivery as a defect\n⢠Document route determination key combinations for each customer/shipping point pair to speed up support diagnosis\n⢠Align factory calendars across shipping points and routes serving the same region to avoid inconsistent transit times\n⢠Use VL10 selection variants per shipping point/route to give warehouse teams manageable, repeatable due lists\n⢠Review scheduling logs after forward scheduling triggers to proactively notify customer service of date changes\n⢠In S/4HANA, evaluate the Fiori collective delivery creation apps for scheduling automation rather than relying solely on legacy background jobs
Interview angle
Interviewers often probe whether a candidate understands the difference between backward and forward scheduling and can explain, step by step, why an order line might be missing from a VL10 due list. Being able to name the specific fields involved (delivery block, schedule line category delivery relevance, route determination key fields) demonstrates real production troubleshooting experience rather than textbook knowledge.