Lesson 1 of 5
IDoc structure
10 min
Listen to this lesson
An IDoc (Intermediate Document) is SAP's container for a business message moving between systems: a sales order from a customer, a purchase order to a supplier, an invoice, a material master. IDocs have been part of SAP ERP for decades, and they remain one of the most used integration technologies in SAP S/4HANA on-premise and Private Edition landscapes, especially after a system conversion, which carries every existing IDoc interface across.
At Contoso Motor Co., the conversion from SAP ECC 6.0 EHP 8 to SAP S/4HANA keeps about 25 IDoc interfaces. The most important are inbound sales orders from Great Lakes Fleet Services over EDI and outbound purchase orders to Lakeside Components. Integration lead Theo and test lead Priya need every one of them retested in the quality system CMQ.
Three kinds of record
Every IDoc is made of three kinds of record. SAP's IDoc display shows them as a tree under the IDoc number:
The control record works like the address on an envelope. When something goes wrong with routing, for example an IDoc goes to the wrong partner profile, the control record is the first place to look. The data records hold the business content. The status records are the IDoc's diary: they tell you what happened, when and with which error. In current releases the three record types are stored in database tables EDIDC (control), EDID4 (data) and EDIDS (status); you rarely need the tables, because the display transactions present them for you.
Message types, IDoc types and segments
Two names describe what an IDoc contains. The message type gives the business meaning: ORDERS (purchase or sales order), ORDRSP (order confirmation), DESADV (shipping notification), INVOIC (invoice), MATMAS (material master), DEBMAS (customer master). The IDoc type (also called basic type) defines the technical structure: which segments exist, in which order and how often. ORDERS05 is a common basic type for the ORDERS message type. One message type can be linked to several basic types, usually newer versions with more fields.
| Term | Answers the question | Example | Where it is defined |
|---|---|---|---|
| Message type | What business message is this? | ORDERS | WE81, linked to IDoc types in WE82 |
| Basic type | What is the technical structure? | ORDERS05 | WE30 (IDoc type development) |
| Extension | Which customer segments were added? | A Z-extension carrying Contoso's fleet contract number | WE30, combined with a basic type |
| Segment | Which group of fields is this? | E1EDK01 header data, E1EDKA1 partner, E1EDP01 item | WE31 (segment editor) |
Segments from SAP start with E1; customer segments usually start with Z1. Some segments are qualified: the first field says what the segment means. The partner segment E1EDKA1, for example, appears several times in an order, once with the qualifier for the sold-to party and once for the ship-to party. A mapping that puts the ship-to number under the sold-to qualifier creates a perfectly valid IDoc with the wrong customer.
- Control recordRead direction, message type and partner: is this the IDoc you expect?
- Data recordsOpen header, partner and item segments: are the business values right?
- Status recordsRead from newest to oldest: where did processing stop and why?
- Linked documentFollow the link to the posted application document and check it in the app
What would you do?
Maria reports that a test order from Great Lakes Fleet Services was posted for the wrong ship-to address. The IDoc is in status 53. What should Theo check first?
- Every IDoc has one control record, one or more data records and one or more status records.
- The message type gives business meaning (ORDERS); the basic type gives structure (ORDERS05).
- Segments group fields; qualified segments such as E1EDKA1 depend on a qualifier for their meaning.
- Status 53 proves an IDoc posted, not that its content was right; always check the posted document.
Check your understanding · not graded
Lesson check
1. Which record type would you check first if an IDoc went to the wrong partner?
2. What does the message type ORDERS tell you that the basic type ORDERS05 does not?
3. Why can a qualified segment cause a valid IDoc to post wrong data?