SAP IDoc Tutorial - Part 1: What is an IDoc?


This is the start of another series on this blog: A complete introduction to IDocs in SAP. We start in this post by explaining the IDoc basics and the usage of IDocs in SAP ERP environments.

Recommended Now

Fire TV Stick Lite Essentials Bundle

This bundle contains Amazon Fire TV Stick Lite and Mission USB Power Cable. The USB power cable eliminates the need to find an AC outlet near your TV by powering Amazon Fire TV directly from your TV's USB port. Includes special power management circuitry that enhances the peak power capability of the USB port by storing excess energy and then releasing it as needed.

Check it out on →

What is an IDoc in SAP ERP?

An IDoc ("Intermediate Document") is a container for standardized data exchange. IDocs can be used to exchange data between two processes, between SAP systems, or between SAP and non-SAP systems.

This definition for SAP IDocs should cover all use cases. And by the way, the correct capitalization is IDoc - not IDOC or Idoc.

IDocs are used to exchange data between two places that need it. Both systems must be able to understand the semantics and syntax of the IDoc. You can think of IDocs simply as a standardized interface format, just like a REST API response that is consumed by a frontend. IDocs are created when an outbound ALE or EDI Process is executed.

IDocs are identified by an IDoc ID or Number that is unique within a client. This is important - the IDoc number on one system does not uniquely identify the same IDoc on another system! Some other important facts about IDocs:

Structure of IDocs in SAP ERP

Idocs come in two flavors. Traditionally, they are a fixed length format (1000 bytes), but in newer releases there is also an XML based format available. This has the advantage of being more flexible in use, being based on the W3C XML standard. Using SAP transaction WE60, the documentation for all IDocs can be seen.

Example Structure of an SAP IDoc

In SAP systems, IDocs always consist of the following three parts.

This structure can be seen in SAP systems as well of course, using transactions WE02 or WE05.

Structure of the same IDoc, seen in SAP transaction WE02 (Display IDoc)

IDoc Types

An IDoc type defines what kind of data is contained in the IDoc. You can imagine an IDoc as an instance of an IDoc type, just like an object is an instance of a class in object-oriented programming. The IDoc type controls, among other things:

IDoc types can be defined using SAP transaction WE30 (IDoc Type Development).

Let's check out some more detailed information about the records present in each IDoc.

Control Record

Control records are stored in the table EDIDC with the IDoc number as the primary key. Some of the most important information stored in the IDoc control record is:

Data Record

The data record contains application data - such as invoice, order or delivery data. The data records for each IDoc are stored in SAP Tables EDID2, EDID3 and EDID4. The actual payload is stored as a plain text string in the field SDATA, which is a 1000 char long field (hence the fixed-length for IDocs). Data records are further structured into segments. Segments are reusable data structures that define the format of data records in IDocs. For each segment, there is a segment type, a segment definition, and segment documentation that can be viewed with transaction WE31. The last three characters in a segment name are the version that is incremented with each change in a new SAP ERP release.

Status Record

In every step in the IDoc processing, a status reord is attached to an IDoc. This happens both when the processing was successful as well as if an error occurs. Status records are stored in table EDIDS. The statuses 1-42 are for outbound processing, whereas statuses 50-75 apply for inbound processing.

IDoc Tables in SAP ERP

IDocs are stored in the database, just like any other SAP object. These are the relevant tables for IDocs in SAP:

Extending IDocs with Extension Segments

Like (almost) everything in SAP ERP, IDocs can be extended. The instrument for this are extension segments. For every IDoc type, you can not modify the basic structure of the segments as this would break the standards which IDocs are based on and therefore compatibility with other systems. But what you can do is add extension segments, adding custom data to the end of the IDoc.

I will do another blogpost describing how to do this in more detail.

IDoc Type Documentation in SAP ERP

Each IDoc type has a very detailed documentation that can be viewed directly in SAP ERP, using transaction WE60. An example:

