SAP SD SUPORTE: You’hv got an IDoc !!

If you google IDoc, you would be flooded with thousands of pages. In this post, I have tried to compile only those part which are practically used in real time projects.

Sections for this page:
1. Difference between ALE and EDI ?
2. Definition and Components of IDoc.
3. IDoc types.
4. Basic steps to performed
5. Where the Idoc information is saved?
6. How to re-process the IDoc?
7. IDoc monitoring T-Codes
8. How to change the status of IDoc manually?
9. Statuses – OK/Warning/Error/Harmless?

[adToAppearHere]

1. What is difference between ALE and EDI ?
One SAP system (eg ECC) to another SAP system (eg SAP CRM/SRM/APO) = ALE (Application Link Enabling)
SAP system to Non-SAP system (external third party system) = EDI (Electronic Data Interchange)

Updated 29th July 2019

We have over simplified the terms ALE and EDI which might confuse many. Our friends at LinkedIn provided better explanation to ALE and EDI.

ALE is not only for SAP to SAP.

EDI is not only for SAP to non-SAP.

Please read the below two paragraphs for better clarity.

Sitakant Tripathy

2 different trading partners both with SAP instances can still choose to do EDI to comply with EDIFACT and keep consistencies in sharing of business documents across multiple partners. Completely dependent on enterprise data distribution and industry compliance strategy.

Gurunathan Nandhi

ALE(Application Link Enabling) generally will be used in Application-to-Application (A2A) scenarios.

Target application can be SAP, Non-SAP and homegrown applications.
ALE need NOT adhere to any International Standard protocols/format such as EDI ANSI X11/X12, EDIFACT, and CIDX….
The exchanged data need NOT be System of Records either source or target systems.

EDI(Electronic Data Interchange) generally will be used in Business to Business (B2B) scenarios.
Business Partners: Vendors, Customers, Banks,…
Most of EDI cases where data need to adhere to International Standard protocols (EDI ANSI X12, EIDFACT…).
Assumptions: The exchanged data can be System of Records at either source or target systems or both.

End of Update – 07/29/2019

2. Definition and Components of IDoc:

An IDoc stands for ‘intermediate document’; it is a container for exchanging data between R/3, R/2 and non-SAP systems.

An Idoc type specifies the structure of the data.

A message type specifies the meaning of the data.

An IDoc type must be assigned to a Message type so that the data in the IDoc is processed correctly.

Note: An IDoc contains only character fields.

PORT (WE21): Port, in the outbound process, determine the name of the EDI subsystem program, the directory path where the IDOC file will be created at the operating system level, the IDoc file names and the RFC destinations.RFC Destination (SM59): Used to define the characteristics of communication links to a remote system on which a functions needs to be executed.Partner Profile (WE20): Partner profile specifies the various components used in a process (Partner number, IDoc type, message type, Port, Process code), the mode in which it communicates with the subsystem (batch or immediate) and the person to be notified in case of errors.Message Control (NACE): Used in pricing, account determination, material determination, output determination etc. The message control component enables you to encapsulate business rules without having to write ABAP programs.

3. IDoc Types:

Based on IDoc Status
01 – 49 for Outbound Process
50 – 75 for Inbound Process

Based on direction of data flow

4. Basic steps to performed:

On both sides
1. Define & Assign Logical System SALE (BD54)
2. Setup RFC destinations SM59
3. Port Destinations WE21
4. Partner Profile WE20

In Source system: In Destination System:

1. Segment Creation WE31 1. First five steps in Source system
2. Basic Idoc Type Creation WE30 6. Creating/Leverage FM SE37
3. Message Type WE81 7. Assign FM to Logical Message WE57
4. Assign Msg Type to Basic WE82 8. Define i/p method for Inbound FM BD51
5. Distribution Model BD64 9. Create Process Code WE42
6. Message control NACE (optional)
7. Programs

Note: Points to remember in Partner Profile Configuration

Trigger Immediately should be avoided.

To process the collected (Outbound) or background triggered IDoc (Inbound), these two batch Jobs needs to be scheduled at regular interval: RSEOUT00 and RBDAPP01 respectively

5. Where the Idoc information is saved?

Tables Description
EDIDC Stores the Control Record information an IDOC
EDID4 Stores the Data Records
EDIDD Data Seg (EDI Intermediate doc)
EDIDS Stores the Status of an IDOC
EDP13 Partner Profile: Outbound (technical parameters)
EDP21 Partner Profile: Inbound

6. How to re-process the IDoc?

Programs Description

RBDMANI2 Reprocess Idocs manually
RBDMANIN Posting of IDocs with Status 51
RBDMOIND Outbound Idocs status 03->12
RSEOUT00 For Processing 30 Status IDocs
RBDAPP01 For Processing 64 Status IDocs
RBDAGAIN Reprocess Incorrect Outbound IDocs
RBDAGAI2 Reprocessing of IDocs after ALE Input Error

Note: Cannot remember the programs names !!!!

Just remember one program name for Inbound Idocs i.e. RBDINPUT.. easy.. huh!!!!
RBDINPUT : A menu with the different statuses possible for inbound IDocs

7. IDoc monitoring T-Codes
Area Menu for Idocs    WEDI
Area Menu for Idoc    SALE
List Of All IDocs Created. (Default, Additional, EDI) WE02
Selection Program For Issuing Output WE15
Process All Selected IDocs WE14
Test Tool For Idoc Processing WE19
Select IDocs BD87
Idoc Search For Business Contents (Database) WE09
All process codes (inbound/outbound) WE64
IDoc documentation    WE60

8. How to change the status of IDoc manually?
Use SAP standard program RC1_IDOC_SET_STATUS. Please use judiciously!!