Freight Unit Building Rules in SAP TM: Design Decisions and Pitfalls
Many SAP TM planning problems I have been called in to fix started months earlier, in a screen nobody looked at again after the blueprint: the freight unit building rule (FUBR). Planners complain that the optimizer is slow or that one sales order produces twelve freight units for no visible reason. The cause is usually the same: the FUBR was copied from a template and never designed for the real order profile.
The freight unit is the smallest object that planning, carrier selection and tendering can move. Whatever granularity the FUBR produces, the planner and the optimizer have to live with. Below are the decisions that matter and the pitfalls we see on projects.
1) What the FUBR actually controls
A FUBR takes a transportation requirement on /SCMTMS/TRQ (an OTR or DTR from a sales order or delivery, or a forwarding order) and turns its items into one or more freight units on /SCMTMS/TOR. The main settings are:
- Freight unit type – the document type the new freight units get.
- Consolidation strategy – how items are grouped into freight units.
- Critical quantity – the measure (for example gross weight, volume or pieces) used to decide whether and how items are split.
- Split quantity and item split flag – the maximum size of one freight unit and whether a single item may be divided to respect it.
- Incompatibility settings – which items must never land in the same freight unit.
In S/4HANA the rule itself is master data maintained in the application menu (Application Administration > Planning, or the corresponding Fiori app). Freight unit types are customizing under SPRO > Transportation Management > Planning > Freight Unit > Define Freight Unit Types. Menu labels have moved between TM 9.x and S/4HANA, so verify them in your release.
2) Choosing the consolidation strategy
SAP offers three strategies, trading planning flexibility against the number of objects to plan.
| Strategy | Result | Good fit | Typical pitfall |
|---|---|---|---|
| Per request item | One freight unit per TRQ item (further split by split quantity if allowed) | Items with different handling needs; parcel and LTL where items travel separately | An order with 40 lines becomes 40 freight units; cockpit and optimizer load grows fast |
| Per request (compatible parts) | Items of one TRQ grouped as long as they are compatible | Most outbound SD scenarios: one delivery, one pick-up, one consignee | Forgetting that incompatibilities are the only thing that separates items |
| Consolidate as much as possible | Compatible items grouped across several TRQs | High volumes of small orders to the same customer and date | One order change touches an FU shared with other orders; harder to trace and cancel |
Our default on SD-integrated projects is per request (compatible parts), with incompatibilities to separate what must travel separately. Per request item is the fallback when the business cannot express its separation rules as incompatibilities.
Pitfall: choosing per item “to be safe”
Per item feels safe in the blueprint because nothing is grouped wrongly. In production, planners drag dozens of tiny freight units per order and the optimizer has many more objects to sequence. If only one product group needs separation, solve it with an incompatibility or a second FUBR determined by condition, not by switching the whole scenario to per item.
3) Critical quantity, split quantity and item split
The critical quantity defines which measure the system looks at when it splits. The split quantity is the upper limit of one freight unit in that measure. With item split allowed, an item exceeding the split quantity is divided across several freight units; without it, the item stays whole and only grouping is limited.
SAP’s documentation uses a simple example: with a split quantity of 1 m³ and items of 0.06 m³ each, one freight unit takes at most 16 pieces.
Why this matters
- A split quantity larger than your vehicle capacity produces freight units that fit no truck.
- A split quantity much smaller than a typical order fills the cockpit with fragments.
- A good starting point is the capacity of the smallest vehicle regularly used for that flow, minus a margin for loading reality.
Pitfall: the critical quantity is not filled
If you split on gross weight but materials have no gross weight, the split cannot work as designed. We have seen sales items with pieces but no weight, and the FUBR quietly produced one large freight unit. Either fix master data (weights, volumes, unit conversions) or use a quantity that is reliably filled, as part of the FUBR design and not after the first failed planning run.
4) Incompatibilities: the right way to keep items apart
All three strategies respect hard constraints and incompatibilities. That makes incompatibilities the cleanest way to express rules such as “dangerous goods never with food” or “chilled items separate from ambient”.
Incompatibility definitions and settings are maintained in the application menu (Application Administration > Planning > General Settings in S/4HANA; verify the location in your release). In the definition you choose the freight unit building area and the attribute to compare; the incompatibility settings are then assigned to the FUBR.
Solution pattern
- Write the business rule in one sentence (“material group A never in the same FU as material group B”).
- Find a field on the TRQ item that carries the attribute reliably. If none exists, fill a custom field on the TRQ item first.
- Create the incompatibility definition for freight unit building on that attribute.
- Assign it to incompatibility settings, and those to the FUBR.
- Test with a TRQ containing both groups and check that two freight units are created.
A freight unit building incompatibility only governs FU building. If the two freight units must also not share a vehicle, you need a separate incompatibility in the vehicle scheduling area.
5) How the FUBR is determined
The system looks for the rule in a fixed sequence:
- A condition for FUBR determination, if one is assigned (where depends on the integration scenario and release, so verify it in your system).
- The FUBR maintained in the logistics integration profile (S/4HANA internal integration) or in the document type.
- Standard settings if neither is maintained.
Conditions let you serve different flows with different rules, for example by shipping point or gross weight read from the TRQ.
Pitfall: the condition silently returns nothing
When the condition finds no matching row, the system falls back to the next level and users see freight units that “ignore” the FUBR. Test conditions with real data first. For debugging, SAP knowledge base articles on FUBR determination reference method DETERMINE_FUB_RULE of class /SCMTMS/CL_FU_BUILDER_CORE as a breakpoint candidate; verify it exists in your release. Also test manual splits: the FUBR can be redetermined for the new part, and a quantity-based condition may then pick a different rule.
6) How a bad FUBR hurts planning later
| Symptom in planning | Likely FUBR cause | What to check |
|---|---|---|
| Optimizer runtime explodes | Per item strategy or very small split quantity | Average number of FUs per order |
| FUs do not fit any vehicle | Split quantity above vehicle capacity, or item split not allowed | Split quantity vs. resource capacity; item split flag |
| Incompatible goods on one FU | Incompatibility not assigned, or attribute empty | Incompatibility settings on the FUBR; field value on TRQ item |
| Different FU types for the same flow | Determination falls back to another level | Condition result; logistics integration profile |
A changed FUBR is applied when freight units are built, so existing freight units normally keep their old structure. Plan the cut-over: let old freight units run out, or rebuild them while still unplanned, and test that behavior in your release first.
7) Design checklist before go-live
- One sentence per flow describing what a freight unit represents (an order, a pallet, a delivery line).
- Strategy chosen per flow; per item only where grouping is truly impossible.
- Critical quantity filled in master data, split quantity checked against the smallest regular vehicle.
- Incompatibilities assigned and tested with mixed orders.
- Determination tested at every level, including the fallback, manual split and order change.
Takeaways
The FUBR decides the granularity of everything that happens after it, so design it from the order profile, not from a template. Per request with incompatibilities covers most SD-integrated flows better than per item. Split and critical quantities only work if master data supports them, and determination fallbacks explain most “the FUBR is ignored” tickets. Share your own FUBR stories in the comments.
