From a transportation requirement to an executable freight order - how the core document of SAP TM actually comes together, and where it tends to break.
Freight order management is the spine of SAP Transportation Management. Almost everything else in TM - planning, carrier selection, charge calculation, settlement, execution visibility - either feeds the freight order or hangs off it. Get the freight order flow right and the rest of TM has something solid to stand on. Get it wrong and you feel it in every downstream process. This is a practitioner's map of how a freight order comes into being, what the moving parts are, and where projects most often stumble.
A freight order is the executable transportation document - the object you subcontract to a carrier, tender, cost, settle, and track. It is not where the process starts; it is the result of turning a demand for transportation into something a carrier can act on. Before the freight order exists, TM has already translated a business document into a transportation requirement, broken that requirement into plannable units, and planned those units onto capacity. The freight order is where that planning becomes a commitment.
1) Transportation requirement - a sales order or delivery in ERP / S/4HANA generates a transportation requirement in TM: an OTR (order-based) or DTR (delivery-based) requirement.
2) Freight unit building - TM splits the requirement into freight units using freight unit building rules (FUBR). The freight unit is the smallest plannable, independently movable piece.
3) Planning - in the transportation cockpit, freight units are assigned to capacity, manually or through the optimizer. The output is the freight order (or freight booking).
4) Carrier selection and tendering - the freight order gets a carrier, by strategy-based selection or by tendering (direct, broadcast, or peer-to-peer).
5) Execution - statuses, events, and proof of delivery flow back, increasingly through SAP Business Network for Logistics and Global Track & Trace.
6) Charge calculation and settlement - the freight order is costed against calculation sheets and rate tables, then settled.
For land transport (road, rail) you plan into freight orders; for ocean and air you plan into freight bookings, which model capacity you have reserved on a carrier's schedule - a vessel sailing, a flight. Same backbone, different document, different execution rhythm. Knowing which one your scenario needs shapes your document types and your customising from day one.
The failures are rarely exotic. The freight-unit building rule is set once, early, and never revisited, so units end up too coarse to plan well or too granular to settle cleanly. Document and freight order types multiply until no one can say which is used when. Integration between ERP / S/4 and TM - embedded in S/4HANA or decentralised - is treated as plumbing rather than design, and status mismatches surface in production. And planning is tuned in isolation from settlement, so beautifully optimised freight orders turn out to be painful to cost. Good freight order management is mostly the discipline of designing these seams deliberately.
Keep going
Freight order management touches almost every other cluster in this hub. The natural next reads are carrier selection and tendering, and charge calculation and freight settlement - where the freight order stops being a plan and starts being money.