SCM CHAMPS<\/strong><\/a> sees this pattern regularly in SAP TM assessments \u2014 the deliveries are correct, and the gap sits somewhere else entirely.<\/p>\nThe instinct is to look at the delivery. Something must be wrong with how the order was split.<\/p>\n
Sometimes that’s true. Often it isn’t. In many cases the delivery is exactly what the sales process intended it to be. The gap sits between three layers that are configured separately and rarely reviewed together: how SD splits deliveries, how SAP TM converts those deliveries into Freight Units, and what the planning run is actually permitted to combine.<\/p>\n
Each layer can be individually correct. The plan can still come out wrong.<\/p>\n
One note on language before going further. What the business calls a shipment is a Freight Order<\/strong> in SAP TM. From here on, this article uses Freight Order.<\/p>\nHow delivery grouping actually works, from order to execution<\/h2>\n
The chain is short, and it helps to see it in one line:<\/p>\n
Sales Order \u2192 Outbound Delivery \u2192 Transportation Requirement \u2192 Freight Unit \u2192 Transportation Planning \u2192 Freight Order \u2192 Execution<\/strong><\/p>\nThe outbound delivery<\/strong> defines what needs to be delivered and how the order has been divided up. The split happens for sales and fulfilment reasons \u2014 shipping point, ship-to party, delivery date, route, and other criteria depending on the configuration.<\/p>\nThe transportation requirement<\/strong> is how that delivery enters transportation planning. An outbound delivery becomes a delivery-based transportation requirement, which carries the transportation-relevant data forward.<\/p>\nA Freight Unit<\/strong> is a group of goods that SAP TM treats as a single transportation requirement for planning. It is the smallest unit the system plans and moves, and it carries the constraints planning has to respect.<\/p>\nFreight Unit Building<\/strong> converts those requirements into Freight Units. The logic lives in the Freight Unit Building Rule<\/strong>, which can be determined by condition \u2014 meaning different deliveries can be processed by different rules.<\/p>\nTransportation planning<\/strong> takes the Freight Units and decides which of them can travel together, producing Freight Orders.<\/p>\nOf those stages, two actually decide how transportation demand gets grouped \u2014 Freight Unit Building and planning. This is where most of the confusion starts.<\/p>\n
Freight Unit Building can group in different ways depending on the strategy in the rule. It can create one Freight Unit per business document item, or group all compatible items of a single document, or consolidate as much as possible \u2014 and that last strategy does work across separate business documents, including delivery-based transportation requirements.<\/p>\n
But the strategy is only half the answer. What matters just as much is how<\/em> Freight Unit Building is triggered. Most implementations run it automatically, so Freight Units are created the moment the delivery is saved. In that mode there is nothing to consolidate with yet \u2014 the other deliveries haven’t arrived. Consolidating across documents at this stage requires Freight Unit creation to run as a batch or interactive step instead, which is a deliberate design decision rather than a default.<\/p>\nSo the practical position for most organizations is this: if your Freight Unit Building runs automatically on delivery save, cross-delivery grouping is happening at the planning step, not before it. Confirming which mode you are running takes minutes and tells you which layer to investigate.<\/p>\n
Why SAP deliveries don’t always group the way you expect<\/h2>\n
There are five recurring causes. Most real cases involve more than one.<\/p>\n
The delivery split shapes what transportation planning receives<\/h3>\n
Take a simple example. Same customer, same destination, same week. SD creates two deliveries:<\/p>\n