What is IDoc

Definition 1
IDoc, short for Intermediate Document, is a SAP document format for business transaction data transfers. Non SAP-
systems can use IDocs as the standard interface (computing) for data transfer. IDoc is similar to XML in purpose, but
differs in syntax. Both serve the purpose of data exchange and automation in computer systems, but the IDoc-
Technology takes a different approach.

While XML allows having some metadata about the document itself, an IDoc is obliged to have information at its
header like its creator, creation time etc. While XML has a tag-like tree structure containing data and meta-data,
IDocs use a table with the data and meta-data. IDocs also have a session that explains all the processes which the
document passed or will pass, allowing one to debug and trace the status of the document.

Different IDoc types are available to handle different types of messages. For example, the IDoc format ORDERS01
may be used for both purchase orders and order confirmations.

IDoc technology offers many tools for automation, monitoring and error handling. For example, if the IDocs are
customized that way on a particular server, then a user of SAP R/3 system creates a purchase order; this is
automatically sent via an IDoc and a sales order is immediately created on the vendor's system.

When this order cannot be created because of an application error (for example: The price per piece is lower than
allowed for this material), then the administrator on the vendor's system sees this IDoc among the erroneous ones
and can solve the situation. If the error is in the master data at the vendor's system, he can correct them and order
the IDoc to be processed again.

Because of the flexibility and transparency of IDoc technology, some non-SAP technologies use them as well.

Definition 2
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 simple words, an idoc is like a data file with a specified format which is exchanged between 2 systems which know
how to interpret that data.

IDOC stands for " Intermediate Document"

When we execute an outbound ALE or EDI Process, an IDOC is created. In an inbound ALE or EDI process, an IDOC
serves as input to create an application document. In the SAP System, IDOCs are stored in database. Every IDOC has
a unique number (within a client).

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

Configuration Steps in IDOC

IDOC or Intermediate Documents are commonly used in case of data migration between SAP systems or between
SAP and legacy system or vice versa. This blog details the steps involved in configuring a new IDOC and also list’s
down the various transactions that are used while working with IDOCs.

The I doc structure consists of 3 parts –

1. The administration part (Control Record)- which has the type of idoc, message type, the current status, the
sender, receiver etc. This is referred to as the Control record.
 2. The application data (Data Record) - Which contains the data. These are called the data records/segments.
3. The Status information (Status Record)- These give you information about the various stages the idoc has
passed through.

You can view an I-DOC using transaction WE02 or WE05

As seen the screenshot above IDOC record has three parts Control, Data and Status.

Let's look into them in detail Control, Data and Status Record.

Control Record
 All control record data is stored in EDIDC table. The key to this table is the IDOC Number
 It contains information like IDOC number, the direction(inbound/outbound), sender, recipient information,
channel it is using, which port it is using etc.
 Direction '1' indicates outbound, '2' indicates inbound.

Data Record
 Data record contains application data like employee header info, weekly details, client details etc.
 All data record data is stored in EDID2 to EDID4 tables and EDIDD is a structure where you can see its
components.
 It contains data like the idoc number, name and number of the segment in the idoc, the hierarchy and the
data
 The actual data is stored as a string in a field called SDATA, which is a 1000 char long field.

Status Record
 Status record is attached to an I-DOC at every milestone or when it encounters errors.
 All status record data is stored in EDIDS table.
 Statuses 1-42 are for outbound while 50-75 for inbound

IDOC Types
An I DOC Type, (Basic) defines the structure and format of the business document that is to be exchanged.  An IDOC
is an instance of an IDOC Type, just like the concept of variables and variables types in programming languages. You
can define IDOC types using WE30

IDOC TERMINOLOGIES

IDOC (BASIC) TYPE

IDoc Types are based on the EDI standards and mostly on EDIFACT standards. 
Basic Types (or IDoc Type) defines the structure of an IDoc. Each basic type describes standard IDoc segments,
format of data fields and their size. Basic Type also defines number of segments and fields in an IDoc. All the fields
that are necessary for transmission of message for a particular business transaction are mapped in different
segments. It also defines the structure and relationship of IDoc segments along with mandatory and optional
segments.

IDOC EXTENSION
Basic type contains all the standard fields that are necessary for carrying out a business transaction. However, if any
additional values are to be sent to the partner then we can make use of the IDoc Extension feature. IDoc extension is
extension of basic type and contains additional custom IDoc segments and fields that are not available in standard
basic type.

IDOCs can be classified into two. Inbound IDOCs and Outbound IDOCs.
 
