EDIDD table — IDoc Data Records (Legacy Segment Table)
EDIDD is the older IDoc data segment table that stores the actual field content of each segment of an IDoc as a single character string, one row per segment occurrence. It predates the current segment table EDID4 and is kept mainly for compatibility with IDoc types and interfaces that were never migrated to the newer, Unicode-safe segment structure.
This page covers EDIDD, the legacy table holding the raw data content of IDoc segments, and how it differs from the current EDID4 table. It focuses on when EDIDD still gets populated, how to read the packed SDATA string, and the wrong conclusions consultants draw when an IDoc's data cannot be found where they expect it.
Published 15 Sept 2026· 1,035 words
What it stores
One row in EDIDD represents one occurrence of one segment belonging to one IDoc, holding the segment's field values packed into a single fixed-format character string. Before the Unicode-safe successor EDID4 became the standard storage table, every IDoc's payload data - the actual business content such as material numbers, quantities, partner data, whatever the segment type defines - lived here, one row per segment instance, in the order the segments occur in the IDoc structure. A single IDoc with many line items produces many EDIDD rows, one per repeating segment. The table is still present and still gets written to in some landscapes, either because an interface was built against it directly or because of how the IDoc was generated, but on current systems the working data for most IDocs is actually in EDID4, not EDIDD.
Key fields
- MANDT - client, always restrict on this before anything else
- DOCNUM - IDoc number, the join key to the control record and status table
- SEGNUM - sequential number of the segment occurrence within the IDoc
- SEGNAM - name of the segment type, e.g. E1EDK01 style identifiers, tells you which fields SDATA actually contains
- SDATA - the packed segment data as one long character field, positionally mapped to the segment's field definition
- PSGNUM - segment number of the parent segment, used to reconstruct the hierarchy
- HLEVEL - hierarchy level of the segment within the IDoc structure
How it joins the data model
- EDIDD-DOCNUM = EDIDC-DOCNUM to get the control record: message type, partner, direction, port
- EDIDD-DOCNUM = EDIDS-DOCNUM to get the processing status history for the same IDoc
- EDIDD-SEGNUM = EDIDD-PSGNUM (self join) to walk the parent-child segment hierarchy of one IDoc
- EDIDD-DOCNUM = EDID4-DOCNUM only meaningful as a comparison, not a real join, when checking which table actually holds the data for a given IDoc number
How to read it safely
Always restrict on MANDT and DOCNUM together; DOCNUM alone is unique enough across clients but scanning without MANDT on a shared instance wastes time. Never select from EDIDD without a DOCNUM restriction on a productive system with years of IDoc history - the table can hold as many rows as there are segment occurrences across the entire IDoc population, and a segment-name-only selection turns into a full scan. SDATA is not directly readable; it is a packed positional string, so pulling it out only makes sense alongside the segment definition that tells you where each field starts and how long it is. If a selection on DOCNUM against EDIDD returns nothing, check EDID4 for the same DOCNUM before assuming the IDoc has no data.
How to prove it in the data
Symptom: a custom report or old interface claims it cannot find the line-item data for a known IDoc number. Selection: read EDIDC by DOCNUM to confirm the IDoc exists and note its type and direction, then select EDIDD by MANDT and DOCNUM. If EDIDD returns no rows, select EDID4 with the same DOCNUM - a hit there confirms the IDoc's segment data is stored in the current table and the interface reading EDIDD directly is looking in the wrong place, not that the IDoc is empty or corrupted.
ECC vs S/4HANA
EDIDD still exists as a table in S/4HANA for compatibility, but the effective storage location for IDoc segment data on current releases is EDID4, the Unicode-safe successor. Interfaces and IDoc types that were defined or regenerated under the newer structure write to EDID4; EDIDD only continues to receive data for older, unconverted definitions. There is no CDS compatibility view standing in for EDIDD specifically - it is the older sibling table, not a replaced one, and both tables can coexist on the same system serving different IDoc types.
Common pitfalls
- Assuming every IDoc has its data in EDIDD - on a current system most IDocs are stored in EDID4, and EDIDD may simply be empty for that DOCNUM, which gets misread as 'the IDoc has no payload'
- Treating an empty EDIDD result as proof the IDoc processing failed before segment data was written; it is far more often a table-location mismatch, not a processing failure
- Trying to read SDATA as plain text without the segment field layout and concluding the data is garbled, when the string is simply packed positionally and needs the segment definition to decode
- Selecting on SEGNAM across the whole table to find 'all IDocs using this segment' without a DOCNUM or date restriction, which turns into a full table scan on a table that can be very large on older or long-lived systems
- Building a new custom program against EDIDD because an old sample report used it, without checking whether the interface generating those IDocs actually still writes there
- Forgetting the self-join via PSGNUM when reconstructing a multi-line IDoc and instead assuming SEGNUM order alone gives the correct parent-child structure
Whose problem this is
Ownership of EDIDD content sits with whoever owns the interface or IDoc type in question - typically the integration or middleware team for the sending or receiving application. A functional module owner (SD, MM, FI) only cares about the business fields inside the segment, not the storage table; the integration team is the one who can say whether a given IDoc type still writes to EDIDD or has moved to EDID4.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/ediddERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.