Introduction to IDOCs

Vimal Balaji
IDocs Training
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
What is an IDOC?

• IDOC = Intermediate Document

• IDOC is simply a data container used to exchange
information between any two processes that can
understand the syntax and semantics of the data.
• 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 an unique number(within a client).
What is an IDOC? (contd)

• IDOCs are independent of the sending and receiving

systems.(SAP-to-SAP as well as Non-SAP)
• 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 tored in
character format instead of binary format.
Agenda

• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
IDOC Structure

Taken from SAP Help

Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
IDOC Type Documentation

• Each IDOC in the system is thoroughly documented (we60)

IDOC Components :

Basic IDOC Type (we30)

• Basic IDOC Type defines the structure and format of the business
document that is 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.
Display Basic type & Segments
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
IDOC Components :

Segments
• Segment defines the format and structure of a data record.
Segments are reusable components.
• For each segment SAP creates
– Segment Type (version independent)
– Segment Definition (version dependent)
– Segment Documentation
• The last 3 characters is the version of the segment
• Definitions keep changing as per the version but the segment
type remains the same
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
IDOC Run-Time Components

• An IDOC is an instance of an IDOC Type

• At run time the following events occur
– A unique IDOC no. 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
– Control Record
– Data Record
– Status Record
• We02 or We05
WE02 / WE05
IDOC Runtime components (Contd)

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, sender, recipient information,
channel it is using, which port it is using etc.
Data Record
• Data record contains application data like employee header info,
weekly details, client details etc
• All data record data is stored in EDI_DD40 table and EDI_DD
Status Record
• Status record are attached to an IDOC at every milestone or when it
encounter errors.
• All status record data is stored in EDID8 table.
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Where and How an IDOC is created?

• Lets take an example to understand this:

• Whenever a Purchase Order (PO) is created we want to send the IDOC
to a vendor.
• The PO is sent in the form of an IDOC to the vendor (partner). That
partner has to be EDI enabled in that system.. SAP should realize that
it could send doc to this vendor electronically. (Creating a vendor is not
sufficient). Partner Profile should be EDI enabledi.e. A partner profile
should exist in the sap system.
• Quotation, RFQ, PO, SO, Invoice, delivery challan etc are some of the
commonly exchanged documents through IDOCs
• We create only one profile for both inbound and outbound IDOCs.
•  Partner profile should contain message type……to be able to
exchange the IDOC.
• We define partner type, partner function and message type (it
distinguish if an IDOC is being sent to same person in same function for
different reason e.g. SO)
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Creating Outbound Process Code (WE41)

• What is Process Code ?

Process of filling the IDOC with application data is done by Function
Module. But, function module is not assigned to a Partner. It is
encapsulated by a Process Code and this Process Code is assigned to
a Partner in Partner Profile.
• Assigning Function Module to Process Code
- Go to Transaction WE41.
- Switch to “Change” Mode and click “New Entries”.
- Enter Process Code Name and assign the Function Module created.

Process Code

Function Module
Partner
Snapshot of WE41
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Creating Partner Profile (WE20)

• What is Partner Profile ?

We must maintain the business partners with whom we communicate
via IDocs, in Partner Profiles.
• Steps to create Partner Profile
- Goto Transaction WE20.
- Click on Create Button.
- Enter the Number of Vendor Created in Partner No. and ‘LI’ in Partner
Type fields.
- Save the Data.
- For Outbound Partner Profile we have to create Outbound
Parameters
- Specify Partner Function, Message type created, Port (create a port in
WE21),Basic Type and Output Mode.
- Goto “Message Control” Tab and link the Message Type and Process
Code created.
- Save.
Snapshots of WE20
Change Application Data to be Transmitted

• Change Purchase Order Created using transaction ME22n for the

Vendor to which partner profile has been created.
• Goto “Messages” , add the new “Message Type” to the list and Save
the Purchase Order.
• An IDOC will be created for the purchase order and will be dispatched
to PORT mentioned.

Check the status of IDOC (WE02)

• The IDOC status can checked using transaction WE02

• If the status is ’03’ , it implies that IDOC is passed to Port.
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Summary: IDOC Workflow

The sequence:
1. Checks whether Partner profile exists or not
2. Whether that PP has a outbound parameter
3. Whether NEU message type is there or not (message control)
4. Checks the process code (gives the name of Function module)
5. Checks immediate transfer or batch transfer
6. Based on that it checks the receiver port
7. Then it will trigger the RFC destination
8. Then it triggers the event on subsystem/customer system
9. Transfer the IDOC to a port and transfer the Idoc in terms of file and it
triggers the customer system
10. Customer knows from where it should pick up the file ….it picks up the
file.
we82
we21
ALE Intro
Extending an Existing IDOC Type

