IDoc, short for Intermediate Document, is an SAP document format for business transaction data

transfers.[1] Alternatively, IDoc can also refer to an IRise document.

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 obligated 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 customised 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.
An IDoc consists of

Control record (it contains the type of IDoc, port of the partner, release of SAP R/3 which
produced the IDoc etc.)

Data records of different types. The number and type of segments is mostly fixed for each
IDoc type, but there is some flexibility (for example an SD order can have any number of items).

Status records containing messages like 'IDoc created', 'The recipient exists', 'IDoc was
successfully passed to the port', 'Could not book the invoice because...'

IDoc Transactions in SAP

The following transactions can be used to create and process IDocs. The list does not include any
transaction required for the development of new IDoc types. Please note that you get a
comprehensive list of available transactions by using area menu WEDI.

WE02 - IDoc List report

This report can be used to display and edit IDocs.

WE19 - Test tool for IDoc processing

This transaction allows the creation of IDocs for testing.

WE20 - Partner Profile

This transaction determines a processing code based on the partner profile identified by the control
record of the IDoc.

WE21 - Ports in IDoc processing

This transaction identifies an external port (RFC, File, ABAP-PI, etc.) that controls the IDoc flow to an
external system.

WE41 - Outbound process code

This transaction links an outbound processing code specified in a partner profile to a function module.

WE42 - Inbound process code

This transaction links an inbound processing code specified in a partner profile to a function module.

BD87 - Inbound processing

This transaction processes inbound IDocs.

BD88 - Outbound processing

This transaction processes outbound IDocs.

Error Handling
SAP provides a standard report (WE02) to display and edit IDocs. Unfortunately, the provided
functionality is very basic; therefore, most customers are forced to create their own custom solution.

What is an SAP IDoc?

Written by anon

What is an IDoc?
An IDoc Type is SAP's format for data being moved between applications. Essentially, SAP has defined what a
sales order, financial statement, invoice, etc will look like electronically. This includes how fields are grouped
together (segments), the order and hierarchy of these groupings, and the format of each individual field.
If you're familiar with EDI at all, then an IDoc will look very familiar to you. Nearly everything you're used to is
there: from segment name to allowable codes to min/max occurs.
It is important to note that an IDoc Type is really just a structure defined on the system and given a name (i.e.,
ORDERS04). An actual IDoc, however, consists of data, which fits within the defined structure of the IDoc Type.
This IDoc is identified by a number rather than by a type.

IDoc Structure

The "only once" rule

It is valuable to note that SAP only allows one occurence of each segment type within the IDoc structure. For
instance, the E1EDKA1 segment may only exist once within the IDoc type.
Now, does that mean you can only have one E1EDKA1 segment in an actual IDoc? Of course not. Segments
may occur multiple times if the "max occurs" setting for that segment is greater than one. This is how the
E1EDKA1 segment can appear multiple times in the ORDERS04 IDoc.
This isn't a big deal if you're just using canned IDocs from SAP; but it is a useful consideration if you need to
extend an existing IDoc substantially or create your own.

Generic Structure
Data within an IDoc is divided into three sections
1.

Control Record, which contains (Table EDIDC)

1.

2.

3.
2.

1.

Receiving Partner Type/ID (RCVPRT, RCVPRN)

2.

Logical Message Type

3.

Test Flag

Other Fields
1.

IDoc Number (DOCNUM)

2.

Direction (1=Outbound; 2=Inbound)

3.

Sending Partner Type/ID (SNDPRT, SNDPRN)

4.

Status

5.

Receiver/Sender Port

6.

Created Timestamp

7.

Changed Timestamp

etc.

Data Records (Table EDID4 in 4.6C)

1.

2.
3.

Key Fields (for inbound)

Admin Data (39 bytes)

1.

IDoc Number (DOCNUM)

2.

Segment Number

3.

Segment Name (SEGNAM) (e.g., E1EDK01, E1EDK03, etc)

