AN INTRODUCTION TO EDI, ALE AND IDOCS ObjectivesGet introduced to the basic concepts of EDI

Learn about ALE technology

Understand about IDOCs

Inbound processing

Outbound processing

Filtering and Conditions

Prepared by: Ajith Jesuwaram

The Basics of EDI

Electronic Data Interchange The exchange of business related documents between the systems

of business partners Also called as paperless exchange It is sent over a communication network It has a standard format

Benefits of using EDI Process

Reduction of errors in data entry Reduction in the Processing cycle time Data available in electronic form Reduction of paper work Less cost Lesser Inventories and a much better planning Communication by Standard Means Much better Business Processes

SAP EDI Architecture

SAPEDI sub-

systemIDOC

Status

EDImessag

e

IDOC

SAP EDI

EDI sub-system

Non-SAP ERP system

EDImessag

e

Application

messages

VAN

Outbound Process

Inbound Process

Basic Concepts of ALE

Basics of ALE ALE architecture Benefits of all ALE Process Difference between EDI & ALE

What is ALE? Application Linking and Enabling SAP’s own technology To support distributed yet integrated processes Based on application-to-application integration Has IDOCs as the data containers

ALE Architecture

Outbound process (from SAP to another SAP or non-SAP system)

Inbound process (from one SAP or non-SAP to a SAP system)

Outbound Process

Inbound Process

ALE versus EDI

ALE EDI

Data transfer between SAP systems.Data transfer between any two systems.

Used for internal communication Used for external communication

To distribute the master data. To exchange transaction data.

Data transfer using memory buffers. Data transfer using file ports.

Translator not required. Translator always required.

No sub-system. Sub-system present.

Used between SAP and systems within the company.

Used between SAP and the customers/vendors.

What is an IDOC?

Intermediate Document A Container used to exchange Data / Information between

two processes which are capable of understanding the syntax & semantics of the data.

It is of 2 types – Inbound IDOC & Outbound IDOC Created when we execute an outbound ALE or EDI Process In Inbound ALE or EDI process, an IDOC acts as input for creating

an Application Document. In SAP Systems, IDOCs are stored in the database. Every IDOC has an unique number (within a client). IDOCs are independent of the sending system & the receiving

system. Data is stored in the character format and not in binary format.

IDOC Structure

The IDOC structure consists of 3 parts

• Administration part - has the type of IDOC, message type, the current status, the sender, receiver etc. This is referred to as the Control record.

• Application data - contains the data. These are called the data records/segments.

• Status information - contains information about the various stages the IDOC has passed through.

IDOC Structure

Control record

Data record

Status record

Basic IDOC Type (WE30)

Basic IDOC Type

This defines the format and structure of the business document that is set to be exchanged.

IDOC Type has a specific name list of permitted segments hierarchy of segments mandatory/optional segments minimum/maximum range of each segment.

Basic IDOC Type (WE30)

Screenshot of WE30 transaction

IDOC Components (WE31)

Segments The segment defines the format & the structure of a data record.

Contains the fields which represent the data.

Can be reused across different IDOC types.

For each segment SAP creates Segment Type (version independent) Segment Definition (version dependent) Segment Documentation

The last 3 characters are the version of the segment

As per the version the definitions keep changing but the segment type remains the same

IDOC Segment - PIC

Screenshot of WE31 transaction

IDOC Run-Time Components

An IDOC is an instance of an IDOC Type (standard/ customized)

Events that occur at run time are as follows; A unique IDOC number is allocated by SAP One control record is attached to the IDOC Segments translate into data records Status records are attached Syntax rules are checked.

Each IDOC has 3 parts• The Control Record• The Data Record• The Status Record

We02 or We05 is used to display an IDOC.

IDOC Run-Time Components (contd.)

Screenshot of WE02/ WE05 transaction

IDOC Runtime components (Contd)

Control Record Contains the control information Has the same structure across IDOCs First record in any IDIC only 1 control record exists for any IDOC Stored in EDIDC table. We61 – documentation of the control record

Data Record This Contains application data. Stored in EDID4 tables. Actual data is stored in the form of a string in a field called SDATA

(1000 character length) Contains 2 sections

Administrative section Data section

Multiple data records can exist in an idoc

IDOC Runtime components (Contd)

Status Record • Displays the status of an IDOC• Gets attached to the IDOCs at every milestone / processing or

when it encounter errors.• Stored in EDIDS table.• Multiple status records can exist for any idoc• Statuses 1-49 for outbound, above 50 for inbound• We47 – list of status codes

Syntax Rules for an IDOC• Only valid segments as defined in the IDOC type are allowed• Mandatory segments must exist.• Data records have a limit defined for the number of repetitions• Must have the same physical sequence as in IDOC structure• Child segment cannot exist without parent.

Extending an Existing IDOC Type

Used when additional information is required in addition to what is supplied by the Standard IDOC Type.

The addition of custom segments.

Create the IDOC type as an Extension in transaction WE30.

Specify the basic type for which it will be an extension.

None of the SAP Standard segments can be deleted or changed.

Add custom segments as children to existing ones (transaction WE31).

Only new data fields have to be added to the custom segment.

WE30 Screenshot for an extended IDOC

THANK YOU