SAP SD Shipping Point Determination — Trace Every Input
The three inputs · where each comes from · OVL2 · worked example · troubleshooting · Last updated September 2026
Most people can recite the formula: shipping condition plus loading group plus delivering plant gives the shipping point. Far fewer can say where SAP got each of those three values — which is exactly what you need when an order arrives with no shipping point at all.
This guide teaches the investigation rather than the formula: read the values off the order, trace each one back to its source, then check configuration. It covers the determination logic, the configuration and master data behind it, a worked example that is deliberately broken and then fixed, and why a shipping point decides how many deliveries an order produces.
Written for SAP S/4HANA on-premise and Private Edition, where these SPRO paths and transactions apply. The determination logic is unchanged from ECC; in Public Edition the same settings are maintained through configuration apps rather than SAP GUI.
On this page
What a shipping point controls
A shipping point is the organisational unit that processes the delivery: a loading dock, a packing area, a shipping office, a mail room for small parcels. It is the highest-level unit in shipping, and every outbound delivery is managed by exactly one of them.
That makes it more than a label. The shipping point carries the pick/pack time, the loading time and the factory calendar used in delivery scheduling, it drives delivery number ranges and output, and it is an input to storage location determination. Get it wrong and the dates, the paperwork and the warehouse all follow it.
| Unit | Answers | What it is |
|---|---|---|
| Plant | Which location owns the stock? | A plant holds inventory and is assigned to a company code. Valuation, availability and goods issue happen against it. |
| Shipping point | Who physically ships the goods? | The organisational unit that processes the delivery: a loading dock, a shipping office, a mail room. Every outbound delivery belongs to exactly one shipping point. |
| Storage location | Where inside the plant do the goods sit? | Determined after the shipping point, from the shipping point, plant and storage conditions (rule MALA), or from the plant and situation (RETA). |
| Loading point | Which gate or ramp within the shipping point? | An optional subdivision of a shipping point, entered on the delivery for information. It plays no part in determination. |
Plant vs shipping point in one line: the plant owns the stock, the shipping point ships it. One plant can have several shipping points, and one shipping point can serve several plants — as long as it is assigned to them.
The three inputs
Scroll the diagram sideways to see all of it →
Shipping point determination in SAP SD: three inputs, each with its own source, looked up in OVL2.
Shipping condition
Sales document type, or the customer master (sales area data → Shipping tab)
A two-character code for how urgently the customer wants the goods — standard, express, collected by the customer. See the next section: the document type wins when it carries one.
Loading group
Material master → Sales: General/Plant view
How the material has to be handled at the dock — pallets, crane, forklift. Materials that need special equipment can be pushed to a shipping point that has it.
Delivering plant
Customer-material info record, then the ship-to party, then the material master
The plant on the sales order item. It is itself determined — which is why a plant problem so often shows up as a shipping point problem.
Determination happens per item, because the plant and the loading group are per item. The shipping condition is on the order header, so it is the same for all of them.
Where the shipping condition comes from
This is the input people get wrong, because the usual shorthand — “it comes from the customer master” — is only half true. SAP checks in this order:
The sales document type (VOV8)
If the document type carries a shipping condition, that value is used and the customer master is not consulted. This is how a rush order type can force express shipping for every customer.
The customer master — which customer depends on configuration
The shipping condition is read from the sales area data (Shipping tab) of the customer. By default that is the sold-to party, but the sales document type has a setting to read the ship-to party’s record instead — which makes sense when the goods go to many locations with different urgencies. Check that flag before concluding that master data is wrong.
In S/4HANA the customer is a Business Partner, so the Shipping tab lives in the BP sales area data — the field and its behaviour are the same as in ECC.
Where the delivering plant comes from
The plant is itself determined, in this sequence — the first one that has a value wins:
- 01Customer-material info record — VD51 — the most specific source: this customer, this material.
- 02The ship-to party’s customer master — The delivering plant on the sales area data.
- 03The material master — The delivering plant on the Sales: Sales Org 1 view.
If none of them has a plant, the item has no plant — and with no plant there can be no shipping point, no availability check and no delivery. A missing shipping point is often really a missing plant, so check the plant field on the item before anything else.
Worth knowing: the plant on the item must also be allowed for the sales organisation and distribution channel. An order can find a plant in master data and still reject it because that assignment is missing — common when a new plant goes live.
Configuration and master-data checks
Define the shipping point
Enterprise Structure → Definition → Logistics Execution → Define, copy, delete, check shipping point
Create the shipping point and set its factory calendar, working times and the times used in delivery scheduling (pick/pack and loading time). These feed the dates on the schedule line.
Assign the shipping point to the plant
Enterprise Structure → Assignment → Logistics Execution → Assign shipping point to plant
A shipping point can only serve plants it is assigned to. Missing this assignment is the most common reason a correctly configured determination entry still produces nothing.
Maintain shipping point determination
OVL2 — Shipping point determination
One row per combination of shipping condition + loading group + plant, holding the proposed shipping point and optional manual alternatives.
Maintain the shipping condition
Customer master (BP, sales area data → Shipping tab) and VOV8 for the document type
Set the customer default, and decide whether any sales document type should force its own shipping condition — for example a rush order type that always ships express.
Maintain the loading group
MM02 → Sales: General/Plant view
The loading group is plant-specific. Extending a material to a new plant without maintaining this view is a classic cause of a missing shipping point for that plant only.
Worked example: break it, then fix it
A distributor in Noida ships from plant 1000 through shipping point N001. An order for a standard pallet material determines like this:
| Field | Value | SAP read it from |
|---|---|---|
| Shipping condition | 01 — Standard | Customer master of the Noida distributor (Shipping tab) |
| Loading group | 0001 — Pallets | Material master, Sales: General/Plant view for plant 1000 |
| Delivering plant | 1000 — Noida DC | Material master (no customer-material info record exists) |
| Result | Shipping point N001 | OVL2 row 01 + 0001 + 1000 → N001 |
Now break it in a training system. The distributor starts selling a bulky item that needs a crane, so the material is given loading group 0002 instead of 0001 — and nobody adds the matching row to OVL2.
The order is entered as usual, but the shipping point field on the item stays empty and the item is incomplete. Without a shipping point the delivery cannot be created, so the item never reaches the delivery due list. Nothing in the message points at the loading group.
- ·Order item: plant 1000 is filled — so the plant is not the problem.
- ·Order header: shipping condition 01 is filled — not that either.
- ·Material master, Sales: General/Plant view for plant 1000: loading group 0002.
- ·OVL2: rows exist for 01 + 0001 + 1000, but none for 01 + 0002 + 1000.
The fix: add the OVL2 row for shipping condition 01 + loading group 0002 + plant 1000 and propose the shipping point that has the crane — say N002, assigned to plant 1000. Re-enter the item: the shipping point is proposed. Existing orders keep the empty field until the item is re-determined, so the open ones have to be touched.
That is the lesson worth keeping: the failure was caused by a master data change, and fixed in configuration. Any change to a loading group, a shipping condition or a plant quietly asks for a new determination row.
Why the shipping point splits deliveries
An outbound delivery is managed by exactly one shipping point, and the shipping point sits in the delivery header. So two items that determined different shipping points cannot travel in the same delivery — SAP creates two.
This surprises people who expected one order to give one delivery. The usual causes are two items with different plants, or the same plant with different loading groups — a palletised item and a crane item, for instance, leaving from different docks.
If the business insists on one delivery, the answer is not to force the split away but to make the items determine the same shipping point: align the loading groups, or add a determination row that sends both to one shipping point capable of handling them.
Troubleshooting
No shipping point is proposed on the order item
- ·No OVL2 row for this shipping condition + loading group + plant combination
- ·The shipping point is not assigned to the delivering plant
- ·The loading group is blank — the Sales: General/Plant view was never maintained for this plant
- ·No shipping condition on the order, because neither the document type nor the customer master has one
- ·No delivering plant on the item, so there is nothing to determine against
Fix: Read the three values off the order item first (plant on the item, shipping condition on the header, loading group on the material for that plant). The empty one is your answer. Only when all three are filled does the problem move to the OVL2 table or the plant assignment.
The shipping point is not the one you expected
- ·The sales document type carries its own shipping condition and overrides the customer master
- ·The shipping condition comes from the ship-to party, not the sold-to party (a flag on the document type)
- ·The order was created with reference, copying an older shipping condition
- ·Somebody changed the value manually on the order
Fix: Compare the shipping condition on the order header with the customer master. If they differ, check VOV8 for the document type before suspecting master data.
It worked for one plant but not another
- ·The loading group is maintained per plant
- ·OVL2 rows are per plant
- ·The shipping point is not assigned to the second plant
Fix: Determination is plant-specific end to end. When a new plant or distribution centre goes live, the three plant-dependent pieces — material view, OVL2 rows and the plant assignment — all have to be created.
The user cannot change the shipping point manually
- ·Only the proposed shipping point is maintained in the OVL2 row, with no manual alternatives
Fix: Add the alternative shipping points to the same OVL2 row. Users can then pick any of them; anything not listed is rejected.
One order produces several deliveries
- ·Items ended up with different shipping points — usually different plants or different loading groups
Fix: Expected behaviour: a delivery belongs to exactly one shipping point, so items with different shipping points cannot share one. If the business wants a single delivery, the items must be made to determine the same shipping point.
Interview recap
How is the shipping point determined in a sales order?
From three inputs on the item: the shipping condition (from the sales document type or the customer master), the loading group (from the material master, Sales: General/Plant view) and the delivering plant. The combination is looked up in shipping point determination (OVL2), which proposes a shipping point and may list manual alternatives.
What is the difference between a plant and a shipping point?
A plant owns the stock — it is where the material is valuated and where goods issue posts. A shipping point is the unit that processes the delivery physically. One plant can have several shipping points, and a shipping point can serve several plants it is assigned to.
Where does the shipping condition come from?
If the sales document type has a shipping condition, it wins. Otherwise it comes from the customer master sales area data, and a flag on the document type decides whether the ship-to party’s record is read instead of the sold-to party’s.
How is the delivering plant determined?
In sequence: the customer-material info record, then the ship-to party’s customer master, then the material master (Sales: Sales Org 1 view). If none of them has a plant, the item has no plant — and then no shipping point either.
Can a user change the shipping point on the order?
Only to one of the manual alternatives maintained in the same OVL2 row. The row holds one proposed shipping point plus the alternatives that are allowed for that combination.
Why did one order create two deliveries?
Because the items determined different shipping points. A delivery is managed by exactly one shipping point, so items belonging to different shipping points must be delivered separately — just as they must for different plants or different ship-to parties.
What else does the shipping point control?
Delivery scheduling times (pick/pack and loading time) and the factory calendar used for those dates, the number ranges and output for deliveries, and it is an input to storage location determination.
A new distribution centre went live and orders have no shipping point. Where do you look?
At the three plant-dependent pieces: the material’s Sales: General/Plant view for the new plant (loading group), the OVL2 rows for that plant, and the assignment of the shipping point to the plant in the enterprise structure.
Where this sits in the SD landscape
Shipping point determination is the hinge between master data and delivery execution in the Order-to-Cash process. The customer data behind it lives on the Business Partner, the confirmed quantities and dates come from the availability check, and whether an item is delivery-relevant at all is decided by item category determination.
Frequently Asked Questions
What is shipping point determination in SAP SD?
It is the automatic proposal of the shipping point on a sales order item, based on the shipping condition, the loading group of the material and the delivering plant. The combination is maintained in transaction OVL2.
Which transaction is used for shipping point determination?
OVL2. Each row combines a shipping condition, a loading group and a plant, and holds the proposed shipping point plus optional manual alternatives.
Why is no shipping point determined in my sales order?
Usually one of the three inputs is missing — no shipping condition on the order, no loading group on the material for that plant, or no delivering plant on the item — or there is no OVL2 row for the combination, or the shipping point is not assigned to the plant.
What is the difference between a shipping point and a plant?
The plant owns and values the stock and is where goods issue posts. The shipping point processes the delivery. A plant can have several shipping points, and a shipping point can serve several plants it is assigned to.
Where is the loading group maintained?
In the material master, Sales: General/Plant view. It is plant-specific, so a material extended to a new plant needs the view maintained again for that plant.
Can the shipping point be changed manually in the sales order?
Yes, but only to a manual alternative maintained in the same OVL2 row. Anything else is rejected.
Can one delivery have items from two shipping points?
No. A delivery is managed by exactly one shipping point, so items with different shipping points are delivered separately.
Does the shipping point affect delivery dates?
Yes. The pick/pack time, loading time and factory calendar of the shipping point feed delivery scheduling, which is how the material availability date and goods issue date are calculated.
Written by
Rahul Narain Saxena
SAP SD Solution Architect with 17+ years of hands-on implementation experience across SAP ECC and S/4HANA. Every guide on The SD Vault is written from live project experience, not summarised from documentation.
“The order has no shipping point. What do you check?”
Determination questions are the fastest way for an interviewer to tell whether you have configured a system or only read about one. The SD Vault has 230+ depth-graded questions and 38 real configuration scenarios that walk these paths end to end.
Get Lifetime Access →Or start free with the sample pack, Order-to-Cash guide, and Item Category Determination guide.