Inbound IDOC: These are IDOCs which get the data into SAP system from external source i.e PI system  or any other
external system.
Outbound IDOC: These are IDOCs which are sent out from SAP system to any other system. i.e PI system or any
other external system.
 
Step 1: We need to check the RFC connections to the target system, it can be PI system or any external system. If it is
to a PI system, then we need to check the connection under ABAP connections in  SM59 transaction and for external
system under HTTP Connections to External System.

Step 2: Create a port in transaction WE21 which shows the target system’s RFC destination.
Step 3: In transaction WE20, create a partner profile and mention the message type details. In case of Outbound
IDOC’s, mention the message types under Outbound Parameters. In case of Inbound IDOC’s, mention the message
types under Inbound Parameters. For outbound parameters, maintain port and IDOC details, because port describes
to which system the IDOC has to flow. Whereas in Inbound IDOC, mention the process code details which
determines the inbound function module for processing the data.
Step 4: Message type SYNCH is the default message type for outbound parameters. Choose a particular message
type and maintain the below settings. Under the receiver port mention the port created in transaction  WE21. In
Output mode, choose Transfer IDOC immediately. In IDOC type mention the IDOC associated with the Message Type.
Step 5: For Inbound IDOCs, mention the process code as APL1 and choose option Trigger Immediately under
Processing by Function Module.
Step 6: In transaction BDFG, we can see which ALE function module we need to enhance for our requirement. In
case, we are working with Business Partner we can choose the FM as CRMXIF_PARTNER_SAVE and the Business
Object Type as ‘BUS1006’. In IDOCs, SAP by standard provides us to exchange the business partner master data
details, BP relationships and BP Hierarchies.
Step 7: In case we are working with Business Transactions we can choose the FM as CRMXIF_ORDER_SAVE and the
Business Object Type as ‘BUS20001’.
Step 8: In our example let us work upon Business Partners. Select the FM name and the Business Object type and
click enter. By default, all standard messages types would be displayed out. Now to create a new message type, click
on Create button as shown below. You will get a popup where in you can enter a Z name.
Step 9: Once the Z message type is created. Release it as shown.
Step 10: Select the Z message type and click on the Display button to view the details.
Step 11: With Z Message Type, Z FM’s for both Inbound and Outbound gets created.
Step 12: In transaction WE30 we can check the IDOC created.
Step 13: In transaction WE31 we can check the IDOC segment.

Step 14: For Inbound IDOCs in transaction code WE42, select the process code APL1 and click on display. Assign a Z
FM-ZAPPL_IDOC_INPUTI. Create a copy of the standard FM APPL_IDOC_INPUTI into ZAPPL_IDOC_INPUTI.
Step 15: Under Logical Message, mention the Z message type created.
Step 16: In transaction WE81, we can see the message type details.
Step 17: In transaction WE82, we can see the message type and basic type details.
Step 18: For outbound IDOCs in transaction BD64, create a distribution model. Go to change mode and click on
‘Create Model View ‘. Enter a description and Technical name.
Step 19: Add the message type under the Distribution Model and maintain the sender and receiver system details.
Step 20: In transaction BD82, generate the partner profile for the newly created distribution model.
Step 21: In transaction SMOEAC, we create the sites and subscriptions. Site is the destination where the data needs
to be sent. Subscription is to identify what is the object to be exchanged. (In case of BP data it will be All Business
Partner MESG). Subscriptions are assigned under Sites. Type would vary based on our need.
Step 22: In transaction CRMXIF_C1, we maintain the message type details against the Site name.
Step 23: We can even restrict an Outbound IDOC flow based on any condition to a particular Site. A times there
could be multiple sites in a system, we can control the flow of IDOC here as well. This can be achieved by maintaining
an entry in table – SMW3FDCUST, we assign a copy of standard FM
– SMW3_OUTBOUNDADP_CALLADAPTERS against BDoc Type BUPA_MAIN, which is used to do any further
customizations. We can do the same for other IDOC types.

In the Z FM, input parameter HEADER we get the Site ID details, based on that we can control the changing
parameter – RECEPIENTS.

Step 24: Apart from the above steps we can use Transaction WE02/WE05 to display any IDOC and WE60 for IDOC
Documentation. To reprocess any IDOC use transaction WE19 adn inoput teh IDOC number, a new number gets
generated.
 
Step 25: Any IDOC has 3 records types – Control, Data and Status. Control Records displays the direction of the
IDOC, message type/basic type details.

Data record display the data under multiple segments. In Status Record we can check the IDOC status whether it is a
success or failure.

Tables for these 3 record types are as below.

Control Record – EDIDC

Data Records    – EDIDD

Status Record   – EDIDS