SAP IDOC Tutorial in ABAP: Step-by-Step Guide

What is an IDoc?

IDoc is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.

In other words, an IDoc is like a data file with a specified format which is exchanged between two systems that know how to interpret that data.

IDoc stands for “Intermediate Document“.

When you execute an outbound ALE or EDI process, an IDoc is created. In the SAP System, IDocs are stored in the database, and every IDoc has a unique number within a client.

Key Features

• IDocs are independent of the sending and receiving systems (SAP-to-SAP as well as non-SAP).
• IDocs are based on EDI standards, ANSI ASC X12, and EDIFACT. In case of any conflict in data size, IDoc adopts the one with greater length.
• IDocs are independent of the direction of data exchange, e.g. ORDERS01 in the Purchasing module supports both Inbound and Outbound.
• IDocs can be viewed in a text editor because the data is stored in character format instead of binary format.

Structure of an IDoc

The IDoc structure consists of three parts:

1. The administration part (Control Record) — holds the type of IDoc, message type, current status, sender, receiver, and similar metadata. This is referred to as the Control Record.
2. The application data (Data Record) — contains the business data. These are called the data records or segments.
3. The status information (Status Record) — provides information about the various stages the IDoc has passed through.

You can view an IDoc using transaction WE02 or WE05.

As seen in the screenshot above, the IDoc record has three parts — Control, Data, and Status. Each part is explored in detail below.

Control Record

• All Control Record data is stored in the EDIDC table. The key to this table is the IDoc Number.
• It contains information like IDoc number, direction (inbound/outbound), sender, recipient information, channel in use, and port in use.
• Direction “1” indicates outbound and “2” indicates inbound.

Data Record

• The Data Record contains application data such as employee header info, weekly details, client details, and so on.
• All Data Record data is stored in tables EDID2 to EDID4, and EDIDD is a structure where you can see its components.
• It contains data like the IDoc number, the name and number of the segment in the IDoc, the hierarchy, and the data itself.
• The actual payload is stored as a string in a field called SDATA, which is a 1000-character field.

Status Record

• A Status Record is attached to an IDoc at every milestone or when it encounters an error.
• All Status Record data is stored in the EDIDS table.
• Statuses 1–42 are for outbound while 50–75 are for inbound.

IDoc Types

An IDoc Type (Basic) defines the structure and format of the business document to be exchanged. An IDoc is an instance of an IDoc Type, just like the concept of variables and variable types in programming languages. IDoc Types can be defined using transaction WE30.

What is a Segment?

A Segment defines the format and structure of a Data Record in an IDoc. Segments are reusable components.

For each segment, SAP creates the following components.

• Segment Type (version independent)
• Segment Definition (version dependent)
• Segment Documentation

The last three characters represent the version of the segment. Definitions can change as the version changes, but the Segment Type remains the same. Transaction: WE31.

What is an Extension IDoc Type?

An IDoc is of two types:

1. Basic
2. Extension

SAP provides many pre-defined Basic IDoc Types which cannot be modified. If you need to add more data to a restricted Basic Type, you can use an Extension Type. Most of the time you will not need extensions.

Documentation

Each IDoc is thoroughly documented in transaction WE60.

Message Type

A message represents a specific type of document that is transmitted between two partners, for example Orders, Order Responses, and Invoices.

An IDoc Type can be associated with many Message Types. Conversely, a Message Type can be associated with different IDoc Types. Transaction: WE81.

IDoc Views

An IDoc Type can be used for more than one Message Type, which results in IDocs containing more fields than required for a particular Message Type.

IDoc Views improve performance in generating IDocs by ensuring that only the relevant segments are filled with data. IDoc Views are important only for Outbound Processing.

Partner Profiles

A partner is a business partner with whom you conduct business and exchange documents.

In the partner profile of a partner with whom IDocs are exchanged, you maintain the parameters that are necessary for exchanging the data. The transaction used is WE20.

Port

The Port defines the technical characteristics of the connection between your SAP system and the other system you want to transfer data with (subsystem). The Port defines the medium in which data is exchanged between the two systems.

There are different types of ports. The two most commonly used are TRFC ports used in ALE and File ports used by EDI.

For TRFC ports, you have to give the name of the logical destination created using SM59. When using a File port, you can specify the directory where the IDoc file should be placed. The other system or middleware then picks up the file from there. A function module can be used to generate a file name for the IDoc. While testing, you can use “Outbound file” to specify a constant file name. The tab “outbound trigger” can be used to supply information if you want to trigger some processing on the subsystem when an IDoc is created at this location. Specify the command file name and the directory that must be run.

Common IDoc Transaction Codes

Transaction Code	Purpose
WE02 / WE05	Display and monitor IDocs
WE30	Create or change IDoc Type
WE31	Create or change Segment
WE20	Maintain Partner Profile
WE21	Maintain Ports
WE42	Define inbound Process Code
WE57	Allocate inbound function module to Message Type
WE60	IDoc Documentation
WE81 / WE82	Create Message Type / associate to IDoc Type
BD51	Define function module characteristics
SM59	Maintain RFC destinations

IDoc Process: A Real-World Example

Consider the example of sending a Purchase Order to a vendor through IDoc.

• Whenever a Purchase Order (PO) is created, the system needs to send an IDoc to the vendor.
• The PO is sent in the form of an IDoc to the vendor (partner). That partner has to be EDI enabled in the system. SAP recognizes that it can send the document to this vendor electronically.
• The PO sent as an outbound IDoc by the customer becomes an inbound IDoc for the vendor. The SAP system on the vendor’s side can process this to create an application document (a Sales Order) on their system.
• Quotations, RFQs, POs, SOs, Invoices, and Delivery Notes are some of the most commonly exchanged documents through IDoc.

The process of data transfer out of your SAP system is called the Outbound process, while data moving into your SAP system is called the Inbound process. As a developer or consultant who sets up these processes for your organization, the steps to configure each are detailed below.

The Outbound Process

Steps involved:

1. Create segments (WE31).
2. Create an IDoc Type (WE30).
3. Create a Message Type (WE81).
4. Associate the Message Type with the IDoc Type (WE82).
5. Create a Port (WE21).
6. If you use the message-control method to trigger IDocs, create the function module that builds the IDoc and link it to an outbound Process Code.
7. Otherwise, create a function module or stand-alone program that creates the IDoc directly.
8. Create a Partner Profile (WE20) with the necessary information in the outbound parameters for the partner you exchange the IDoc with, and trigger the IDoc.

The Inbound Process

Steps involved:

1. Create the Basic IDoc Type (Transaction WE30).
2. Create the Message Type (Transaction WE81).
3. Associate the Message Type with the Basic IDoc Type (Transaction WE82).
4. Create the function module for processing the IDoc.
5. Define the function module characteristics (BD51).
6. Allocate the inbound function module to the Message Type (WE57).
7. Define the Process Code (Transaction WE42).
8. Create the Partner Profile (Transaction WE20).

FAQs