SAP IDocs

IDoc stands for Intermediate Document. It is SAP's own proprietary format for exchanging business data between SAP systems and between SAP and external systems. IDocs have been part of SAP since the early 1990s and remain one of the most common data exchange mechanisms in large SAP landscapes, even today.

Think of an IDoc like a standardized shipping box. Every time SAP needs to send business data somewhere — a purchase order to a supplier, a delivery confirmation to a warehouse, a payment notice to a bank — it packs that data into an IDoc box. The receiver opens the box and reads the contents according to an agreed structure. The structure never changes, so both sides always know exactly where each piece of data sits.

Why IDocs Exist

Before IDocs, companies exchanged data in flat files and custom message formats. Every partner connection required custom development. When the data format on one side changed, the receiver had to update its code. IDocs solved this by defining a standard structure for each business document type, which all SAP-connected systems could rely on.

IDoc Structure

Every IDoc has three parts:

1. Control Record (EDI_DC)

The envelope of the IDoc. It holds technical routing information — the sender system, the receiver system, the message type, the IDoc type, and a timestamp. Every IDoc has exactly one control record.

2. Data Records (Segments)

The actual business data. Data records are called segments. Each segment has a name, a hierarchy level, and fixed-length field positions. An IDoc can contain many segments, organized in a parent-child tree structure.

3. Status Records

A log of everything that happened to this IDoc — when it was created, when it was sent, when it was received, whether it succeeded or failed processing. Status records are added automatically by SAP throughout the IDoc's lifecycle.

IDoc Visual Structure

┌────────────────────────────────────────┐
│  CONTROL RECORD (EDI_DC40)             │
│  From: SAP_ERP  To: PARTNER            │
│  Message Type: ORDERS                  │
│  IDoc Type: ORDERS05                   │
└────────────────────────────────────────┘
┌────────────────────────────────────────┐
│  SEGMENT: E1EDK01 (Order Header)       │
│    BSART: OR (Order Type)              │
│    WKURS: 1.25 (Exchange Rate)         │
└─────────┬──────────────────────────────┘
          │
          ├──┌──────────────────────────────────┐
          │  │ SEGMENT: E1EDK14 (Org Data)      │
          │  │   QUALF: 006  ORGID: 1000        │
          │  └──────────────────────────────────┘
          │
          ├──┌──────────────────────────────────┐
          │  │ SEGMENT: E1EDP01 (Line Item 1)   │
          │  │   POSEX: 000010  MENGE: 500      │
          │  └──────────────────────────────────┘
          │
          └──┌──────────────────────────────────┐
             │ SEGMENT: E1EDP01 (Line Item 2)   │
             │   POSEX: 000020  MENGE: 100      │
             └──────────────────────────────────┘

IDoc Types and Message Types

Two key terms appear whenever you work with IDocs:

• IDoc Type (Basic Type) – Defines the structure — which segments exist and in what order. Example: ORDERS05 defines the structure for purchase orders.
• Message Type – Defines the business meaning. Example: ORDERS is the message type for purchase orders, INVOIC for invoices, DESADV for delivery notices.

Multiple IDoc types can carry the same message type. ORDERS01, ORDERS02, ORDERS03, ORDERS04, and ORDERS05 are all versions of the ORDERS message type, each adding more fields than the previous version.

Common IDoc Types You Will Encounter

• ORDERS05 – Purchase orders (sent to suppliers)
• INVOIC02 – Vendor invoices (received from suppliers)
• DESADV01 – Delivery/Advance Ship Notice
• MATMAS05 – Material master data
• DEBMAS06 – Customer master data
• HRMD_A08 – HR employee master data
• WMMBXY – Warehouse goods movement

Inbound vs Outbound IDocs

OUTBOUND (SAP sends IDoc to external system):
[Business event in SAP] → SAP creates IDoc → sends to Partner
Example: SAP creates a purchase order → sends ORDERS05 IDoc to supplier

INBOUND (External system sends IDoc to SAP):
[Partner sends IDoc] → SAP receives it → posts as business document
Example: Supplier sends INVOIC02 IDoc → SAP posts as vendor invoice

IDoc Processing in CPI

CPI handles IDocs through the IDoc adapter. Here is what happens in a typical inbound IDoc scenario:

1. A supplier's system generates an INVOIC02 IDoc and sends it to CPI
2. The IDoc adapter in CPI receives the IDoc and converts it to XML for internal processing
3. The iFlow applies any required transformations (field mapping, value conversion)
4. The IDoc adapter sends the processed IDoc to the SAP system
5. SAP posts the IDoc as a vendor invoice in the MM module
6. SAP updates the IDoc status record to "Posted successfully"

IDoc Monitoring in SAP

SAP provides transaction WE02 (IDoc list) and WE05 (IDoc display) for monitoring IDocs. You can filter by IDoc type, status, date, and partner to find specific IDocs. Each status code tells you where in the lifecycle the IDoc sits:

• Status 03 – Data passed to port (outbound sent)
• Status 12 – Dispatch OK (outbound successful)
• Status 51 – Application document not posted (inbound error)
• Status 53 – Application document posted (inbound success)

EDI and IDocs

Many companies exchange IDocs with external partners using EDI (Electronic Data Interchange) standards like EDIFACT or ANSI X12. These partners do not run SAP, so SAP must convert IDocs to the EDI standard the partner expects. An EDI subsystem or an integration platform like CPI handles this conversion. The combination of IDoc expertise and EDI knowledge makes integration professionals particularly valuable in manufacturing and retail industries.