SAP Delivery

The outbound delivery represents the fulfilment step: it triggers warehouse activities (picking and packing) and, on goods issue, reduces inventory (MM) and posts cost of goods sold (FI). It is the operational link between agreeing to sell (order) and invoicing (billing).

• Delivery creation from the order (due for delivery).
• Picking (with WM/EWM for detailed warehouses).
• Packing (handling units).
• Goods issue: stock reduction + COGS posting.

VL01N creates an outbound delivery from an order, VL02N changes it and VL03N displays it. VL10 and its variants are the delivery due list, which is how deliveries are actually created in a working business: everything due today, processed together, rather than one at a time.

The header and item tables are LIKP and LIPS, and the document flow that links order to delivery to invoice is VBFA.

Three fields on the header explain most delivery behaviour. The shipping point determines where the delivery is processed and is derived from the plant, the shipping conditions on the customer and the loading group on the material, so a new plant or material combination can fail to determine one at all. The route drives transit time and therefore dates. The picking status and goods issue status say how far along it is.

Twenty minutes, and it covers the moment ownership actually changes.

1. Create a delivery from an order with VL01N. Note that the quantity is proposed and not yet picked.
2. Enter the picking quantity. The picking status changes; stock has not moved.
3. Post goods issue. Now inventory falls, an accounting document posts cost of sales, and the delivery is complete operationally.
4. Look at the document flow on the order. The delivery and the goods issue material document are both there.
5. Reverse the goods issue with VL09. Stock returns, a reversing accounting document appears, and the delivery goes back to picked but not issued.

Step three is the answer to a question that comes up constantly: revenue is not recognised here. Goods issue posts cost of sales and reduces inventory. Revenue arrives with the invoice, which is why a shipped and uninvoiced delivery shows cost without income until billing runs. See SD billing for that step.

The delivery integrates SD with inventory (MM stock reduction at goods issue), finance (COGS posting), and warehouse (WM/EWM picking). Goods issue is the pivotal posting, it is when the sale physically and financially leaves the company. Delivery blocks and incomplete deliveries are common things to manage.

Where warehouse management or EWM is in use, the delivery does not pick itself. It generates warehouse tasks, and the picked quantity flows back before goods issue can be posted. That handshake is where most "the delivery is stuck" reports come from, and the queue between the two systems is the first place to look.

• Complete delivery or partial. Whether a customer accepts part of an order or waits for all of it. It is a field on the customer master and it changes how the due list behaves.
• Delivery blocks. At order header, item or customer level, and each one stops the delivery at a different point with a different owner.
• Picking with or without warehouse management. Simple picking on the delivery, or full warehouse tasks. The second is right when the warehouse needs directing.
• Batch determination. Where batches apply, the delivery decides which one ships, and the strategy is usually oldest first or by remaining shelf life.

Individual delivery creation is how the transaction is taught. The due list is how deliveries are actually made, and understanding it explains a lot of day-to-day SD.

VL10 and its variants select everything ready to deliver for a shipping point and a date range, and process it in one run. What appears in that list is the interesting part, because an order that a salesperson expects to ship and cannot find is nearly always failing one of its conditions.

An order line reaches the due list when its schedule line is confirmed, its material availability date has arrived, there is no delivery block at header or item, credit has not blocked it, and the shipping point could be determined. Fail any one and it is invisible rather than flagged.

The list can be run in background as a scheduled job, which is normal in high-volume businesses: deliveries are created overnight for the day's despatches, and the warehouse starts with work already waiting.

Complete delivery customers change the behaviour. Where the customer requires the whole order together, no line ships until all of them can, so one unavailable item holds the rest. That is the customer's instruction rather than a system fault, and it lives on their master record.

Order combination works the other way: several orders for the same customer, shipping point and route can become one delivery, which is what makes consolidated despatch possible. It is also the usual explanation when somebody cannot find their order's delivery, because it is inside somebody else's.

Delivery depends on the availability check that ran at order entry, so understanding it explains most of what does and does not deliver.

The check answers whether the quantity can be promised on the requested date, by looking at current stock plus expected receipts minus existing commitments. What it counts is configurable: some businesses include planned production, others only physical stock.

The result is a confirmed quantity on the schedule line. Confirmation is a promise rather than a reservation, and this is the part people misread. Stock is not set aside. Another order can consume it, and whether that happens depends on the order of processing rather than on who was promised first.

A backorder is an order line confirmed for less than requested, or for a later date. Rescheduling runs periodically and reallocates confirmations as supply changes, which is what moves promises around and occasionally takes stock from one customer and gives it to another with a higher priority.

Advanced ATP adds rules for that allocation deliberately, so scarcity is distributed by policy rather than by processing order. Where supply is regularly short, that is the difference between a system that decides and one that happens.

• Goods issue not posted, sale not completed operationally/financially.
• Picking/WM issues stalling delivery.
• Delivery blocks unresolved.

• Deleting a delivery instead of reversing goods issue. If goods issue posted, reverse it first; the accounting has to be undone in order.
• Shipping point not determined. It is derived configuration, and the message points at the delivery rather than at the determination.
• Assuming picked means shipped. See returns for the reverse flow and sales orders for the step before.

• Creating deliveries one at a time in a business that should be using the due list. It works, it does not scale, and it hides the orders that are failing to appear.
• Treating a confirmed quantity as reserved stock. It is a promise, and another order can take the stock before yours ships.

Posting a goods issue is the easy half, and configuring shipping point determination, routes and picking so a real warehouse can work is the part you do in the course.

The check worth doing first on any delivery question is the document flow on the order. It shows what exists, what is missing and what status each step reached, which usually answers the question before you open the delivery at all.