IDoc

What is an IDoc?

An IDoc – short for Intermediate Document – is a standardized SAP data format that encapsulates business data in a defined, hierarchical structure and enables its transfer between systems. Each IDoc consists of a control record (administrative metadata), one or more data records (the actual payload), and optional status records that log the processing state. IDocs are processed asynchronously: the sending system hands off the document without waiting for an immediate response from the recipient.

IDocs are typed – each IDoc type describes a specific class of business transactions, such as delivery notifications, purchase orders, or goods receipts. SAP provides an extensive library of predefined base types; custom extensions are possible via so-called extension IDocs, though in practice this requires careful documentation.

How do IDocs work in warehouse logistics?

In intralogistics, IDocs are encountered primarily at the interfaces between ERP and WMS systems and when connecting external partners. Typical scenarios include:

• Transmission of advance shipping notifications (DESADV) from the supplier to the receiving warehouse
• Transfer of transfer orders or goods issue postings from the ERP to a connected warehouse management system
• Feedback of inventory or picking data from the WMS to SAP
• EDI communication with freight carriers, customers, or authorities via conversion platforms

Processing typically runs via defined ports and partner profile configurations in the SAP basis. Faulty IDocs end up in an error queue (transaction BD87 or WE02), where they can be reprocessed manually or automatically. Effective IDoc monitoring is therefore an operational necessity – unresolved errors can block goods receipts, delivery processes, or inventory postings.

What matters when selecting and implementing IDocs?

When building an IDoc-based integration, several aspects are critical. First, the appropriate IDoc type should be carefully selected, or an existing type reviewed for coverage – not every requirement immediately calls for custom development. In addition, the error handling strategy must be clarified early: who monitors the error queue, which error classes trigger automatic retry, and when does an error escalate to the business department?

Latency expectations also play a role. IDocs are designed for asynchronous scenarios; for time-critical real-time communication – such as with automated conveyor systems – REST APIs or messaging systems are often preferred today. In many warehouse environments, both approaches coexist, with IDocs remaining particularly strong where SAP-to-SAP integration or established EDI networks are required. The decision between IDoc and API depends on the vendor and context, and should be made based on specific latency, volume, and maintainability requirements.