4.

etc

Actual Data (SDATA 1,000 bytes)

Status Records (Table: EDIDS)

1.

IDoc Number (DOCNUM)

2.

Counter (COUNTR)

3.

Status (STATUS)

4.

etc

Additional Considerations
1.

Data record table is version-specific. EDID4 is valid for the current release of SAP R/3 and may change
in future versions.

2.

The control record is common across all transactions and is used for routing the IDoc to the correct port
in external processing, or to the correction function module or workflow item for inbound processing.

3.

Each IDoc may have several data records, which are arranged hierarchically. The data segment table
(EDID4) contains this nesting information in the hierarchy field, etc.

4.

Each IDoc may have several status records, which are arranged in sequence.

5.

Segment Types begin with E1. This is the internal SAP format.

6.

Segment Definitions begin with E2. This is a fixed, version-specific format which defines how the outside
world sees the segment.

7.

Segment Documentation records begin with E3.

8.

Outbound IDocs are created directly by a function module, or may be created via message control. Most
outbound documents within OTC are created by message control.

9.

The global IDoc Administrator is defined in transaction OYEA.

Status Codes
Outbound Codes
00 Not used, only R/2
01 IDoc created
02 Error passing data to port
03 Data passed to port OK
04 Error within control information of EDI
subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check

Inbound Codes
50 IDoc added
51 Error: Application document not posted
52 Application document not fully posted
53 Application document posted
54 Error during formal application check

55 Formal application check OK

56 IDoc with errors added
57 Test IDoc: Error during application
check
08 Syntax check OK
58 IDoc-Copy from an R/2 connection
09 Error during interchange handling
59 Not used
10 Interchange handling OK
60 Error during syntax check of IDoc
(inbound)
11 Error during dispatch
61 Processing despite syntax error
(inbound)
12 Dispatch OK
62 IDoc passed to application
13 Retransmission OK
63 Error passing IDoc to application
14 Interchange Acknowledgement positive 64 IDoc ready to be transferred to
application
15 Interchange Acknowledgement negative 65 Error in ALE service
16 Functional Acknowledgement positive 66 IDoc is waiting for predecessor IDoc

(serialization)
17 Functional Acknowledgement negative 67 Not used
18 Triggering EDI subsystem OK
68 Error - no further processing
19 Data transfer for test OK
69 IDoc was edited
20 Error triggering EDI subsystem
70 Original of an IDoc which was edited
21 Error passing data for test
71 IDoc reloaded from archive
22 Dispatch OK, acknowledgement still due 72 Not used, only R/2
23 Error during retransmission
73 IDoc archived
24 Control information of EDI subsystem 74 IDoc was created by test transaction
OK
25 Processing despite syntax error (outbound)
26 Error during syntax check of IDoc (outbound)
27 Error in dispatch level (ALE service)
28 Not used
29 Error in ALE service
30 IDoc ready for dispatch (ALE service)
31 Error - no further processing
32 IDoc was edited
33 Original of an IDoc which was edited
34 Error in control record of IDoc
35 IDoc reloaded from archive
36 Electronic signature not performed (timeout)
37 IDoc added incorrectly
38 IDoc archived
39 IDoc is in the receiving system (ALE service)
40 Application document not created in receiving system
41 Application document created in receiving system
42 IDoc was created by test transaction

What is SAP IDOC

The full form of IDoc is Intermediate Document. Its a SAP standard document format for
exchanging data between different application servers. The Idoc interface will contain the data
structure and processing logic. The data structure is known as IDoc.Using IDoc different
application servers can be connection via a message based interface. It has an extensive
exception handling before the data is stored in the application server. Electronic Data
Interchange (EDI) and Application Link Enabling (ALE) are the main techniques using IDoc to
exchange data between systems.
Segments are the basic building blocks of Idoc and store the actual data. SAP supplies some
IDocs by default and they are known as basic types of idoc. We can add additional data to the
existing basic types using reference segments. We can define our own IDoc types if the basic
types wont fit for our requirements.
Structure of an IDOC
Every IDoc consist 3 records they are
Control Record: It contains the general information about that IDoc. It stores the sender
identification, receiver identification and IDoc type.Cotrol Records are stored in the data
dictionary table EDIDC and it can be views by transaction code SE11.Idoc type is the key
information for IDoc processor to interpret the data containing in that IDoc.
Important Fields containing in Control records are

