EDID4 table — IDoc Data Records, Extended Segment Format
EDID4 stores IDoc segment data records in the same role as EDIDD, but with a longer data field to accommodate segments whose character content exceeds the classic 1000-character limit. Each row is one segment occurrence of one IDoc. An IDoc's segments live entirely in EDID4 or entirely in EDIDD, never split across both, depending on the segment definitions involved.
EDID4 is the extended-length counterpart to EDIDD, holding the actual field content of IDoc segments once a segment definition exceeds the old length ceiling. This page covers what a row represents, how to join it back to the control record, and the recurring mistake of querying EDIDD alone and concluding an IDoc has no data.
Published 15 Sept 2026· 922 words
What it stores
One row in EDID4 is a single segment occurrence belonging to one IDoc: the concatenated field values of that segment as a raw character string, tagged with the segment name and its position within the IDoc's hierarchy. An IDoc with, say, header, item and partner segments produces one row per segment instance, so a multi-line document generates many rows sharing the same document number. EDID4 exists because some segment types, particularly those built for newer extended interfaces, carry more data per occurrence than the classic 1000-character segment buffer allows. SAP routes an IDoc's segment storage to EDID4 instead of EDIDD when any segment in that IDoc's type requires the longer buffer. The two tables are functionally parallel and mutually exclusive per IDoc; an IDoc is never split between them.
Key fields
- MANDT - client, always the first restriction
- DOCNUM - IDoc number, joins back to the control record and status records
- SEGNUM - sequential number of the segment occurrence within the IDoc, defines ordering
- SEGNAM - name of the segment type, e.g. an E1-prefixed segment identifier
- SDATA - the raw concatenated field content of the segment, longer than the equivalent field in EDIDD
How it joins the data model
- EDIDC-DOCNUM = EDID4-DOCNUM, the control record for the IDoc whose segments are stored here
- EDIDS-DOCNUM = EDID4-DOCNUM, the status history for the same IDoc
- EDID4-DOCNUM = EDIDD-DOCNUM only in the sense that both are checked, never both populated for the same IDoc
- EDID4-SEGNAM matched against the segment definition maintained in the IDoc type's structure to decode SDATA into named fields
How to read it safely
Always restrict by MANDT and DOCNUM together; DOCNUM alone is unique within a client but the table has no secondary index that makes broad scans cheap. Never select on SDATA content directly with a wildcard search across the whole table; it is an unstructured character field and a LIKE scan on it will run for a very long time on any system with real interface volume. Get the DOCNUM list from EDIDC first, filtering by message type, partner, direction and date, then fetch EDID4 rows for that restricted set of document numbers. Do not assume an IDoc's segments are in EDID4 without checking EDIDC's basic type first; most IDoc types still land in EDIDD.
How to prove it in the data
Symptom: an inbound IDoc shows status 53 (posted) in EDIDC but the business document supposedly created from it cannot be found. Pull DOCNUM from EDIDC for that message type and date, then select EDID4 (and EDIDD, checking both) by that DOCNUM ordered by SEGNUM. If rows exist with plausible SDATA content, the IDoc did carry data and the gap is downstream in the posting logic, not in IDoc transfer.
ECC vs S/4HANA
EDID4 exists unchanged as a transparent table in S/4HANA; IDoc processing itself was not restructured by the S/4HANA move, since IDocs remain a core ALE and interface mechanism. There is no compatibility CDS view replacing EDID4 for transactional access; consultants still read it directly or, more commonly, via the standard IDoc display transaction rather than raw table access. The split between EDIDD and EDID4 based on segment length persists on S/4HANA exactly as it did on ECC.
Common pitfalls
- Querying only EDIDD and concluding an IDoc has no segment data, when the IDoc type in question actually stores in EDID4; always check both, or check the basic type's segment definitions first to know which one applies
- Trying to read SDATA as a fixed offset without pulling the exact segment definition for that release; segment layouts can differ between systems if a customer segment was extended, and a hardcoded offset that worked in one client silently misreads data in another
- Assuming SEGNUM order equals business document line order; SEGNUM reflects storage sequence within the IDoc hierarchy, which usually but not always matches the logical line sequence a functional consultant expects
- Deleting or archiving EDID4 rows independently of EDIDC and EDIDS; the three tables must be treated as one archiving object, and orphaned segment data with no control record is unreadable and a housekeeping problem to clean up
- Assuming a large row count in EDID4 for a DOCNUM signals a data quality issue; it often just means the IDoc type has many small segment occurrences, which is normal for line-item-heavy message types
Whose problem this is
The interface or PI/PO/Integration Suite team owns questions about whether data reached this table at all. The functional module team (SD, MM, FI, whichever business area the IDoc feeds) owns what happens after the segment data is read and posted. Basis owns archiving and volume growth of EDID4 alongside EDIDC and EDIDS.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/edid4ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.