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

What is an IDoc in SAP ERP?

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:

• IDocs can be used independently from the technical architecture of sending and receiving systems. This means that you could, in theory, use IDocs for data exchange between non-SAP systems - however this is never done in the real world.
• IDocs are based on (quite old) EDI standards, ANSI ASC X12 and EDIFACT.
• IDocs are characterized by IDoc types which define the data they can hold. The same IDoc type is used for inbound and outbound data exchange. There is no difference in the data coming in and going out.
• IDocs are not encoded in a binary format - instead, they can be viewed in a text editor and even exported as XML.

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.

• The Control Record contains system information such as the type of IDoc, e.g. "INVOIC02" for invoices. It also contains other administrative information such as the partner port, which SAP release this IDoc was created in and other things.
• Data Records are the place where the actual content of IDocs is stored. Data records consist of several segments, the number, type and order of which depends on the IDoc type. Segments in SAP IDocs can be seen as a hierarchical tree of application payload, such as an order header and several order positions.
• Status records are attached to an IDoc for documentation and debugging. They are a series of messages documentating the flow and processing of the Idoc, containing information like "IDoc was created", "The recipient exists", "IDoc successfully passed to the port", "Order was booked". Using the information in status records, SAP consultants can understand how the IDoc was processed by the involved systems and where reasons for errors might lie.

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:

• Which segments the IDoc can contain and how the contents of the data record must be interpreted (remember, it's just a 1000 byte plaintext string)
• What kind of processing is applied to the IDoc after it is created and sent - inbound or outbound

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:

• IDoc number time of creation and time of last modification
• SAP Release for IDoc
• Status
• Direction (1 means inbound, 2 means outbound)
• Receiver port (SAP System, EDI subsystem)
• Partner Type and Number of Receiver
• Recipient address
• EDI standard and version
• Port, partner type, partner number and address of sender

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:

• EDIDC - Table for IDoc control records
• EDID2, EDID3, EDID4 - Tables for IDoc data records
• EDIDS - Table for IDoc status records

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.

Port

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

• WE05 - IDoc Lists
• WE02 – Display IDocs
• WE09 – Search IDocs by Content
• WE10 – Search for IDocs in Archive
• WE11 – IDoc Deletion

IDoc Administration and Documentation Transactions

• WE06 – Active IDoc Monitoring
• WE07 – IDoc Statistics
• BD87 – Status Monitor for ALE Messages
• WE20 – Partner Profiles
• WE21 – Port definitions
• WE60 – Documentation for IDoc types
• WE64 – Documentation for Message types
• SM59 – RFC Destinations
• SM58 – Error protocol asynchr. RFC

IDoc Development Transactions

• WE31 – Development IDoc Segment
• WE30 – Development IDoc Type
• WE81 – Logical Message Types
• WE82 – Assign Message Types to IDoc Types
• WE41 – Process codes, outbound
• WE42 – Process codes, inbound
• BD51 – Maintain function modules (inbound)
• WE57 – Assignment Messages for Application Objects
• WE32 – Development IDoc Views

IDoc Testing Transactions

• WE12 – Test Modified Inbound File
• WE14 – Test Outbound Processing
• WE15 – Test Outbound Processing from MC
• WE16 – Test Inbound Processing
• WE17 – Test Status File
• WE18 – Create Status File
• WE19 – IDoc Test Tool

Happy IDoc development!!