SAP SD Route Determination — Four Inputs and a Weight Group
The inputs · 0VTC & 0VRF · transit times · redetermination · troubleshooting · Last updated September 2026
The route is the quietest field in the sales order and one of the most consequential. It decides how long the journey takes — and therefore what date you promise the customer, when the warehouse has to pick, and what the freight costs.
This guide covers the four inputs and where each comes from, the fifth one that only applies in the delivery, the configuration behind them, how transit times reach the schedule line, and what to check when the route field is blank or the promised dates are impossible. Written for SAP S/4HANA on-premise and Private Edition; the logic is unchanged from ECC.
On this page
What a route controls
A route is the transport path from your shipping point to the customer. It is not just a label on the delivery: four things hang off it.
Transit time
How long the journey takes. Subtracted from the requested delivery date in backward scheduling to give the goods issue date — which is why a missing transit time promises same-day delivery across the country.
Transportation lead time
How long it takes to organise the transport — booking a carrier, arranging a vehicle. Subtracted from the loading date to give the transportation planning date.
Route stages
Legs of a longer journey, each with its own leg indicator, carrier and duration, for shipments that pass through a hub or change transport mode.
Freight pricing and shipment planning
The route is available as a field in pricing, so freight conditions can be priced per route, and it feeds shipment documents in transportation planning.
The four inputs
Scroll the diagram sideways to see all of it →
Route determination in SAP SD: four inputs in the order, a fifth in the delivery.
Departure zone
Shipping point — country and transportation zone
Where the goods leave from. Each shipping point is assigned a country and a departure zone in customizing, so the route can differ for the same customer served from two warehouses.
Shipping condition
Sales document type, otherwise the customer master
How urgently the goods are wanted. The same code that feeds shipping point determination feeds this one, with the same precedence: the document type wins if it carries a shipping condition.
Transportation group
Material master — Sales: General/Plant view
How the material has to travel: palletised, refrigerated, liquid in a tanker. It lets two materials going to the same customer take different routes.
Transportation zone of the ship-to party
Customer master — general data (address)
Where the goods are going. The zone groups destinations that share transport characteristics — a region, a metro area, a set of postal codes.
Weight group (optional)
Delivery weight, matched to a weight group
A fifth input used only when the route is determined again in the delivery. A full truck and a parcel to the same address are not the same journey.
Two of these you already know: the shipping condition and the material master view are the same ones that drive shipping point determination. Shipping point determination uses the loading group; route determination uses the transportation group. Two fields, one screen, endlessly confused.
Configuration step by step
Define transportation zones
SPRO → SD → Basic Functions → Routes → Route Determination → Define Transportation Zones
Zones are defined per country. Keep them at the granularity your transport really has — one zone per region is usually enough, and a zone per city creates a determination table nobody maintains.
Maintain the zone on the customer master
BP / customer master → general data → address
The ship-to party’s transportation zone is the destination input. A customer created without it cannot determine a route, which is the most common cause of a blank route field.
Set country and departure zone on the shipping point
SPRO → Routes → Route Determination → Maintain Country and Transportation Zone for Shipping Point
This is what turns a shipping point into a departure zone for determination.
Define routes
0VTC
Create the route and maintain transit time, transportation lead time, travel duration and distance, plus the route stages if the journey has legs. These values are what flow into delivery scheduling.
Maintain route determination
0VRF
One table without the weight group (used in the sales order) and one with it (used when the delivery redetermines the route). Each row: departure country and zone + destination country and zone + shipping condition + transportation group → proposed route, plus manual alternatives.
Allow redetermination in the delivery
Delivery type configuration (0VLK)
The delivery type decides whether the route is simply copied from the order or determined again. Redetermining is the usual choice, because the real weight is only known once the delivery exists.
Routes and delivery dates
Backward scheduling runs from the date the customer asked for, and the route supplies the longest leg of it:
If the material availability date lands in the past, SAP switches to forward scheduling from today and proposes a later delivery date. Either way the route’s transit time is doing the arithmetic, and the loading and pick/pack times come from the shipping point. Routes created for determination but left with zero transit time are the reason a warehouse in Noida cheerfully promises same-day delivery to Chennai.
Redetermination and the weight group
At order entry SAP does not know what the shipment will weigh — quantities change, items get rejected, deliveries get split. So route determination runs twice.
In the order, the four inputs give a proposed route. In the delivery, if the delivery type is configured to redetermine it, SAP runs determination again against the table that also includes the weight group — derived from the actual delivery weight. A part-load and a full truck to the same customer can then take different routes, with different transit times and different freight.
Both switches are needed: the delivery type has to allow redetermination, and the determination table with the weight group has to have rows. Projects frequently do one and wonder why nothing changes.
Worked example
A distributor ships from a Noida warehouse. Its zones are simple: N1 for the north, S1 for the south. A customer in Chennai sits in zone S1.
| Input | Value | Read from |
|---|---|---|
| Departure zone | IN / N1 | Shipping point N001 — country and zone in customizing |
| Shipping condition | 01 — standard | Customer master (the order type carries none) |
| Transportation group | 0001 — pallets | Material master, Sales: General/Plant |
| Destination zone | IN / S1 | Ship-to party address |
| Result | Route R-S1-STD · transit 3 days | 0VRF row for this combination |
The customer asks for delivery on the 20th. Backward scheduling subtracts the 3-day transit time to give goods issue on the 17th, then the shipping point’s loading and pick/pack times to give a material availability date on the 16th — the date the warehouse must have the stock ready.
Then the delivery is created for 8 tonnes. The delivery type redetermines the route, the weight falls into the full-truckload weight group, and the route becomes R-S1-FTL with a 2-day transit time and its own freight condition — a direct truck instead of the consolidated milk run. The delivery dates and the freight both change, automatically, because one field on the delivery type said “determine again”.
Troubleshooting
No route is determined on the order item
- ·The ship-to party has no transportation zone in its address
- ·The shipping point has no country and departure zone assigned
- ·The material has no transportation group
- ·No 0VRF row exists for this combination
Fix: Read the four inputs off the document before touching configuration: zone on the ship-to, departure zone on the shipping point, transportation group on the material, shipping condition on the order header. A blank one is your answer.
Delivery dates look unrealistic — everything ships same day
- ·The route has no transit time maintained
- ·The determined route is a default with zero duration
Fix: Open the route in 0VTC and check transit time and transportation lead time. Routes are often created for determination and then never given durations, which quietly breaks scheduling for every order that uses them.
The route does not change in the delivery even for heavy loads
- ·The delivery type copies the route instead of redetermining it
- ·No weight groups are defined, or the determination table with weight group has no rows
Fix: Switch the delivery type to redetermine the route, then maintain the determination table that includes the weight group. Both are needed — one without the other changes nothing.
Freight conditions are missing or wrong
- ·The freight condition’s access does not read the route
- ·The route changed in the delivery but pricing was not redetermined
Fix: Check the access sequence of the freight condition type, and the pricing type in delivery-to-billing copy control if the freight should follow the final route.
Interview questions
What determines the route in a sales order?
Four inputs: the departure zone of the shipping point, the shipping condition, the transportation group of the material and the transportation zone of the ship-to party. The combination is looked up in route determination (0VRF), which proposes a route and may allow manual alternatives.
Where does each input come from?
The departure zone from the shipping point’s country and zone assignment in customizing; the shipping condition from the sales document type, otherwise the customer master; the transportation group from the material master Sales: General/Plant view; the destination zone from the ship-to party’s address.
What is the weight group, and when is it used?
It is a fifth input used only when the route is determined again in the delivery. Route determination has a separate table that includes the weight group, so a heavy delivery can take a different route from a light one to the same destination. It matters only in the delivery, because that is where the real weight is known.
What does the route actually control?
Transit time and transportation lead time, which drive delivery scheduling; the route stages and carriers for multi-leg journeys; freight pricing, when freight conditions are accessed by route; and the shipment documents in transportation planning.
A customer complains that promised dates are impossible. Where do you look?
At the route on the order and its transit time. If the route is right but the transit time is zero, scheduling has nothing to subtract from the requested delivery date, so the goods issue date equals the delivery date. It is a data problem in 0VTC, not a scheduling bug.
Can users change the route manually?
Only to one of the manual alternatives maintained in the determination row, and only if the document allows it. A route not in that row is rejected — the same pattern as shipping point determination.
Where this sits in the SD landscape
Route determination and shipping point determination are the two halves of delivery scheduling in the Order-to-Cash process: the shipping point says who ships and how long preparation takes, the route says how long the journey takes. Both depend on the ship-to party, which comes from partner determination, and both feed the dates that the availability check confirms.
Frequently Asked Questions
What is route determination in SAP SD?
Route determination is how SAP proposes the transport route on a sales order item and delivery. It uses the departure zone of the shipping point, the shipping condition, the transportation group of the material and the transportation zone of the ship-to party, with an optional weight group when the route is determined again in the delivery.
Which transactions are used for routes?
0VTC defines routes with their transit time, transportation lead time and stages. 0VRF maintains route determination, in one table without the weight group and one with it.
Where is the transportation zone maintained?
On the customer master address (general data) for the ship-to party, and in customizing for the shipping point, which supplies the departure zone.
Where is the transportation group maintained?
In the material master, Sales: General/Plant view — the same view that holds the loading group used in shipping point determination.
Why is no route determined in my sales order?
Usually one of the four inputs is missing — most often the transportation zone on the ship-to party or the transportation group on the material — or there is no route determination row for the combination.
How does the route affect delivery dates?
The transit time is subtracted from the requested delivery date in backward scheduling to give the goods issue date, and the transportation lead time is subtracted from the loading date to give the transportation planning date. A route with no times makes every order look shippable immediately.
What is route redetermination in the delivery?
The delivery type can be set to determine the route again instead of copying it from the order. This lets the weight group influence the result, because the actual delivery weight is only known at that point.
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.
“Why is the route blank, and why are the dates wrong?”
Determination questions separate the consultants who have configured a system from those who have read about one. The SD Vault has 230+ depth-graded questions and 38 real configuration scenarios, including route determination and delivery scheduling end to end.
Get Lifetime Access →Or start free with the sample pack, Shipping Point Determination guide, and Order-to-Cash guide.