SAP Shipping

Shipping manages the physical dispatch: creating and processing deliveries, picking and packing the goods, posting goods issue, and handing over to transportation. Shipping points (organizational units) determine where and how deliveries are processed, and route determination helps plan how goods reach the customer.

• Shipping point: where deliveries are processed.
• Picking & packing (integrating WM/EWM, handling units).
• Goods issue completing dispatch.
• Route & transportation handover (to TM where used).

This is the piece of shipping configuration that causes the most support calls, and it is a three-field derivation worth memorising.

The shipping point is determined from the shipping conditions on the customer master or the order type, the loading group on the material master, and the delivering plant. Those three together resolve to a shipping point through a configuration table.

The consequence is that a delivery fails to determine a shipping point whenever a new combination appears: a new plant, a new material with an unfamiliar loading group, or a customer with shipping conditions nobody configured. The error names the delivery, so people look at the delivery, and the answer is three levels away in master data and configuration.

The shipping point then carries its own working times and determines the scheduling of picking, loading and transport, which is how it ends up affecting promised dates as well as processing.

Half an hour, and it explains why a customer is promised the date they are promised.

1. Create an order for a material with stock and look at the schedule line. There is a requested delivery date and a confirmed one.
2. Open the shipping tab on the item. Material availability date, transportation planning date, loading date, goods issue date, delivery date.
3. Read them backwards from the delivery date. The system worked back through transit time from the route, loading time and pick pack time from the shipping point, to decide when the material must be available.
4. Change the route to one with a longer transit time and recreate the order. Every earlier date moves.
5. Now remove the stock so availability fails. The confirmed date moves out to when stock is expected, and the whole chain recalculates forward from there.

Backward scheduling is the default and forward scheduling is the fallback when the dates would be in the past, which is why an order placed for tomorrow behaves differently from one placed for next month.

Shipping integrates SD with warehouse management (picking), inventory/finance (goods issue), and transportation management (freight). It turns the delivery document into physical movement of goods, and its efficiency directly affects customer service and delivery performance.

Shipping is also where output reaches the outside world: delivery notes, packing lists, labels and electronic despatch advices are all output types on the delivery, determined by the same condition technique as pricing. A delivery that processed correctly and produced no paperwork is an output determination problem, not a shipping one. See SD output.

• How many shipping points. One per physical dispatch area with its own working times. Too few and scheduling is wrong for some flows; too many and the determination table becomes unmanageable.
• Routes and transit times. These drive promised dates, so optimistic transit times produce promises the business cannot keep.
• Packing. Whether handling units are used, which gives traceable pallets and cartons and adds a step to every despatch.
• Where transport planning sits. Simple route determination in SD, or full transport management with its own planning and carriers.

Packing is optional in SAP and it is the difference between knowing you shipped forty units and knowing which pallet they left on.

A handling unit is a physical package: a carton, a pallet, a container. It has its own number, it holds materials or other handling units, and it carries its own weight and volume. A pallet containing six cartons containing forty units is three levels of nesting, and each level is identifiable.

Packaging materials are the pallets and cartons themselves, and they are materials in their own right, which means they can be stocked, valued and charged for.

What packing enables is the reason to bother. Labels can be printed per handling unit with a scannable identifier. A despatch advice sent to the customer can list exactly what is on each pallet, which is a requirement in retail supply. Traceability improves, because a recall can identify which pallet went where. And loading can be checked, since the delivery knows how many handling units should be on the vehicle.

The cost is a step in the process. Somebody has to pack, or the system has to pack automatically from a packing instruction, and getting that instruction right for every material combination is real configuration work.

Where a business ships pallets to retailers, packing is not optional in practice because the customer requires the advice. Where it ships parcels through a carrier who provides their own labels, it often adds little. That distinction is the decision. See returns for what happens when the pallet comes back.

Shipping decides when goods leave. What happens between leaving and arriving is transport, and the handover between them is worth understanding.

The route on a delivery carries a transit time, and that time feeds the date scheduling described above. Routes are determined from the shipping point, the destination country and region, the shipping condition and the transportation group on the material.

A shipment document groups deliveries onto a vehicle with stages, a carrier and planned dates. Where transport is simple, this is enough: a shipment per truck, costs entered against it, and freight settled from there.

Where transport is a business in itself, a dedicated transport management system takes over the planning, and the delivery becomes an input to it rather than the place planning happens.

The practical join to watch is dates. Shipping schedules a goods issue date from the route's transit time; transport plans an actual departure. When those two disagree, deliveries are ready before or after the vehicle, and the symptom is either goods sitting on a dock or a truck waiting. Aligning them is the point of planning the two together rather than separately.

• Shipping-point configuration errors, wrong delivery processing.
• Picking bottlenecks delaying dispatch.
• Goods issue not posted, incomplete shipping.

• Blaming availability for a date the scheduling produced. Read the shipping tab before concluding there is no stock.
• Working times left at defaults. A shipping point that claims to work twenty-four hours schedules dispatches nobody will load.
• Route determination that never finds a route. See the delivery for the document all of this configures.

• Adding a shipping point per team rather than per physical dispatch area. Determination becomes unmanageable and scheduling stops reflecting how goods actually leave.
• Transit times that were optimistic on day one. They become promises, and the business is judged on them.

Creating a delivery is the easy half, and configuring shipping points, routes and scheduling so the dates a customer is given are the dates they get is the part you do in the course.

If one thing is worth remembering: when a date looks wrong, read the shipping tab before questioning availability. The dates were calculated backwards from the delivery date through transit, loading and pick pack times, and the answer is nearly always one of those.