Mestyp: (Logical message type)

Idoctp: (Idoc type -Basic structure of the IDoc)

Cimtyp: (Structure of customer extension)

Rcvprt: (Partner type of the receiver)

Rcvprn: (Partner number of the receiver)

Rcvpfc: (Partner function of the receiver)

Data Records: It contains the actual data to process.Data records are stored in the data
dictionary table EDIDD.Data records consists with two parts segment name and segment data.
For each segment type of the IDoc structure, there is a DDIC structure with the same name. A
field string with this structure is used for creating a data record. The application data is mapped
to the field string. The segment type is written to the field SEGNAM, and the field string is written
to the field SDATA. This data record is then included in the internal table with the structure edidd.
The fields in data records are

Segnam: (Segment type)

Sdata: (Actual data with maximum 1000 byte-long character)

Status Record: It stores the status of IDOC. The status records are stored in the data
dictionary table EDIDS.
The important fields in these records are

DOCNUM

STATUS

STATXT

SEGNUM

Steps to create a basic type Idoc

Creation of a new basic type of IDOC consists of several steps. Here is the detail explanation
and steps to do for that.
Step 1: Creation of Segments
Here are the steps to define segments

Enter Transaction code WE31

Select Utilities -> Requests (Organizer)

Specify segment type and choose create

Enter a short description of the segment and enter the corresponding field names and
data elements associated with that segment.

Goto -> Documentation and describe the segment type

Come back to segment editor

Save and Enter the segment in a transport request

Step 2: Define a basic Idoc Type

Enter transaction code WE30

Enter a name for the basic IDoc type and mark basic type as the development object.
And choose create

Enter a description for the basic Idoc type and choose tick mark button.

Position the mouse on header and choose create button

Enter the segments.

Save

Step 3: Assigning Message types

We need to create new message types only if the existing message not matching with our
requirements.
Steps to create a new message type

Enter Transaction WE81

Choose edit button and then new entries

Enter the message type with description

Save

Steps to assign basic Idoc type to message type

Enter transaction WE82

Choose edit button and then new entries

Enter the message type, basic type and SAP release in their corresponding columns.

Save data

Step 4: Create function Module for outbound processing

The steps for creating a function module have been described in our earlier posts. Here is a brief
about the steps.

Open the function builder to create our new function module

Create the segments as global data and code the function module to pass the application
data to the corresponding segments.

Activate the function module

Step 5: Maintaining the Attributes of a Function Module

Use transaction code BD51 to maintaining the Attributes of a Function Module (Like the settings
for dialog possible etc)
Step 6: Assign function module to the basic Idoc
Use Transaction code WE57 and then assign the function module to various objects as per our
requirements. This step is the ALE registration for the function module.
Step 7: Assigning a Process Code
This step is used to assign a new process code to the new function module. This enables the
function module to be identified from the partner profiles defined in the IDoc Interface when an
IDoc of the new message type is received.

Enter transaction code WE42

Enter process code and a description. Choose the Processing with ALE and Processing
by function module options and save your entries. In the maintenance screen assign the
inbound function module to the process code.

Choose new entries

In the detail screen enter Process code, Module fame, Idoc fame, Application Object
fame etc

Save

Enter transaction code WE42 again

Go back to maintain the inbound process codes and choose the Logical message
navigation.

Choose change mode and select new entries

Enter the message type and process code

Save

Step 8: Defining a partner

