DELVRY message type — DELVRY IDoc Message Type for Delivery Replication
DELVRY carries an outbound or inbound delivery document between two SAP systems, most commonly between an ERP/S4 core and a decentralized warehouse management system such as SAP EWM decentralized. It replicates delivery creation, change and confirmation so the receiving system can pick, pack and post goods movements against the same delivery number. It is not the customer-facing despatch advice, which is DESADV.
This page covers the DELVRY IDoc message type used to replicate delivery documents across systems in an ALE or decentralized warehouse landscape. It focuses on the segments that carry header, item and quantity data, the partner profile and process code setup that must be in place, and the ordered checklist for diagnosing a stuck or failed delivery IDoc.
Published 16 Sept 2026· 1,066 words
What it carries
DELVRY moves a delivery document (outbound or inbound delivery) from the system where it is created or changed to a system that needs its own copy to act on. The classic use case is delivery replication between an ERP/S4 core and a decentralized warehouse management system, where the core system creates the delivery and DELVRY pushes it to the WMS for picking and packing; a change IDoc later carries confirmed quantities back. It also appears in ALE landscapes between two logistics systems that must stay synchronized on delivery status. Direction is always system to system, not company to customer or carrier. It should not be confused with DESADV, which carries the despatch advice to an external trading partner over EDI. DELVRY is internal plumbing; DESADV is the outward-facing document.
Segments
The structure varies slightly by basic type version (DELVRY01, DELVRY02, DELVRY03) but the core carriers are stable across them. Segment names below are the ones consistently documented for this message type; treat anything not listed here as version-specific and confirm against the actual IDoc segment editor before relying on it.
- E1EDL20 - delivery header: delivery number, shipping point, delivery type, ship-to partner, overall dates
- E1EDL24 - delivery item: item number, material, order quantity, plant, storage location, reference to the sales order or outbound delivery item
- E1EDL37 - serial number data where the item is serial-managed
- E1EDL44 - batch data where the item is batch-managed
- E1EDT13 - date and time segment carrying qualified dates such as goods issue date, loading date, pick date
Configuration
On the sending side, a partner profile in WE20 for the receiving logical system must list DELVRY as an outbound message type, with the correct basic type version, a port pointing at the receiving system (RFC port in WE21 for an ALE/EWM-decentralized link), and an output type in the delivery's output determination procedure that triggers via NAST to generate the IDoc on save or on goods issue. On the receiving side, the partner profile needs DELVRY as inbound with a process code that points at the delivery-creation function module for that release, plus authorization for the technical user posting the IDoc to create deliveries in the target plant and storage location. For ALE scenarios the distribution model (BD64) must have a matching entry for the sending and receiving logical system, or the IDoc is never generated even though the delivery itself is fine.
What to inspect when it fails
Work from the outside in: confirm the IDoc exists and left the sender before assuming a receiving-side data problem.
- WE02 or WE05: locate the IDoc by delivery number or date range, read the status record text, note whether it stopped outbound (5x) or inbound (5x on the receiving side)
- Status 29 or a missing IDoc entirely: check the output type in the delivery's output determination log, confirm the condition record and access sequence actually determined the medium and partner function
- WE20: confirm the partner profile still lists DELVRY with the expected basic type and process code, especially after a release upgrade that may have bumped DELVRY02 to DELVRY03
- BD64: for ALE distribution, confirm the model view has an active entry for this message type between the two logical systems
- Segment content in the IDoc: open E1EDL20 and E1EDL24, check plant, storage location and quantity fields against the source delivery in VL03N
- SM58 and SMQ1/SMQ2: if the link uses transactional or queued RFC rather than plain ALE, check for stuck LUWs before touching the IDoc itself
- On the receiving side, the application log behind the inbound function module: authorization failures, missing storage location, or a material not extended to the receiving plant surface here
Whose problem this is
Functional (SD or logistics execution) owns output determination, partner function setup, and whether the delivery data itself is correct before it becomes an IDoc. Basis owns the port, RFC destination, and any stuck tRFC or qRFC queue entries. Hand over to ABAP only when the inbound process code points at a custom function module or a user exit is suspected of dropping segment data.
Common pitfalls
DELVRY is easy to misread because success at the IDoc layer says nothing about correctness at the business layer.
The reflex is to select the failed IDoc in BD87 and click reprocess, or worse, manually set the status to 53 to make the worklist look clean. Reprocessing without reading the application log behind the error repeats the same failure, and forcing the status green hides a delivery that was never actually created or confirmed in the receiving system. The warehouse then works from a delivery that does not exist there, or the core system believes goods issue happened when it has not, and the mismatch surfaces later as a stock discrepancy that is much harder to trace back to this IDoc.
- Status 53 only confirms the inbound function module ran without raising an application error; it does not confirm the delivery quantities match, only that a delivery object was created or updated
- DELVRY is frequently confused with DESADV; DELVRY replicates the delivery for internal warehouse execution, DESADV notifies an external party the goods shipped, and they run through different partner profiles and often different output types on the same delivery
- Basic type mismatches between sender and receiver (DELVRY01 vs DELVRY02 vs DELVRY03) produce IDocs that post with some fields silently blank rather than erroring, because unknown segments are ignored rather than rejected
- Change IDocs for the same delivery can arrive out of order under queued processing, so an item change appears to vanish when in fact a later change IDoc overwrote it before the earlier one was read
- Batch and serial segments are optional; their absence in a given IDoc is normal for non-managed materials and is not itself evidence of a data loss problem
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-idoc/delvryERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.