ERPClimb logoERPClimb
Login
IDoc
ABAP Developmentbeginner

IDoc Part 1: What an IDoc Is — Inbound, Outbound and the Big Picture

Key takeaway

Understand IDocs: the intermediate document container for ALE/EDI, its control record (EDIDC), data records (EDID4) and status records (EDIDS), outbound and inbound flows, the key configuration objects and the monitoring transactions WE02, WE05, WE19 and BD87.

What this complete series covers

Learn SAP IDoc processing from structure and message types through inbound/outbound configuration, partner profiles, status codes, extensions and production troubleshooting.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of IDoc.
Prerequisites
Basic SAP navigation and ABAP syntax help. For hands-on practice, use an ABAP system with ADT or the relevant ABAP development tools.
Final outcome
By the end, you should be able to trace an IDoc end to end, find the first failed layer and reprocess safely after fixing the cause.
  1. Part 1: IDoc Part 1: What an IDoc Is — Inbound, Outbound and the Big Picture

    Understand the three core IDoc record types: the control record identifies routing and message metadata, data records hold ordered segments, and status records preserve the process

  2. Part 2: IDoc Part 2: Message Type, Basic Type and Extension

    Differentiate IDoc message type, basic type and extension so business intent, technical segment structure and customer additions are configured without mixing their responsibilities.

  3. Part 3: IDoc Part 3: Inbound IDoc Processing

    Understand inbound IDoc processing from transport reception through partner/profile process-code resolution to application posting, status 53 success or status 51 business failure.

  4. Part 4: IDoc Part 4: Outbound IDocs, Distribution Model and Reprocessing

    Understand the outbound IDoc path from business trigger through message generation, partner profile, ALE routing and RFC/qRFC transport, then reprocess only after the root cause is fixed.

  5. Part 5: IDoc Part 5: Partner Profile, Port and RFC Configuration

    Understand the IDoc communication chain: partner profile controls message-specific processing, port defines the technical endpoint, and RFC destination provides connectivity for RFC-based ports.

  6. Part 6: IDoc Part 6: Inbound Process Code and Custom Function Module

    Understand how an inbound partner profile uses a process code to resolve application posting logic, and debug the process function only after status and payload evidence points to

  7. Part 7: IDoc Part 7: Outbound Triggering — Output Control and Change Pointers

    Understand the major outbound IDoc trigger patterns, including application output, change pointers and direct application calls, so failures are diagnosed at the trigger layer befo

  8. Part 8: IDoc Part 8: Status Codes and Reprocessing with BD87

    Use IDoc status as the process timeline: identify the last successful technical or application step, fix the underlying problem, then reprocess through the supported mechanism with

  9. Part 9: IDoc Part 9: IDoc Extension and Custom Segments

    Extend a standard IDoc only when the partner genuinely needs additional business data, using a custom segment and IDoc extension while preserving standard basic-type compatibility.

  10. Part 10: IDoc Part 10: Debugging and Production Support

    Troubleshoot IDoc incidents by identifying direction and last successful status, inspecting payload and configuration, fixing the first failed layer, then reprocessing only after t

System and release assumptions: Examples follow modern ABAP practices. Exact syntax, available APIs, and tools can vary by SAP release, so release-dependent points are called out where needed.

Explanation

📌 KEY POINTS
✅ An IDoc (Intermediate Document) is SAP's standard container for exchanging business data asynchronously — between SAP systems (ALE) or with partners via EDI.
✅ Every IDoc has one control record (EDIDC: who, what, direction), data records (EDID4: segments with business data) and status records (EDIDS: processing history).
✅ Outbound: an application creates the IDoc and sends it via a port; inbound: SAP receives it and posts it with a function module.
⚠️ IDocs are asynchronous: "sent" does not mean "posted" — always check the status on both sides.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

  • Part 1 — what an IDoc is (this lesson)
  • Part 2 — message type, basic type and extension
  • Part 3 — inbound IDoc processing
  • Part 4 — outbound IDoc, distribution model and reprocessing
  • Part 5 — partner profile, port and RFC configuration
  • Part 6 — inbound process code and function module
  • Part 7 — outbound triggering and output control
  • Part 8 — status codes and reprocessing
  • Part 9 — IDoc extension and custom segments
  • Part 10 — debugging and production support

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHERE IDOCS ARE USED

  • EDI with customers/suppliers: purchase orders (ORDERS), order confirmations (ORDRSP), dispatch advice (DESADV), invoices (INVOIC).
  • ALE between SAP systems: master data distribution (MATMAS, DEBMAS, CREMAS), FI postings.
  • Middleware (SAP PI/PO, CPI) converts IDocs to/from other formats.

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE THREE RECORD TYPES

  • Control record EDIDC: IDoc number (DOCNUM), direction (1 outbound, 2 inbound), message type (MESTYP), basic type (IDOCTP), extension (CIMTYP), sender/receiver partner and port, status.
  • Data records EDID4: segments (e.g. E1EDK01 header, E1EDP01 item) in a hierarchy; each segment's content is in SDATA.
  • Status records EDIDS: status numbers with timestamps and messages (e.g. 03 passed to port, 53 posted, 51 error).

