TM 404 · SOLUTION WORKBENCH
How do you design and prove Basic TM?
A Basic TM workbench connects delivery-based demand, Freight Unit building, feasible manual planning, Freight Order execution, freight charges, FSD, PO/SES evidence, supplier invoice verification, and FI posting. Basic TM / Transportation Management terminology varies by SAP release and licensing material; this page uses Basic TM for the minimum delivery-based scope.
FOUNDATION
Confirm the operating ground before demand enters TM
Keep this as a prerequisite strip, not a second implementation methodology.
- 01SCOPETM Scope / License
Confirm Basic TM scope and license boundaries before adopting planning functions that may require Advanced TM.
- 02STRUCTUREOrganizational model
Confirm embedded/internal integration, shipping and receiving ownership, and which SD/MM/LE delivery documents enter TM.
- 03PARTNERBusiness Partner / Carrier
Maintain carrier business partner data and purchasing readiness where settlement will create downstream evidence.
- 04NETWORKLocations / Zones
Locations, zones, lanes or route context determine whether the plan has a reachable transport network.
- 05CAPACITYResources / Equipment
Means of transport, resource and equipment capacity make the Freight Order feasible rather than merely created.
- 06INTEGRATIONLogistics Integration
Integration profiles, queues, messages and source-document triggers preserve one demand-to-settlement chain.
SOLUTION ARCHITECTURE
Foundation, demand, plan, execute, cost and settle
Keep the design readable at the control-group level. Detailed configuration recipes belong beside the approved scenario, not in this overview.
Delivery / Business Document -> Transportation Relevance -> Control Key -> Logistics Integration Profile -> Freight Unit Building Rule (FUB Rule) -> Freight Unit.
Design questionWhich delivery-based demand enters TM, and how should the Freight Unit Building Rule create plannable Freight Units?Core Basic TM: Locations -> Zones -> Planning Profile -> Resource / Capacity -> Manual Planning -> Freight Order -> Carrier Assignment.
Advanced / license-checkIncompatibilities, optimizer-driven planning, automated carrier selection, tendering, route optimization, advanced load planning, and vehicle scheduling require explicit scope and license validation.Transport Network: Locations -> Zones / Lanes / Route context. Capacity: Means of Transport / Resource -> Capacity. Partner: Carrier Business Partner.
Design questionCan Freight Units consume network, capacity, schedule, and carrier master data without planner guesswork?Freight Order -> Carrier -> Stops -> Delivery / Warehouse Handoff -> Loading / GI / GR Evidence -> Events / Status.
Deployment boundaryExact TM-warehouse status propagation depends on the selected integration model, deployed scope, and licensed capability.Freight Order -> Freight Agreement / Rates -> Charge Calculation -> Freight Settlement Document -> PO + Service Entry Sheet -> Supplier Invoice Verification -> FI.
Design questionHow does the transport result become an expected, settled, invoice-verified, and posted carrier cost?Demand -> Plan -> Movement -> Cost -> Accounting.
Proof questionCan one delivery demand become one explainable Freight Unit, one feasible Freight Order, one evidenced movement, and one reconciled freight cost?PROJECT MOMENT
Prove one connected Basic TM solution
Use representative delivery-based demand to prove the full sequence: foundation data is ready, the right Freight Units are built, manual planning can create a feasible Freight Order, execution evidence remains connected, and expected freight cost reaches settlement.
- Demand produces the intended Freight Units
- Freight Units plus network, capacity, schedule, and carrier data create a feasible Freight Order
- Freight Order, delivery, warehouse hand-off, loading/GI/GR evidence, events, and statuses remain connected
- Charges, FSD, PO/SES, supplier invoice verification, and FI reconcile
- Failed paths are classified by layer: demand, plan, execute, cost, settle, or accounting
FAILED-PATH LENS
Classify the first broken layer
Keep the existing failure discipline: do not fix a downstream document until the owning layer is proven.
Check transportation relevance, control key, integration profile, FUB Rule, source changes, and messages.
Check location, zone, route context, planning profile, resource, equipment, schedule, capacity, and unplanned demand.
Check Freight Order stops, carrier assignment, warehouse readiness, loading, GI/GR, events, status propagation, and failed messages.
Check freight agreement, rate, calculation sheet, scale, quantity, distance, accessorial input, currency, and validity.
Check FSD, PO/SES, supplier invoice verification, account assignment, tax, period, match status, and FI posting logs.
Move from solution design into testing, cutover, adoption, and stabilization.
IMPLEMENTATION PROOF
Prove the normal journey and the controlled recovery
Keep the evidence with the scenario so the project can distinguish a design gap from a data, integration, or operating failure.
- 01Representative demandDelivery relevance, freight-unit building, planning, and Freight Order creation are explainable.
- 02Physical hand-offWarehouse readiness, loading or receipt, transport events, and related document statuses agree.
- 03Commercial closureExpected charge, FSD, purchasing follow-on documents, and invoice evidence reconcile.
- 04Changed or failed pathTest a source change, missing resource, capacity conflict, late readiness, failed message, missing rate, or invoice variance with a named recovery owner.
- 05Cutover and supportOpen demand, master-data ownership, monitoring, access, reconciliation, and escalation are rehearsed.