SD to SAP TM Integration: Order-Based vs Delivery-Based (OTR vs DTR)
Almost every SAP TM project hits the same question in the first blueprint workshop: does transportation planning start from the sales order or from the outbound delivery? It sounds like a small integration detail. In practice it decides when freight units exist, who is allowed to create deliveries, how much rework a sales order change causes, and whether the planners trust the cockpit at all.
Standard SAP gives you both options, order-based transportation requirements (OTR) and delivery-based integration (DTR in side-by-side TM, delivery-based freight units in embedded S/4HANA TM). It does not tell you which one fits your business. Teams that activate both “just in case” usually end up with duplicate freight units, planning that is thrown away when the delivery arrives, and a long list of tickets in hypercare.
Below is how we make the decision on projects, the settings to check and the traps we have seen.
1) OTR and DTR: what actually gets created
Both are transportation requirements on the /SCMTMS/TRQ business object family, but they behave differently depending on the deployment:
- OTR – created when a TM-relevant sales order (or purchase order / stock transport order) is saved. It carries items, quantities, schedule-line dates, locations and Incoterms. Freight units are built from it with the freight unit building rule (FUBR).
- DTR (side-by-side TM) – created from the outbound delivery sent from ERP. Freight units are built from the DTR, and if an OTR existed before, TM reconciles the delivery against the order-based freight units.
- Embedded TM in S/4HANA – there is no separate DTR document. Freight units are created directly from the delivery, and the FUBR for that is taken from the logistics integration profile.
Why this matters
The object that creates the freight unit is the object whose changes drive replanning. If the FU comes from the order, every sales order change (quantity, date, ship-to) flows into planning. If it comes from the delivery, planning only starts once the warehouse side has committed, and earlier visibility is lost.
2) Three integration patterns we see in projects
Rather than “OTR or DTR”, it helps to talk about three patterns:
- Order-based planning, TM creates deliveries (delivery proposal). The OTR creates freight units, planners build freight orders, and TM proposes deliveries that respect the planning result (one delivery per freight order assignment, dates from the freight order). TM leads; ERP follows.
- Order-based planning, deliveries created in ERP. Planning starts on the OTR, but shipping still runs VL10 or delivery due list jobs. The delivery then updates or replaces the order-based freight units. This is the most common pattern and the one with the most reconciliation issues.
- Delivery-based only. The sales order is not TM-relevant (or is sent without planning). Freight units are built from the delivery. ERP and the warehouse lead; TM plans what has already been released for shipping.
3) Decision table
We use a table like this in the blueprint to make the decision explicit and documented per order type or business line:
| Criterion | Order-based (OTR) | Delivery-based |
|---|---|---|
| Lead time between order and pickup | Days or weeks; carriers must be booked early | Short; same-day or next-day shipping |
| Stability of sales orders | Stable quantities and dates | Frequent changes until picking |
| Who decides consolidation | Transport planners | Warehouse / shipping office |
| Need for capacity forecast | High (tendering, booking ocean/air) | Low |
| Delivery creation | Ideally from TM (delivery proposal) | ERP (VL10, VL01N, EWM) |
| Volume of FU rework on changes | Higher, must be monitored | Lower |
Mixing patterns is valid: export orders can be order-based while domestic replenishment is delivery-based, controlled by the assignments described next.
4) Configuration walk-through (embedded S/4HANA TM)
The names below are from embedded TM in S/4HANA; menu positions move slightly between releases, so verify the exact paths in your release.
Step 1 – Control keys for document integration
In SPRO under Transportation Management > Integration > Logistics Integration, define a control key for document integration. The control key holds the flags that decide whether the sales order is transferred to TM, whether the outbound delivery is transferred, and whether TM is allowed to create deliveries. Create one key per pattern instead of one key that switches everything on.
Step 2 – Logistics integration profile
In the same area, define the logistics integration profile. This embedded-only object holds, among other things, the FUBR for order-based freight units, the FUBR for delivery-based freight units and the OTR type. In recent releases it also carries the transportation duration determination profile used for master-data-based sales order scheduling.
Step 3 – Activate TM for sales documents
Assign the control key and the logistics integration profile to the sales document. The determination key is a combination of sales organization, distribution channel, division, sales document type and shipping condition (verify the exact key fields in your release). This is where you split export from domestic, or a “planned” shipping condition from an “ad hoc” one.
Step 4 – Delivery side
Check that the outbound delivery types used by these orders are TM-relevant and that the delivery FUBR in the profile is compatible with the order FUBR (see pitfalls). If TM should create deliveries, check that the delivery type determined from the sales document type is the one you expect, because TM uses the standard SD delivery creation logic underneath.
Test checklist
- Create a sales order and confirm in the document flow that an OTR and freight units exist.
- Change quantity and requested delivery date; check that the freight units are adjusted and not duplicated.
- Create the delivery from TM (or in VL10, depending on the pattern) and confirm which freight units remain assigned to the freight order.
- Repeat with the shipping condition that should not be TM-relevant.
5) Impact on freight unit building and delivery proposals
The FUBR decides how many freight units exist per order (per item, per order, per schedule line with split quantities). With delivery proposals, TM proposes deliveries based on how freight units are assigned to freight orders or bookings: freight units of different orders can only end up in the same delivery when they are on the same freight order, and an order whose units are spread over several freight orders gets several deliveries. Dates come from the freight order, or from the freight units if they are not planned yet.
Two consequences for design:
- A FUBR that splits too finely (for example one FU per schedule line with a small split quantity) produces many small deliveries and annoys the warehouse.
- Delivery creation needs the OTR to be free of delivery blocks and the SD document to expect a delivery. If an order type has a delivery block by default, the delivery proposal silently produces nothing. Report
/SCMTMS/DLV_BATCHcan create proposals in background; verify its availability and selection options in your release.
6) Pitfalls we have seen
Different FUBRs for order and delivery
If the order FUBR consolidates per order and the delivery FUBR builds per item, the delivery cannot be matched cleanly to the planned freight units. The result is new, unplanned freight units next to the planned ones. Keep both rules aligned in consolidation level and units of measure.
Deliveries created outside the agreed pattern
In pattern 1, a user running VL10 “to help” bypasses the planning result. Restrict this with authorizations or batch job variants, and agree on it with shipping before go-live.
Shipping condition coming from the customer master
Because TM relevance depends on the shipping condition, a master data change on the customer can silently move orders from order-based to delivery-only. Include the shipping condition in your monitoring.
Incoterm changes and stage profiles
Changing the Incoterm on the sales order updates the OTR, but the stage profile may not be redetermined. An SAP knowledge base article describes this for S/4HANA 1709 onward; verify the behavior in your release before relying on Incoterm changes.
Takeaways
- Choose the integration pattern per business line and document it in a decision table, not globally.
- Use separate control keys and logistics integration profiles per pattern, determined by sales document type and shipping condition.
- Keep the order and delivery FUBRs aligned, or the delivery will create unplanned freight units next to the planned ones.
- If TM plans on the order, let TM create the deliveries; otherwise the planning effort is lost at the warehouse door.
Which pattern did your project choose, and what made you change it later? Let me know in the comments.
