Configuring Delivery-Based Integration Between TM and EWM
Learn how outbound and inbound deliveries become the handshake point between TM and EWM, including transportation relevance settings, freight unit generation, and the technical channels used to move data between the two components.
Explanation
Once a topic-level overview establishes that TM and EWM must talk to each other, the practical question every consultant faces is: what actually triggers that conversation, and where do you configure it? The delivery document is the pivot. In most SAP TM landscapes, a sales order or purchase order generates an outbound or inbound delivery in SD/MM, and that delivery is flagged as transportation-relevant. This relevance flag, maintained on the delivery type or delivery item category configuration, determines whether the delivery is picked up by TM's integration layer to automatically create a freight unit. Without this flag set correctly, deliveries will sit in the warehouse with no transportation object ever created, which is one of the most common go-live defects in new TM implementations. Once a delivery is transportation-relevant, TM creates a freight unit (or, depending on configuration, works directly with the delivery as a transportation unit reference) that carries dimensional, weight, and routing data forward into planning. The freight unit is then assigned to a freight order during planning, and that freight order becomes the execution document that EWM needs to know about so it can plan warehouse activities like picking, packing, and staging in the correct sequence and at the correct door. The technical exchange between TM and EWM depends on deployment: in embedded TM (TM functions running in the same S/4HANA system as EWM, whether embedded EWM or decentralized), integration can rely on shared database tables and direct function-module calls, which is faster and reduces synchronization lag. In a decentralized EWM scenario, where EWM runs in a separate system connected via delivery replication, the integration is queue-based, typically relying on qRFC-style outbound queues to push delivery and transportation data across the system boundary. Consultants must know which topology they are working in, because troubleshooting techniques differ substantially. A key configuration decision is whether TM sends the freight order to EWM as a reference document for warehouse task creation, or whether EWM's own transportation unit (TU) concept is used to represent the freight order at the warehouse level. The TU acts as EWM's internal handle for a vehicle or trailer being loaded, and it carries a link back to the TM freight order number. Configuring this correctly means setting up the transportation unit type, door and staging area determination, and the loading point assignment so that when a freight order is created or changed in TM, EWM can create or update the corresponding TU without manual intervention. Another configuration area is timing: should EWM start warehouse activities as soon as the delivery exists, or only after the freight order is tendered and confirmed by a carrier? Many projects configure a status-dependent release, so picking does not start until the freight order is in a 'planned' or 'confirmed' status, avoiding wasted labor on shipments that get replanned. This is set through delivery split profiles combined with TM status management rather than a single switch, and it requires close collaboration between the TM and EWM configuration teams because a change on one side (say, splitting a delivery) has immediate consequences on the other side's warehouse task structure. Finally, master data alignment is essential: locations, means of transport, packaging materials, and units of measure must be consistent across TM and EWM, because inconsistent master data is the single largest source of failed integration messages in real projects.
Real project scenario
During a retail distribution center rollout, freight units were not generating for a subset of outbound deliveries. Investigation showed that a new delivery type introduced for direct-store-delivery orders had not been added to the transportation relevance configuration. Correcting the delivery type setting and reprocessing the backlog resolved the gap, but the team also implemented a validation report to run after every delivery type change to catch this earlier.
Common mistakes
• Forgetting to mark new or copied delivery types as transportation-relevant after a delivery type extension project • Assuming embedded and decentralized EWM integration behave identically when troubleshooting timing issues • Releasing warehouse picking before the freight order is tendered, causing rework when carriers reject loads • Allowing inconsistent unit-of-measure or packaging master data between TM and EWM, leading to failed load building • Not aligning delivery split rules with warehouse door and staging capacity, creating unplanned TU fragmentation
Best practices
• Confirm transportation relevance flags whenever delivery types or item categories are extended or copied • Document explicitly whether the landscape uses embedded or decentralized EWM, since it changes support procedures • Use status-dependent release rules to avoid warehouse work starting before tendering is complete when business rules require it • Maintain a master data governance checklist covering locations, packaging materials, and units of measure shared by TM and EWM • Build a lightweight reconciliation report comparing delivery counts against freight unit counts to catch configuration gaps early
Interview angle
Interviewers commonly ask candidates to explain what actually triggers freight unit creation from a delivery and how that differs between embedded and decentralized EWM setups; a strong answer distinguishes transportation relevance configuration from the underlying technical transport mechanism (shared tables versus queue replication) and ties status-dependent release to real operational risk reduction.