• Used in cases where some additional information is required in addition

to that supplied by the Standard IDOC Type.
• In Transaction WE30 we create the IDOC as an Extension and specify
the basic type for which it is an extension.
• We add the segments needed as children to existing ones.
• None of the Reference Segments can be deleted or changed.
Basic Type(ORDERS01)
F1
Cannot be modified
F2

F3
Extension Child Segs
F4

F5
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Inbound v/s Outbound processing -- Similarities

• The basic Idoc type

• Partner profile
• Message type
• Idoc type – Message type association
• Defining Inbound function module
• Process code
Inbound v/s Outbound processing -- Differences

• Partner profile – is maintained for inbound parameters

• Idoc type - Message type association – has fewer details
Steps

• Creation of basic Idoc type (Transaction we30)

• Creating message type (Transaction we81)
• Associating the Message type to basic Idoc type (Transaction we82)
• Creation of partner (Transaction xd01)
• Associating the partners (Transaction voe2)
• Creation of partner profile (Transaction we20)
• Defining process code (Transaction we42)
• Maintain an entry for the material in customer-material info records
(Transaction vd51)
Creating a partner -- customer

• The customer is the receiver of the idoc in this scenario

– Transaction xd01
– Enter sales organization – 1000
– Sales division – 12
– Distribution Channel – 00
– Account group – ship-to-party
– Enter all required data -- sales area data and billing data
– Note the customer number
Associating the partners

• The customer and vendor need to be associated

• Goto transaction ve02
• Create a new entry
– Enter customer number
– Enter vendor number
– Enter sales area - 1000
– Enter sales division - 12
– Enter distribution channel - 00
– Enter standard order type - ZTA
Create a Inbound process code

• The inbound process code is the process that needs to be triggered in

order to post the idoc that is sent by the subsystem.
• The steps in developing a process code
– Develop a function module
– Define inbound characteristics of the function module – bd51
– Assign idoc type and message type – we57
– Define the process code – we42
Function module

• This function has a basic functionality of posting the document into its
respective format from the idoc
• It is basically a bdc
• The functionality is to
– Read control record and data records
– Fill bdc table, call transaction
– Change status record
Assign Idoc type – Message type (Transaction we57)

• Module name – function module developed

• Basic idoc type eg: orders01
• Message type eg:orders
• Object type – bus2032
Defining the process code – we42

• Enter the process code – any name

• Identification is the name of the function module
• Processing type is processiong by function module
Creating a partner profile -- Tcode we20

• Enter partner function – ship-to-party

• Message type – orders
• Process code – orde
• Note that no other details are needed unlike partner profile for outbound
process
Testing the inbound function module – we19

• The idoc created has to be posted

• Change the control record
• Post the idoc
– Use inbound function module or
– Standard inbound function module
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
 EDI

Contents
• Evolution and Need of EDI
• What is EDI ?
• EDI Architecture
• Advantages of EDI
• The Two Types of EDI Processes
- Outbound Process
- Inbound Process
Disadvantages of Conventional Business Documents Exchange

• Highly Inefficient & Laborious

• No proper Tracking Mechanism
• No visibility into the Process
• Long Lead Time
• Redundant Entry at various points
Evolution of EDI
Data Exchanged through Floppy Disk

Adoption of Standard Formats

ANSI Committee Formation

X.12 – 1975
•One-to-one correspondence between paper-based document and an EDI Message
•North America , New Zealand and Australia

UN/EDIFACT (United Nations EDI for Administration, Commerce and

Transport) 1985
•International Recognition
•Similar to ANSI X.12
•Business Documents become Messages
What is EDI ?

• EDI, stands for Electronic Data Interchange, is the electronic

exchange of structured business data between different applications.
The EDI architecture consists of

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.
EDI Architecture

MM SD
(Customer) (Vendor)

IDOC IDOC

EDI subsystem EDI subsystem

Communication
Advantages of the EDI Process

• Reduced data Entry Errors

• Reduced Processing cycle time
• Availability of data electronic form
• Reduced Paper Work
• Reduced Cost
• Reduced Inventories and Better Planning
• Standard Means of Communicating
• Better Business Processes
• Competitive Advantage
Outbound EDI Process
Database Data Flow
Repository Process Flow
EDI-Enabled
Application

Application
Selection Document VAN
Program Value added
Network
IDoc