The new basic type must be entered in the partner profiles before being used. Use transaction
code WE20 to create partner profile. Partner number, partner type, Partner function, message
type, permitted agent and process code are the important fields to maintain in inbound partner
profiles.

These are the common steps involved in creating a new basic type Idoc. The other steps you
need to do after this may be

Create Logical System

Create RFC destination

Using of test tool for IDOC

IDOC status codes

After the process of inbound function module and outbound function module the state of status
will be recorded in the status record of IDOC.We can view the status by using transaction codes
WE02, WE05 and WE07.Here is the list of main IDOC stats codes for Outbound and Inbound
IDOC.
Outbound IDOC status codes with status description.

01: IDoc generated

02: Error passing data to port (Its an error status)

03: Data passed to port OK

04: Error within control information of EDI subsystem

05: Error in translation

06: Translation successful.

07: Error on syntax check (Its an error status)

08: Syntax check successful

09: Error on interchange handling (Its an error status)

10: Interchange handling successful

11: Error on dispatch (Its an error status)

12: IDOC Dispatch successful

13: Retransmission successful

14: Interchange Acknowledgement positive

15: Interchange Acknowledgement negative (Its an error status)

16: Functional Acknowledgement positive

17: Functional Acknowledgement negative (Its a warning error status)

18: Triggering EDI subsystem successful

19: Data transfer for test successful

20: Error on triggering EDI subsystem (Its an error status)

21: Error on passing data for test (Its an error status)

22: Dispatch successful, acknowledgement still due

23: Error on retransmission (Its an error status)

24: Control information of EDI subsystem successful

25: Processing despite syntax error (Its a warning error)

26: Error during syntax check of IDoc (Its an error status)

27: Error in ALE dispatch level (Its an error status)

29: Error in ALE service (Its an error status)

30: IDoc is ready for dispatch in ALE service

31: IDOC is marked for deletion.

32: IDoc was edited

33: Original of an IDoc which was edited

34: Error in control record of IDoc (Its an error status)

35: IDoc reloaded from archive

36: Timeout error on Electronic signature not performed (Its an error status)

37: IDoc added incorrectly (Its an error status)

38: IDoc archived

39: Arrival of IDOC in target system confirmed

40: Application document not created in target system (Its an error status)

41: Application document created in target system

Inbound IDOC status codes with status description.

42: IDoc was created by test transaction

50: IDoc added

51: Application document not posted (Its an error status)

52: Application document partially posted (Its an error status)

53: Application document posted successfully.

54: Error during formal application check (Its an error status)

55: Formal application check successful

56: IDoc with errors added (Its an error status)

57: Test IDoc: Error during application check (Its an error status)

60: Syntax error on IDOC (Its an error status)

61: Processing despite syntax error (Its a warning error status)

62: IDoc passed to application

63: Error passing IDoc to application (Its an error status)

64: IDoc ready to be transferred to application

65: Error in ALE service (Its an error status)

66: IDoc is waiting for predecessor IDoc in serialization process

68: IDOC is marked for deletion.

69: IDoc was edited

70: Original of an IDoc which was edited

71: IDoc reloaded from archive

73: IDoc archived

74: IDoc was created by test transaction

Using the standard report RC1_IDOC_SET_STATUS we can change the status of an IDOC if we
require for that. We can reprocess IDoc if we are getting errors.

