<aside> <img src="notion://custom_emoji/7f3a86c4-0e4f-8193-9274-00038d571f22/294a86c4-0e4f-8053-a481-007af138f2db" alt="notion://custom_emoji/7f3a86c4-0e4f-8193-9274-00038d571f22/294a86c4-0e4f-8053-a481-007af138f2db" width="40px" />

A Shipping Point is the operational fulcrum that SAP leans on to turn orders into physical movement. It matters because every outbound process you care about depends on this single object being correct: deliveries, picking, packing, loading and carrier dispatch. Use it when you want predictable logistics. Avoid ignoring it unless you enjoy delivery creation failures, misrouted stock or warehouse staff sending you irritated GIFs.

</aside>


A Shipping Point is SAP’s way of saying “nothing moves until I know who is doing the moving”. It isn’t a warehouse, and it isn’t a storage location. It is the execution hub where labour, calendars, cut-off times and dispatch rules converge. If this node is wrong, everything downstream becomes a guessing game.


Why this matters

Think of the Shipping Point as the spine of your logistics body. You can ignore it, but try walking without it.

Whenever SAP needs to create an outbound delivery, it starts with one question:

Which Shipping Point is responsible for moving this thing?

If SAP cannot answer that, it simply shrugs and refuses to create the delivery. No delivery means no picking. No picking means no shipment. No shipment means customer support explaining delays while your planners quietly melt.

A Shipping Point is also where you encode realism: opening hours, labour availability, picking constraints and dispatch patterns. Without these, the system treats your outbound flow as a fantasy novel.


Jargon, made human

If these sound abstract, that’s intentional. SAP tries to compress the madness of real logistics into six terms. Our job is to make them behave.