DESADV message type — DESADV IDoc Despatch Advice Message Type

DESADV represents the despatch advice document, the notification that goods have left the shipping point and are on their way, sent ahead of or alongside the physical shipment. Outbound, it is generated from an outbound delivery and sent from the shipping party to the customer or to a warehouse, telling the receiving side what quantities, batches, and packaging to expect. Inbound, the same message type arrives from a vendor against a purchase order and is used to create an inbound delivery automatically, letting the receiving plant plan goods receipt and putaway before the truck arrives. The direction is set entirely by whether the IDoc is being generated (outbound partner profile) or received (inbound partner profile); the message type name and structure do not change between the two directions, only the partner role and the processing function module.

The IDoc is built on the DELVRY basic type family shared with shipping notifications, so the segments describe a delivery rather than a generic document.

Outbound generation is driven by output determination on the delivery: an output condition record for the despatch advice output type must exist for the shipping point and partner combination, and that output type must be configured to produce an IDoc rather than a print or fax. The partner profile on the sending side (message type DESADV, outbound parameters) points to the port and the basic type, and the port definition determines whether the IDoc goes to a file, an ALE/RFC destination, or a middleware queue. On the receiving side the partner profile carries the inbound parameters: process code, and the process code links to the function module that actually creates the inbound delivery or updates the purchase order confirmation. If any of these three pieces is missing or points to the wrong basic type version, the IDoc either never gets created, sits unsent, or lands but cannot find a process code to execute against.

Work from the delivery document outward before touching the IDoc tools; the fault is more often in output determination than in the IDoc layer itself.

Functional ownership sits with SD for outbound despatch advice and MM for inbound advance shipping notifications; they own output determination, partner profiles, and process code assignment. Basis owns ports, RFC destinations, and queue health. Hand over to Basis only after confirming the IDoc was generated correctly and simply failed to transmit; hand over to development only when the process code's function module itself needs a code fix rather than a configuration correction.

Several things make this message type look broken when the process is actually working as configured.

The reflex is to mass-reprocess every status 51 IDoc from the monitoring transaction without reading the individual error text first. That clears the error list and makes the queue look healthy, but if the underlying cause was a missing EDI partner number on the customer master or an incompatible unit of measure, the reprocessed IDoc fails again on the next run, or worse, posts with wrong data because the retry happened after someone patched the master record halfway. Reprocessing is the last step, applied once the actual cause is fixed, not the first diagnostic action.