EDIDC table — EDIDC IDoc Control Record

One row in EDIDC represents the administrative header of exactly one IDoc, whether inbound or outbound. It records what the IDoc is (message type, IDoc type, extension type), who sent it and who is meant to receive it (partner number and type, port), when it was created, and its current processing status. It is the anchor record: every other IDoc-related table hangs off the DOCNUM assigned here. The table does not contain the actual segment data or field values of the business document, only the metadata needed to route, monitor, and reprocess the IDoc. A single business document (a sales order, a material master change, a delivery confirmation) generates one EDIDC row per direction per system it passes through, so the same logical message can appear as several separate EDIDC entries across sender and receiver systems.

Always restrict on MANDT explicitly when scripting selects, even though most tools apply it automatically. EDIDC is one of the largest tables in a live SAP system with active EDI or ALE traffic, easily hundreds of millions of rows over a few years of retention. Never select against it without a CREDAT (and ideally CRETIM) range, and add MESTYP, DIRECT, or STATUS as further filters before running anything interactively. DOCNUM is numeric and assigned by a number range, so it is not meaningfully sortable by business relevance, only by creation order within a range. A raw browse of EDIDC without date restriction on a production system is a common way to lock up a session or table space for minutes.

Symptom: a batch of outbound sales order confirmations to a customer EDI partner appears to be missing at their end. Select EDIDC where MESTYP equals the relevant message type, DIRECT equals 2, STATUS equals the error status code, and CREDAT falls in the affected window. Take the returned DOCNUM values and check EDIDS for the full status trail and EDIDD or EDID4 for the segment content to confirm the payload was actually built before failing at transmission.

EDIDC is retained in S/4HANA in essentially its original form. The classic IDoc interface and its control table were not replaced by a CDS compatibility view or restructured as part of the S/4HANA simplification, since the IDoc technology itself continues to run largely unchanged alongside newer integration approaches. The practical difference on S/4HANA projects is less about the table shape and more about which interfaces still use IDocs at all, as many scenarios have moved toward API-based or event-based integration on the platform, leaving IDoc traffic concentrated in legacy or partner-mandated EDI flows.

A question about a specific EDIDC row, whether an IDoc failed and why, belongs to whoever owns the EDI or ALE interface, typically a Basis or integration team member with IDoc monitoring responsibility. A question about whether the underlying business document is correct or complete belongs to the functional module team that owns the document type, since EDIDC only confirms the message moved, not that its content was right.

EDIDD and EDID4 hold the segment data referenced by DOCNUM. EDIDS carries the full status history. EDP12 and EDP13 hold the outbound and inbound partner profile configuration that determines how a given partner and message type combination is processed. Standard transactions that read and write against EDIDC include the IDoc list display, the single IDoc display, and the status monitor used for reprocessing failed IDocs in bulk.