Delivery Replication and Confirmation Flow Between ERP and EWM (Part 3)

When a warehouse runs on EWM (embedded or decentralized) while sales, purchasing, and inventory accounting stay in ERP/S4, every delivery must be replicated to EWM so warehouse execution can plan and confirm work, and every physical goods movement executed in EWM must be posted back to the ERP stock ledger. This two-way flow is the functional heart of ERP-EWM integration, and consultants must understand it well enough to explain document status mismatches to warehouse supervisors and finance teams.

On the outbound side, when a sales order-based delivery is created in ERP, the delivery header and item data is sent to EWM as a delivery request. In decentralized EWM this happens over qRFC (queued RFC) using IDoc-based message types for delivery creation, change, and deletion; the replicated document becomes an EWM outbound delivery order, which is a distinct object from the ERP delivery even though they share a common delivery number in many configurations. In embedded EWM on S/4HANA, the same logical replication occurs but through an internal, tightly coupled call framework rather than external IDoc transport, so there is no separate ALE distribution model to configure, though the delivery still exists as two document representations internally.

EWM then plans and executes the outbound process: wave assignment, warehouse task creation, picking, packing, and loading. As each step completes, EWM does not wait until the very end to talk to ERP. Depending on configuration, goods issue can be posted from EWM once picking and loading confirmations are complete, or ERP can retain control of the goods issue posting while EWM only confirms execution status. The confirmation message flows back through the same queued communication channel, updating delivery quantities and eventually triggering the goods movement posting in ERP inventory management.

Inbound follows a mirror pattern: a purchase order or inbound delivery in ERP is replicated to EWM as an expected receipt; EWM manages putaway, quality inspection triggers if configured, and goods receipt posting, then confirms actual received quantities back to ERP, which updates the purchase order history and stock.

Because this is asynchronous, queue-based communication, timing gaps are normal and expected, not automatically an error. A delivery might show as 'in process' in ERP for several minutes while EWM finishes picking, and confirmations are typically processed in near-real-time but not synchronously. Consultants need to understand which message types drive which document status transitions so they can distinguish a normal processing delay from a genuine integration break.

Another important design point is quantity and batch/handling unit reconciliation. If packing in EWM changes handling unit structure or if partial confirmations are posted, the ERP delivery must reconcile those quantities correctly; misconfigured item category or batch determination settings can cause delivery items to remain open indefinitely even though the warehouse work is physically complete. Understanding this flow is essential before attempting to diagnose queue failures, which is covered in the next lesson.

During a retail distribution center go-live on decentralized EWM, warehouse supervisors reported that completed and loaded deliveries were still showing as open in ERP for up to twenty minutes. Investigation showed this was expected queue processing latency under peak load, not a defect, and the business accepted a revised SLA after the consulting team explained the asynchronous confirmation flow and adjusted batch job scheduling for downstream billing so it no longer ran immediately after shipment completion.

• Assuming ERP and EWM delivery documents are the same object with identical status update timing
• Treating normal queue processing delay as a system error and escalating unnecessarily
• Overlooking handling unit or batch split differences that block final delivery quantity reconciliation
• Not distinguishing between EWM-side goods issue posting and ERP-side goods issue posting when troubleshooting missing stock updates
• Ignoring message type-specific configuration when only one direction of replication appears to fail

• Document expected replication latency and share it with warehouse and finance stakeholders before go-live
• Clarify early in design whether goods issue and goods receipt postings originate in EWM or ERP
• Align batch and handling unit determination logic between ERP and EWM to avoid reconciliation gaps
• Build monitoring dashboards that show delivery status side by side across both systems
• Train key users to check queue status before assuming a functional defect

Interviewers use this topic to check whether a candidate actually understands EWM as a distinct execution system rather than assuming it behaves like classic WM. Strong answers describe the delivery replication and confirmation loop in terms of document types, queue-based transport, and asynchronous timing, and can explain why a delivery might be complete in the warehouse but not yet reflected in ERP.