━━━━━━━━━━━━━━━━━━━━
▶ 3. OUTBOUND FLOW (SIMPLIFIED)
Application (e.g. output type in a sales order) → IDoc created (status 30/01) → passed to port (03) → partner system or middleware.

━━━━━━━━━━━━━━━━━━━━
▶ 4. INBOUND FLOW (SIMPLIFIED)
Port receives IDoc (status 50/64) → partner profile determines process code → function module posts the document → status 53 (success) or 51 (error).

━━━━━━━━━━━━━━━━━━━━
▶ 5. KEY TRANSACTIONS

  • WE02 / WE05: display IDocs (list, segments, status).
  • WE19: test tool — copy an IDoc and process it again.
  • BD87: status monitor and reprocessing.
  • WE20: partner profiles; WE21: ports; WE30/WE31: IDoc types and segments; WE81/WE82: message types.

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

  1. WE02: select IDocs of the last day and open one inbound and one outbound IDoc.
  2. Look at the control record (partner, message type), expand segments and read the status records.
  3. Open BD87 and see IDocs grouped by status.

✅ CHECKPOINT: you understand the structure of an IDoc and the basic inbound and outbound flows.

Code example

ABAP Code
* ===== Reading an IDoc programmatically (display only) =====REPORT zidoc_read. PARAMETERS p_docnum TYPE edi_docnum OBLIGATORY. DATA: ls_control TYPE edidc,      lt_data    TYPE STANDARD TABLE OF edid4,      ls_data    TYPE edid4,      lt_status  TYPE STANDARD TABLE OF edids,      ls_status  TYPE edids. START-OF-SELECTION.* Control record: who, what, direction  SELECT SINGLE * FROM edidc INTO ls_control WHERE docnum = p_docnum.  IF sy-subrc <> 0.    WRITE: / 'IDoc not found'.    RETURN.  ENDIF.  WRITE: / 'Direction  :', ls_control-direct,          " 1 = outbound, 2 = inbound         / 'Message    :', ls_control-mestyp,         / 'Basic type :', ls_control-idoctp,         / 'Extension  :', ls_control-cimtyp,         / 'Partner    :', ls_control-sndprn, ls_control-rcvprn,         / 'Status     :', ls_control-status. * Data records: segments with business data (SDATA)  SELECT * FROM edid4 INTO TABLE lt_data WHERE docnum = p_docnum ORDER BY segnum.  LOOP AT lt_data INTO ls_data.    WRITE: / ls_data-segnum, ls_data-segnam, ls_data-hlevel.  ENDLOOP. * Status records: processing history  SELECT * FROM edids INTO TABLE lt_status WHERE docnum = p_docnum ORDER BY countr.  LOOP AT lt_status INTO ls_status.    WRITE: / ls_status-status, ls_status-credat, ls_status-cretim, ls_status-statxt.  ENDLOOP. * Standard alternative: FM IDOC_READ_COMPLETELY reads all three record types

Real project scenario

A customer complained that an order sent by EDI never arrived. The sales team assumed SAP had lost it. In WE02 the inbound IDoc was found with status 51: the customer's material number had no customer-material info record.
After the master data team created the record, the IDoc was reprocessed in BD87 and posted with status 53. The team learned to check IDoc status first before escalating "missing orders".

Common mistakes

  • Assuming sent means posted.
  • Looking only at SAP documents, not at IDoc status.
  • Confusing message type and basic type.
  • Reading EDID4 SDATA without the segment structure.
  • Reprocessing without understanding the error.

Best practices

  • Check control, data and status records together.
  • Use WE02/WE05 and BD87 for monitoring.
  • Know the message types of your interfaces.
  • Correct root causes before reprocessing.
  • Document partner and interface setup.

Interview angle

Questions: "What is an IDoc?", "What are the record types?", "Difference between ALE and EDI?"
Strong answer: intermediate document for asynchronous exchange; control record EDIDC (direction, message type, basic type, partners, status), data records EDID4 with segments, status records EDIDS; ALE between SAP systems, EDI with external partners; outbound via port, inbound via partner profile/process code/FM; monitor WE02/WE05/BD87, test WE19.

Practice this lesson

Quick check

1. Which IDoc record holds the processing history with status numbers and messages?

2. What does IDoc stand for?

3. Which IDoc record contains sender, receiver, message type and basic type information?

Interview questions

1. What is an IDoc in SAP?

Answer it in your own words first, then compare.

2. An inbound ORDERS IDoc failed with status 51. Which parts of the IDoc do you look at first, and why?

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.

More lessons in this topic

Interview questions on this topic

Related SAP topics