More IDoc-related definitions

To understand the context IDocs operate in, it is useful to have a couple terms explained before we take a closer look at actually working with IDocs.

Message Types and IDoc Views

Message Types represent specific types of business documents in EDI - such as orders, order confirmations, invoices. IDoc Types can be mapped to Message Types in a many-to-many relationship using transaction WE81.

Since IDocs can be used for multiple message types, they often contain more fields than necessary for a particular message. Therefore, IDoc views can be used to create projections of IDoc types that use only some of the IDoc type's available segments. They apply only to outbound processing, as in inbound processing this overhead is not problematic. IDoc views can be maintained using transaction WE32.

Partner Profiles

Partner Profiles in the context of EDI/ALE/IDoc are business partners with which an SAP system can exchange documents. Using transaction WE20, you can maintain the parameters necessary for the data exchange.


Ports are the place where the technical properties of a connection between an SAP system and a connected system ("subsystem") are maintained. They define what happens with IDocs after they are sent. Some of the most common ports are the HTTP port for direct IDoc exchange in XML format, the File port used by EDI or the TRFC port used by ALE.

The file port is great for debugging, as it will dump the created IDoc in a file within a file system. It is also the most basic  way to build interfaces reading data from SAP, since pretty much every other system can be configured to read files in certain formats.

A full IDoc process flow

Here's a high-level example of the steps involved in processing an IDoc. Let's assume we want to send a purchase order to a vendor connected to us via EDI. Let's assume the vendor has SAP ERP as well.

  1. The purchase order is created through whichever way in the SAP system.
  2. An IDoc is created automatically and sent to the partner. Since EDI is enabled and a partner profile is maintained, the IDoc is sent to that partner.
  3. The vendor receives the IDoc in his inbound processing queue. It gets assigned a different number since it is in a different system now, but the message type remains the same!
  4. The IDoc is processed for the vendor, creating an SAP business object using the data in the data record. In this case, it would likely create a sales order.
  5. An order confirmation IDoc is created and sent back to the original party via the same way.

Sending data out of your own SAP system is called Outbound Processing, and receiving data from other systems is called Inbound Processing. SAP developers or consultants are frequently tasked to set up these communication routes. Here are the steps required:

How to Set Up Outbound Processing for IDocs

These are the high-level steps needed to setup outbound IDoc processing.

  1. Select the IDoc type to use (transaction WE30).
  2. Check if it is necessary to create a Message Type (WE81).
  3. If necessary, assign the IDoc Type to a Message Type (WE82).
  4. Select or create a port (WE21).
  5. Create or select a partner profile (WE20). This contains the communication details for the partner that the IDoc is sent to.
  6. Create something that generates IDocs - either manually with ABAP code in a user exit or using the message control method (in this case, it is necessary to create a function module IDoc creation and assign it to an outbound process code).
  7. Trigger the IDoc.

How to Set Up Inbound Processing for IDocs

These are the high-level steps needed to setup inbound IDoc processing.

  1. Select the IDoc type to use (transaction WE30).
  2. Check if it is necessary to create a Message Type (WE81).
  3. If necessary, assign the IDoc Type to a Message Type (WE82).
  4. Create a function module that actually does something with the IDoc that was received. This is where your custom inbound processing logic will go.
  5. Maintain your function module so that it can actually process inbound IDocs (BD51).
  6. Assign the new inbound function module to the message type (WE57).
  7. Define an inbound process code (WE42).
  8. Create or select a partner profile (WE20).
  9. Wait for or manually trigger an inbound IDoc to see how it is processed.

IDoc Transactions in SAP ERP

This helpful list contains a selection of IDoc transactions that are useful when developing or working with IDocs.

IDoc Search and Display Transactions

IDoc Administration and Documentation Transactions

IDoc Development Transactions

IDoc Testing Transactions

Happy IDoc development!!