SAP IDoc Processing: ORDERS05 Structure Explained

ORDERS05 is the IDoc type behind most SAP sales order and purchase order EDI interfaces. Its segment hierarchy looks intimidating in WE30/WE31 until you realize it follows one consistent pattern: header segments, then a repeating item structure, then optional partner/condition segments hanging off each.

The Segment Hierarchy, Top to Bottom

E1EDK01  — Document header general data
├── E1EDKA1 — Partner information (sold-to, ship-to, bill-to...)
├── E1EDK14 — Order type / document type qualifiers
├── E1EDK03 — Header dates (order date, requested delivery date...)
└── E1EDP01 — Item data (repeats once per line item)
    ├── E1EDP02 — Item reference numbers (customer PO item, etc.)
    ├── E1EDP03 — Item dates
    ├── E1EDP05 — Item conditions (pricing)
    └── E1EDPA1 — Item-level partner overrides

The pattern to internalize: K-segments are header-level, P-segments are item-level, and both can carry a matching sub-segment type (01 = general data, 03 = dates, A1 = partner) — so E1EDK03 and E1EDP03 are "the same kind of thing" (dates) at two different levels.

Key Fields Worth Knowing by Heart

E1EDK01 (header):

Field	Meaning
BELNR	Document number
CURCY	Currency key
BSART	Purchase order/document type

E1EDP01 (item):

Field	Meaning
POSEX	Item number (external, as sent by the partner)
MENGE	Quantity
MENEE	Unit of measure
MATNR	Material number

E1EDKA1 (partner, appears at both header and item level):

Field	Meaning
PARVW	Partner function (AG = sold-to, WE = ship-to, RE = bill-to)
PARTN	Partner number

Common Mapping Pitfalls

1. Confusing POSEX with the internal item number. POSEX is the item number as the sending system numbered it, which frequently does not match the SAP sales/purchase order's own item numbering after processing. Don't use POSEX as if it were VBAP-POSNR — map it explicitly.

2. Assuming partner segments only appear once. E1EDKA1 can repeat multiple times at header level (one per partner function) and can also appear at item level to override the header partner for a specific line. Mapping code that assumes "one sold-to per IDoc" breaks the first time a ship-to override shows up on a single item.

3. Missing qualifier fields on date/reference segments. Segments like E1EDK03 carry an IDDAT qualifier field that tells you which date this occurrence represents (order date vs. delivery date vs. requested delivery date) — the segment structure is the same regardless of which date it is. Mapping code that reads the first E1EDK03 occurrence without checking IDDAT will silently grab the wrong date under certain partner configurations.

Where to Look When an Inbound IDoc Fails

Start in WE02/WE05 to see the actual segment data that arrived, then compare it field-by-field against the expected structure — this is exactly the lookup our IDoc Segment Explorer is built for, so you don't need WE60/WE31 access just to check what a field means. For the reverse direction (converting internal SAP DATS values you find in these segments to a readable date), the SAP DATS / TIMS Converter saves the manual parsing.