Here is the list of important ALE IDOC transaction codes and its purposes for a quick reference.
1. SALE This transaction code is used for access IMG ALE Configuration root
2. WE05 IDoc overview
3. WE07 IDoc statistics
4. WE20 This transaction code is used for manually maintain partner profiles
5. WE21 This transaction code is used for Ports in Idoc processing
6. WE47 This transaction code is used for edit IDOC status values. (Real path: SALE ->
Set-Up System Monitoring -> IDoc Status Display -> Edit IDoc Status Values)
7. WE60 This transaction code is used for create IDoc documentation (IDOC header file)
8. SM59 This transaction code is used for Create RFC Destinations
9. SM58 Schedule RFC Failures
10. BD21 Create IDocs from change pointers
11. BD50 This transaction code is used for Activate Change Pointer for Message Type
12. BD52 This transaction code is used for Activate change pointer per change.doc object
13. BD53 This transaction code is used for Reduction of Message Types
14. BD55 This transaction code is used for Defining settings for IDoc conversion
15. BD56 This transaction code is used for Maintain IDOC Segment Filters
16. BD59 This transaction code is used for Allocation object type -> IDOC type
17. BD61 This transaction code is used for Activate Change Pointers Globally
18. BD62 This transaction code is used for Define rules
19. BD64 This transaction code is used for Maintain customer distribution model
20. BD71 This transaction code is used for Distribute customer distribution model
21. BD79 This transaction code is used for Maintain rules
22. BD82 This transaction code is used for Generate Partner Profiles
23. BD87 This transaction code is used for Status Monitor for ALE Messages (Real access
path is Tools -> IDoc Interface/ALE -> Administration ->Monitoring -> IDoc Display
->Status Monitor )
24. BD88 Outbound IDoc reprocessing
25. BDM2 IDoc Trace
26. BDM5 This transaction code is used for Consistency check

27. BDM7 IDoc Audit Analysis

28. WEDI This transaction code is used for ALE IDoc Administration
29. SARA This transaction code is used for IDoc archive administration
30. BALE ALE Distribution Administration

ALE Distribution model using BAPI

In ALE applications BAPIs can be called synchronously and asynchronously but synchronous
communication only using for reading external data. For writing, ALE BAPI distribution use only
asynchronous communication method.
Here is the list of processes in ALE data distribution model using BAPI
Outbound Processing

Receiver determination (Receiver system for the BAPI call will define and filter objects
will check the validity of the receiver. This process take place in application layer)

Calling the generated outbound function module (Data for BAPI call and list of receiver
system are passed to the ALE outbound function module. This take place in ALE layer)

Data filtering

Conversion of BAPI calls into IDoc (IDOC containing the data is transferred and created
from the outbound function module. This take place in ALE layer)

Segment filtering (rarely used one for BAPI)

Field conversion (For converting data fields between different systems)

IDoc version change

Dispatch control (Schedule timing for the dispatch. This step also take place in ALE layer)

IDOC dispatch
In communication layer IDOCs are sent using tRFC or EDI to the target system. This step take
place in communication layer.
Inbound Processing

Segment filtering (rarely used one for BAPI)

Field conversion

Transfer control (Decides when the BAPIs are to be called like or at a later time in
background processing.)

Conversion of IDoc into BAPI call (Data from IDOC segments will stored in the
corresponding parameters of BAPI function module)

BAPI function module call

Determination of IDoc status

Posting of application data and IDoc status

Error handling

IDOC Reprocess reports

We can reprocess IDoc if we are getting errors. Several standard reports are available for this
reprocessing. Here are some standard reports for reprocessing of IDOC.

Report RBDMANI2
We can execute this program for manual reprocess of IDOC.It can be used when we get the
status 51 or status 63 errors for an inbound IDOC.
Report RBDMANIN
It used for Posting of inbound IDocs with Status 51.
Report RBDMOIND
It checks whether the communication with tRFC was successfully completed. If successfully
completed, the status of the IDoc is changed. This reprocess program can be used for outbound
IDOC with status codes from 03 to 12.
Report RSEOUT00
For reprocessing outbound IDOC with status 30
Report RBDAPP01
For reprocessing inbound IDOC with status 64
Report RBDAGAIN
It for reprocessing of incorrect outbound IDOC with statuses 02, 04, 05, 25 and 29
Report RBDAGAI2

It for reprocessing of IDOCs after ALE input error with statuses 56, 61, 63 and 65
Report RBDAGAIE
It for reprocessing of Edited IDOCs with status 32 and 69