Outbound
Trigger IDoc
Program File EDI EDI
Subsystem Document
Operating
System
Inbound EDI Process
Database Data Flow
Repository Process Flow
EDI-Enabled
Application

Application
Posting Document
Program

IDoc VAN
Value added
Network
Inbound
Trigger IDoc
Program File EDI
Subsystem EDI
Operating Document
System
Agenda
• What is an IDOC?
• IDOC Structure
• IDOC Type Documentation
• IDOC Components
– Basic IDOC Type
– Segments
• IDOC Run-Time Components
– Control Records
– Data Records
– Status Records
• Where and How an IDOC is created?
• Process Code
• Partner Profile
• Summary: IDOC Workflow
• Inbound processing of IDOC
• EDI
• ALE
Purpose And Implementation Considerations

PURPOSE
ALE supports the distribution of the business functions and process
across loosely coupled R/3 systems. Connections from R/2 and non
SAP systems is also supported.
IMPLEMENTATION CONSIDERATIONS
• Distributing business applications and at the same time ensuring data
consistency is practical because:
– The increasing globalization of markets has led to the physical division of
organizational units.
– Business processes are not restricted to one organization only and an increasing
number of customers and vendors are involved.
– The performance of an R/3 System can be improved by distributing the business
applications.
Features

• 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.

ALE has functions for controlling messages flows (Audit) and for
eliminating malfunctions.
Message Exchange Between Distributed Application
Steps Involved in the Configuration of ALE

• Setting up the Clients

• Defining Logical Systems for the Clients
• Defining the Communication Parameters
• Modeling the Distribution
• Generating Partner Profile in the Sending system
• Distributing the Distribution Model
• Generating Partner Profile in the Receiving system
• Creating Master Data
• Sending Master Data
Setting Up The Client

• First of all, you have to set up two clients to enable communication

between the logical systems. The two clients may be located in the
same R/3 System or in separate systems or servers.
• You can either use existing clients or you can create new clients by
making copies of existing ones.
• To set up a new client, from the SAP standard menu choose:
• Tools  Administration  Administration  Client administration 
Client maintenance
• But usually the creation of the clients is taken care of by the basis
administrators. So this step really is not the part of ALE Configuration,
but as an ALE Consultant one should know how to Create and maintain
the clients.
Defining Logical Systems

• To overcome any confusion, the communicating systems in a

distributed environment must have the unique ID. The name of the
logical system is used as the unique ID. This name is assigned
explicitly to one client in an R/3 System at a time.
• You can find the functions required for this in the R/3 Implementation
Guide under:
• Sale  Distribution (ALE)  Sending and Receiving Systems 
Logical Systems
• To define the logical systems in the distribution environment, choose
Define Logical System.
• Execute the function and enter a logical system (LOG. SYSTEM) and a
short text for each of your clients and save your settings.
Logical Systems Contd…

• If you are using two clients in different systems, make sure your
settings are the same in both systems. When using two clients in one
physical R/3 System, you only have to make the settings once, since
the entries are client-independent.
• Assign the respective logical system to both the clients. Choose Assign
Logical System to Client.
• Execute the function in both clients (Fig 1.1).
• To display the client maintenance screen (Fig 1.2), double-click on a
client.
• In the Logical system field, enter the logical system to be assigned to
the individual client and save your entry.
Logical Systems Contd…
Assigning Client To Logical System
Defining the Communication Parameters

• For the two logical systems to be able to communicate with one

another, they must know how to connect to each other. The RFC
(Remote Function Call) destination provides this information.
• In each of the two clients, you must assign the RFC destination for the
other logical system. In Customizing for ALE choose:
• Sending and Receiving Systems  Configure Systems in Network 
Define RFC Destination.
• Execute the function (Fig 1.3).
• Choose Create.
• Enter the RFC destination. Use the name of the logical system that is to
be the destination (use UPPERCASE letters only). Enter ‘3’ as the
Connection Type and give short description for RFC Destination.
RFC Destinations Contd…
RFC Destinations Contd…

• As logon parameters, enter the logon language (for example, EN ), the

logon client and the logon user (user ID with target system password).
• Once the RFC Destination is created, it is visible in one of the RFC
Destination Types Screen e.g. Choose R/3 Connections. It will display a
list of RFC Destinations. If you choose any one of them, then you have
to enter Target Host and the system number either for the Remote Log-
On or for Testing the current connection. Target Host is nothing but the
application server to which you intend to connect. This name can be
given either in the form of an IP address mode or just in the form of
application server name. You can see the list of application servers
using the transaction code SM51. The screen can be seen as following
(Fig 1.4).
RFC Destinations Contd…
Modeling The Distribution

