EDIDS table — IDoc Status Record Table

One row in EDIDS represents a single status event recorded against one IDoc during its processing lifecycle. Every time an IDoc changes state - created, passed to the port, dispatched by the receiving system, error in the application, posted successfully - a new row is written, never an update to an existing row. So an IDoc that has gone through outbound dispatch and inbound posting without incident might have five or six rows, and one that has been reprocessed after an error can have a dozen or more. The table is the audit trail SAP uses to answer 'what happened to this IDoc and when', which is exactly what the standard IDoc monitoring transactions read to build their status displays.

Always restrict by MANDT and by DOCNUM range or by CREDAT/CRETIM window before touching this table directly; it grows without bound because every retry, every dispatch attempt, and every posting error adds rows, and on a busy interface landscape it can be one of the largest tables in the system. Never select on STATUS alone across the whole table looking for 'all failed IDocs today' without also restricting the date, and never assume COUNTER is a reliable ordering field across different runs - use CREDAT/CRETIM together with COUNTER when reconstructing sequence. If pulling data for analysis, filter by message type or partner via a join to EDIDC first, then bring in EDIDS rows for that restricted DOCNUM set.

Business symptom: 'this IDoc never posted'. Select EDIDS where DOCNUM equals the IDoc number, order by COUNTER ascending, and read the STATUS and STATXT sequence. If the last row is 51 (application document not posted) or 56 (IDoc with errors added), the failure and its message are right there in STATXT. If the last row is 53, the IDoc itself succeeded and the missing document is a downstream posting or workflow issue, not an IDoc processing problem.

EDIDS is unchanged in shape and role on S/4HANA; IDoc processing and status logging work the same way as in ECC. The IDoc monitoring transactions still read this table directly, and no CDS compatibility view replacement was introduced because it was never restructured as part of the Simplification List. The practical difference on S/4HANA projects is volume: more integration runs through IDocs and APIs side by side, so EDIDS growth and archiving discipline matter more, not the table structure itself.

Interface or basis teams own the IDoc monitoring layer and archiving policy for EDIDS. The functional team that owns the business document (sales order, delivery, invoice) owns the question of why a specific IDoc's status sequence ended where it did, since that requires reading STATXT and matching it against the application logic, not the table structure itself.

EDIDC is the IDoc header table joined by DOCNUM; EDIDD and EDID4 hold the segment data for the same IDoc under the classic and clustered storage variants. Transactions WE02 and WE05 display IDoc lists built from these three tables plus EDIDS; BD87 is the standard status monitor and reprocessing transaction that both reads and writes EDIDS rows when an IDoc is manually reprocessed.