ABAP Developmentbeginner

IDoc Part 2: Message Type, Basic Type and Extension

Key takeaway

Distinguish the IDoc building blocks: message type (business meaning, e. g. ORDERS), basic type (technical structure, e. g. ORDERS05), segments and segment hierarchy, extension types for custom segments, and the transactions WE30, WE31, WE60, WE81 and WE82.

Explanation

📌 KEY POINTS
✅ Message type = business meaning (ORDERS = purchase/sales order, INVOIC = invoice, MATMAS = material master).
✅ Basic type (IDoc type) = technical structure with segments and hierarchy (ORDERS05, INVOIC02, MATMAS05).
✅ Extension = customer addition of segments to a basic type; message type + basic type + extension are linked in WE82.
⚠️ One message type can use several basic types (versions); partner profiles decide which one is used.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced IDocs. This lesson explains how their structure is defined.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MESSAGE TYPE (WE81)

Describes what is exchanged: ORDERS, ORDRSP, DESADV, INVOIC, MATMAS, DEBMAS, CREMAS …
Used in partner profiles and the distribution model to route IDocs.

━━━━━━━━━━━━━━━━━━━━
▶ 2. BASIC TYPE (WE30)

Defines segments, their order, hierarchy and min/max occurrences.
Versions: ORDERS01 … ORDERS05 — newer versions contain more segments; usually the latest released one is used.
Documentation: WE60 shows the structure and fields of each segment — essential for mapping.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SEGMENTS (WE31)

Segment type (E1EDK01 — order header general data) with fields; segment definition (E2EDK01005 — versioned).
In data records (EDID4) the segment name and SDATA hold the content.
Hierarchy: e.g. E1EDP01 (item) with child segments E1EDP19 (object identification), E1EDP20 (schedule lines).\n\n━━━━━━━━━━━━━━━━━━━━\n▶ 4. EXTENSION (WE30 → Extension)\n• Adds customer segments (Z1…) below existing segments without modifying the basic type.
CIMTYP in the control record contains the extension name.
Details in Part 9.

━━━━━━━━━━━━━━━━━━━━
▶ 5. ASSIGNMENT (WE82)
Message type + basic type + extension + release → valid combination.

━━━━━━━━━━━━━━━━━━━━
▶ 6. EXAMPLES

ORDERS / ORDERS05: E1EDK01 header, E1EDKA1 partners, E1EDK02 references, E1EDP01 items, E1EDP19 material, E1EDP20 schedules.
MATMAS / MATMAS05: E1MARAM general data, E1MAKTM descriptions, E1MARCM plant data.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

WE60: display documentation of ORDERS05 and find the segment carrying the customer's material number (E1EDP19 with qualifier).
WE82: check which basic types are assigned to ORDERS.
In WE02 open an ORDERS IDoc and match its segments to the WE60 documentation.

✅ CHECKPOINT: you can read an IDoc type definition and map fields to segments.

Code example

ABAP Code

* ===== Reading typed segment data from an IDoc =====REPORT zidoc_segments. PARAMETERS p_docnum TYPE edi_docnum OBLIGATORY. DATA: lt_data   TYPE STANDARD TABLE OF edid4,      ls_data   TYPE edid4,      ls_e1edk01 TYPE e1edk01,        " order header segment structure      ls_e1edp01 TYPE e1edp01,        " item segment      ls_e1edp19 TYPE e1edp19.        " object identification (material numbers) START-OF-SELECTION.  SELECT * FROM edid4 INTO TABLE lt_data WHERE docnum = p_docnum ORDER BY segnum.   LOOP AT lt_data INTO ls_data.    CASE ls_data-segnam.      WHEN 'E1EDK01'.        ls_e1edk01 = ls_data-sdata.                 " SDATA -> typed segment        WRITE: / 'Header currency:', ls_e1edk01-curcy.      WHEN 'E1EDP01'.        ls_e1edp01 = ls_data-sdata.        WRITE: / 'Item', ls_e1edp01-posex, 'qty', ls_e1edp01-menge.      WHEN 'E1EDP19'.        ls_e1edp19 = ls_data-sdata.        CASE ls_e1edp19-qualf.                      " qualifier decides the meaning          WHEN '001'.            WRITE: / '   customer material:', ls_e1edp19-idtnr.          WHEN '002'.            WRITE: / '   vendor material  :', ls_e1edp19-idtnr.        ENDCASE.    ENDCASE.  ENDLOOP. * ===== Definition transactions =====* WE81 message types   WE30 basic types/extensions   WE31 segments* WE82 message type <-> basic type/extension          WE60 documentation

Real project scenario

A new EDI customer sent ORDERS IDocs, but the mapping team used the qualifier 002 of E1EDP19 for the customer's material number, while the customer used 001. Orders were created with wrong or missing materials.
Using WE60 documentation and example IDocs, the team corrected the mapping: qualifier 001 carries the buyer's material, 002 the supplier's. They added qualifier checks to the partner onboarding checklist.

Common mistakes

Confusing message type (meaning) with basic type (structure).
Ignoring qualifiers in segments like E1EDP19 or E1EDKA1.
Using old basic type versions without reason.
Mapping without WE60 documentation.
Modifying standard basic types instead of using extensions.

Best practices

Use WE60 documentation for mapping.
Agree on qualifiers with partners.
Use the latest suitable basic type.
Extend via extensions, never modify.
Keep an interface specification per message type.

Interview angle

Questions: "Message type vs basic type?", "What is an IDoc extension?", "Which transactions define IDoc structures?"
Strong answer: message type = business meaning (WE81), basic type = structure with segments (WE30), segments in WE31, assignment WE82, documentation WE60; one message type with several basic type versions; extensions add Z segments (CIMTYP); qualifiers define segment meaning.

Practice this lesson

Quick check

1. What does the basic type (e.g. ORDERS05) define?

2. Which transaction is used to create or extend an IDoc type by combining segments into a hierarchical structure, including defining a custom extension type?

3. Which pair of transactions is used to assign a message type to a basic IDoc type and, separately, an extension IDoc type to a message type?

Interview questions

1. What is the difference between IDoc message type and basic type?

Answer it in your own words first, then compare.

2. Difference between message type and basic type.

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.