ALE, EDI & IDocs Introducion & Difference: SAP Tutorial

What is EDI?

EDI, stands for Electronic Data Interchange, is the electronic exchange of structured business data between different applications. A purchase order raised in one company can therefore arrive in a supplier’s system as a sales order, without anyone re-keying it.

EDI Architecture

As the diagram above shows, EDI Architecture consists of three layers –

1. EDI-enabled applications: They support the automatic processing of business transactions.
2. The IDoc interface: This was designed as an open interface. The IDoc interface consists of IDoc types and function modules that form the interface to the application.
3. The EDI subsystem: This converts the IDoc types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP.

Advantages of EDI process

• Reduced data entry errors
• Reduced processing cycle time
• Availability of data in electronic form
• Reduced paper work
• Reduced cost
• Reduced inventories and better planning
• Standard means of communicating
• Better business processes
• Competitive advantage

What is ALE?

EDI reaches outward to trading partners. ALE solves the mirror problem inside the enterprise, where several SAP systems must stay in step.

ALE supports the distribution of the business functions and process across loosely coupled SAP R/3 systems (different versions of SAP R/3). Connections from R/2 and non SAP systems is also supported.

ALE supports-

• Distribution of applications between different releases of R/3 Systems
• Continued data exchange after a release upgrade without requiring special maintenance
• Customer-specific extensions.
• Communication interfaces that allow connections to non-SAP systems.
• Coupling of R/3 and R/2 Systems.

What is IDOC?

Both ALE and EDI require data exchange, and both hand that job to the same object.

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 the 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 the one with greater length. IDOCs are independent of the direction of data exchange, for example ORDERS01 in the Purchasing module is used both inbound and outbound. IDOCs can be viewed in a text editor because 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).

IDoc Structure: Control, Data and Status Records

Knowing that an IDoc is a container is only useful once you can read what is inside it. Every IDoc, regardless of message type, is built from three record types.

Status numbers also tell you the direction at a glance. Codes in the 01 to 49 range belong to outbound IDocs, where 03 means “passed to port” and 12 means “dispatched”. Codes from 50 upward belong to inbound IDocs, where 53 means “application document posted” and 51 means “application document not posted”.

How does the ALE and IDoc process work?

The records above move through a fixed sequence of steps. Understanding that sequence is what allows you to find where a failed interface stopped.

Outbound process

1. Application document is created. A user or a batch job saves a business document, such as a purchase order.
2. Message control is triggered. The output determination finds a message type, for example ORDERS, and a partner profile that says an IDoc should be produced.
3. The IDoc is generated. A selection function module reads the application tables and fills the control and data records. The IDoc receives status 30, “ready for dispatch”.
4. The IDoc is passed to the port. The port definition decides the medium, which may be a file, a remote function call, or an XML transfer. Status becomes 03.
5. The subsystem or partner receives it. For EDI, the subsystem converts the IDoc into an EDIFACT or ANSI X12 message. A successful transmission returns status 16.

Inbound process

1. The IDoc arrives through the port and is written to the database with status 50.
2. The partner profile is checked. SAP looks up the sender, the message type and the assigned process code.
3. The process code calls a function module, which validates the segments against the basic type.
4. The application document is posted. Success gives status 53. A failure gives status 51, and the IDoc stays in the database with the error message attached.
5. Failed IDocs are reprocessed after the master data is corrected, without the partner needing to resend anything.

Because the IDoc is stored at every stage, no data is lost when a step fails. That durability is the main reason SAP integrations still rely on IDocs decades after their introduction.

Difference between ALE and EDI

With all three concepts defined, the distinction becomes easy to state.

ALE is used to support distributed yet integrated processes across several SAP systems whereas EDI is used for the exchange of business documents between the systems of business partners (which could be non-SAP systems).

ALE is SAP’s technology for supporting a distributed environment whereas EDI is a process used for exchange of business documents which now have been given a standard format.

An IDoc is a data container which is used for data exchange by both EDI and ALE processes. That shared container is why the two technologies are almost always studied together.

Common IDoc Transaction Codes in SAP

Day-to-day work with ALE and EDI happens through a small set of transaction codes. The table below groups them by the task they serve.

A practical troubleshooting habit is to start at WE02 to read the status, then use BD87 to reprocess once the root cause is fixed.

FAQs