SAP IDoc Architecture: Control Record, Data Segments and Status Records

IDoc is SAP's Intermediate Document framework for ALE/EDI-style integration. The control record identifies sender/receiver, message type, basic type/extension, port and processing context. Data records carry named segments in hierarchy order; each segment's SDATA is interpreted using the segment definition. Status records are appended as the IDoc moves through outbound generation, communication, inbound framework and application posting. The IDoc number ties all three layers together. A status is evidence of a processing step, not the business document itself; a successful technical transfer can still be followed by an application error status.

Use IDocs when the SAP application provides a standard IDoc/message type, asynchronous decoupling and operational reprocessing are valuable, or an EDI/ALE landscape already uses partner profiles and monitoring. They fit high-volume document exchange where sender and receiver should not be tightly coupled to synchronous availability. For new S/4HANA cloud-centric integrations, compare the IDoc with released APIs/events before choosing it purely because the team knows WE20.

Message types connect business intent to basic IDoc types. WE30/WE31 define basic types and segments; WE20 partner profiles provide inbound/outbound parameters; WE21 ports define technical destinations; process codes link messages to outbound/inbound application logic; BD64 can determine ALE receivers. tRFC/qRFC may transport IDocs underneath. WE02/WE05 display document/status history. Reprocessing transactions/programs act on failed statuses without requiring the original sender to recreate the entire business payload.

An ORDERS IDoc arrives and shows status 51. EDIDC confirms the sender/receiver/message/basic type; EDID4 shows the purchase-order segments; EDIDS contains the application error message. Because the IDoc reached inbound application processing, Basis does not begin with RFC connectivity. The MM/integration team fixes the master/configuration cause and reprocesses through the supported IDoc path. If the IDoc had stopped earlier in communication/queue status, the ownership path would be different.

IDocs remain widely supported in S/4HANA on-premise/private cloud and in many standard integrations. SAP also provides modern OData/SOAP/event APIs, so new designs should choose based on business semantics and lifecycle rather than age alone. Clean-core principles favor standard/released IDoc extension points and APIs rather than direct table/status manipulation.

Integration/ALE teams own partner profiles, ports, message/basic type mapping and monitoring. Functional teams own application posting/master data. Basis owns RFC/qRFC/communication infrastructure. ABAP owns custom segments, process-code function logic and safe extensions.

WE02/WE05 monitor IDocs; WE20 partner profiles; WE21 ports; WE30/WE31 types/segments; WE42 inbound process codes. EDIDC, EDID4 and EDIDS table pages provide storage semantics.

Production verification: Capture the IDoc number when one exists, sender/receiver logical systems, message type/basic type/extension, current and prior statuses, partner type, process code/port, and the exact timestamp. Use WE02/WE05, WE20/WE21/BD64 and EDIDC/EDID4/EDIDS as appropriate so the incident can be placed at trigger, routing, transport, or application-posting layer.

Operational readiness: For production readiness of SAP IDoc Architecture: Control Record, Data Segments and Status Records, add an operational runbook that names the source owner, integration/platform owner and target application owner; defines correlation, retry/replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed/business-invalid payloads and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue/retention/order behavior and how a corrected message is reprocessed without duplicating a business transaction.