• The systems involved in the communication, must know which

messages are getting transferred from where to where. This information
is stored in the distribution model. The distribution is based on the
distribution model and is directly controlled by distribution model.
• From the R/3 Implementation Guide screen, choose:
• Sale  Distribution (ALE)  Modeling and Implementing Business
Processes  Maintain Distribution Model
• Create the model view. Select Create model view. Enter the technical
name and a description for it.
• Define the sending and receiving systems and the message type.
Position the cursor on Technical name and select Add message type.
A dialog box appears. Enter the logical system name of the sender and
the receiver and the message type e.g. MATMAS. For your reference,
please see the screen shot Fig 1.5.
Modeling Distribution Contd…
Generating Partner Profiles for Sending System

• After creating the model view, go to Environment Menu and click

Generate Partner Profiles.
• According to the Technical name of the model view and without
changing any parameter execute the function and generate the partner
profile.
• For your reference, please see the screen shot Fig 1.6.
Generate Partner Profiles Contd…
Distributing the Distribution Model

• To generate the partner profiles in the receiving system, this system

must distribute all the messages in the respective distributed
environment. This is possible only when you transport your distribution
view to the receiving system. So we need to distribute the model
distribution view.
• To achieve this choose:
• Distribution (ALE)  Modeling and Implementing Business Processes
 Maintain Distribution Model  Edit  Model View  Distribute
• Actually after this step is successfully over, we get a message saying
that the corresponding Model View is successfully updated.  
Configuration In Receiving System

• The next step after this is, we have to generate the partner profile for
the receiving system. Which is very much similar to the procedure as
that of Generating the partner profile in the Sending system (The
Partner profile must be generated for inbound parameters) .
• Here technically, the configuration of ALE is over. Only the job left is to
create a material or a purchase order or a sales order or any entry for
that matter and send that particular entry to the receiving system
through the newly configured ALE Configuration Model.
Distribution of material

• Go to the respective master data transaction and then send the data in
this case BD10.
• Go to SE38 and run the program RBDMOIND for the status of the
IDOC which is generated to be changed to 12 i.e. Dispatch OK
• The IDOC with the status 53 have to posted in the target service.
Examples
Change Pointers

• The change pointer technique is based on the change document

technique which tracks changes made to the key document in SAP
,such as material master, customer master and sales order.
• Changes are recorded in the database tables
– CDHDR – Change document header table
– CDPOS – Change document detail information
– BDCP -- changes relevant to ALE
• The shared Master data (SMD) tool write change Pointers i.e. it consults ALE distribution model
to determine whether a receiver is interested in the object which is changed, then it is logged in
BDCP table.
– The ALE programs analyze change pointers and generate IDocs
• These programs are designed to ignore multiple changes and create only one IDocs
• The function module are invoked by a standard report, RBDMIDOC,selection screen allow you
to specify the message type.
Master Data Distribution through Change Pointers

Create or Change
Master data

Create change
Master
Document Data

Analyze ALE Distribution

Change Changes
Document Model

Change
Pointers

Program RBDMIDOC
•Analyze change Pointers
•Generate Idocs
•Update Status of Change Pointers

Outbound Ale Processing

Communication
To destination system
Souurce:Ale,EDI,&IDOC Idocs
technologies forSAP
Configuration

• Enable Change Pointers globally

– Transaction: BD61
• This option enables the change Pointers to process Globally
• Enable Change Pointer for Message type
– Transaction: BD50
• This potion activate the change pointer for specific message type i.e. if the message type
MATMAS is checked then only it can allow the master data distribution
• Specify fields for which change pointers are to be written
– Transaction: BD52
• Specify fields for the change of which the processing have to be triggered
Configuration – BD61
Configuration – BD50
Configuration – BD52

Change a field in the master data and then execute program RBDMOIND
To process the change pointers
Points Of Failure in the Outbound Process

• An error in the change pointer process

• An error in Ale/EDI interface Layer
• An error in the IDOC structure (syntax error, conversion problem and so on)
• An error in sending the IDoc to a remote SAP system

Syntax error in IDoc: status code 26

Outbound partner profile is missing: status code 29 (Error in ALE service)
Filtering

• Filtering at the IDoc level creates a communication IDoc in which an

object’s views are filtered out, based on the filters specified in the
distribution model.
• Business Scenario
• Filtering at IDoc level
– Master IDoc  consults Distribution model  checks filter objects values checked
in filter object and master IDoc  values mismatch data record dropped
• Filtering can be done at the receiving system
VIMAL BALAJI / KELLE