Idoc

1. ➢ Basics of iDocs and Overview
➢ Customization and configuration steps
➢ Partner profile maintenance
➢ iDoc Structure and Recorders
➢ Sending and receiving iDoc
➢ Documentation for iDoc type
➢ Common iDoc messages
➢ ALE
➢ EDI
➢ Configuration

2. iDoc are used in most SAP application for transfer of message (information ) from SAP to other
system or vice versa. Lot of documentation is available in iDoc they have technically different in
nature. For a functional consultant it is necessary to aware about concept of iDoc in order to
handle project/ support issues on iDocs. It is also known as Intermediate document.
Overview
iDoc is an SAP object that carries data of a business transactions from one system to another
system in the form of electronic message. The purpose of it transfer data information from SAP
to other system or vice versa. iDoc is an acronym intermediate document. The transform of data
from SAP to non-SAP system is perform via EDI (Electric Data Interchange) subsystems, ALE
(ApplicationLink Enabling) is a mechanism for the exchange business data between loosely-
coupled T/3 application built by customers of SAP ERP program. Each Idoc number is unique to
the client. Denoted by binary system.
iDoc can be triggered in SAP system or in EDI subsystem, This depend upon direction in which
iDoc is sent and is called INBOUND or OUTBOUND iDoc accordingly.
INBOUND FLOW : EDI coverts the partner data and iDoc is created in SAP. After successful
processing of iDoc, Application Document is posted in SAP.
OUTBOUND FLOW : iDocis triggered in SAP through message control which is then send to EDI
subsystem. EDI converts the data into XML or equivalent format and then sent data to partner
system through internet.

3. Information flow OUTBOUND
Information flow INBOUND
Application iDoc EDI subsystem Partner

4. “EDI” is electronic exchangeof business document
between the computer system of business partners,
using a standard format over a communication
network.
For transmission of information electronically
standards are as follows
• ANSI ASC X12
• EDIFACT ANSI ASC X12
A committee formed by representativeof major
organizations and EDI software companies which
define standards and guidelines for information
interchange over EDI.UN/EDIFACT stands for United
Nations EDI for Administration, commerce and
Transport and was founded in 1985 using ANSI X12
and UNTDI (United Nation Trade Data Exchange) as
base standards ANSI X12 describes business
document as transactions and each transactions is
represented by three digit number for example 850 –
Purchase Order, 855 – Purchase Order
Acknowledgement.
EDIFACT describes business document as message,
represented by standard name for example ORDERS
for purchase order.

5. IDOC (BASIC) TYPE
iDoc types are based on the EDI
standard and on EDIFACT
standards.
Basic types defines the structure of
an iDoc. Each iDoc type describes
standard iDoc segments, format of
data fields and their size. Basic type
also defines numbers of segments
and fields in an iDoc. All the field is
necessary for transmission of
message for a particular business
transaction are mapped in different
segment. It is also defines the
structure and relationship of iDoc
segments along with optional and
mandatory segments.

6. IDOC Segments :
iDoc segments contain actual data that is sent to or received from a partner. These segments
Contains the actual values that are sent as part iDoc transmission.
Parent and Child Segments :
iDoc segment is termed as parent segment if it contains its own segments. These dependent
segments are called as child segments.

8. INBOUND/: OUTBOUND iDocs :
iDoc sent outside the system are termed as Outbound iDocs and the ones are received into the
system, are called Inbound iDocs.
iDoc Direction :
This signifies the direction is which information is sent and is similar to terminology used in
mails. If information is sent outside the system then the direction is outbox when it is received
into the system then direction is inbox. In SAP Outbox direction is represent by “1” there fore
Outbox and Inbox direction is represented by “2”.

9. Partner :
Partner is the Business partner with which the exchangeof information is to takes place using
iDoc. It can be vendor or customer or any other system, Depending on the direction of
information in which the information is sent it plays a role of either a “sending partner” or a
“receiving partner”.
Partner Type :
Partner Type Description
KU Customer
LI Vendor
LS Logical System

10. Message Type :
iDoc processing involves transmission or receipt document in the form of message, each of
which represents a document in SAP. These documents can be Order, Shipment Confirmation,
Advance Shipping Notification, Goods Receipt, or Invoice. Message type is associated with
Basic iDoc type (Basic Type) and defines the kind data or document that is exchanged with the
partner.
Process Code :
The process code contains the details of the function Module that are used for iDoc processing.
Message type can be linked to the process code.
Port :
iDoc Port contains the information about the way datais sent between the source or target
system. The type of port defines the information contained within the port. For port type “File” ,
directory or file name information is maintained. “tRFC “ port contains information about the
RFC destination of the target system. For iDoc transmission using ALE “tRFC” ports are used.

11. Message Type :
iDoc processing involves transmission or receipt document in the form of message, each of
which represents a document in SAP. These documents can be Order, Shipment Confirmation,
Advance Shipping Notification, Goods Receipt, or Invoice. Message type is associated with
Basic iDoc type (Basic Type) and defines the kind data or document that is exchanged with the
partner.
Process Code :
The process code contains the details of the function Module that are used for iDoc processing.
Message type can be linked to the process code.
Port :
iDoc Port contains the information about the way datais sent between the source or target
system. The type of port defines the information contained within the port. For port type “File” ,
directory or file name information is maintained. “tRFC “ port contains information about the
RFC destination of the target system. For iDoc transmission using ALE “tRFC” ports are used.

12. Partner Profile (WE20)
Partner profile must be maintained
in all the business partners to
whom we want to send or receive
the iDocs. The T-code: WE20
Double Click on the Partner
Partner profile contains parameters
for Inbound and Outbound
processing
Of iDocs. Foe each message type
we can maintain inbound/outbound
option,
message control, post processing
options and contact information
within
Inbound and Outbound parameters.
Outbound Parameters
This involves sender/receiver port,
Output mode and relation to iDoc
type i.e. Basic type and extension.

13. Message Control (Outbound Parameters)
This contains application for which iDoc will be created for example EF for purchase order, the
message type of the application that will trigger the iDoc and process code that will convert SAP
document to an iDoc. For example if a Purchase Schedule agreement is to be sent to the vendor
1000 then in the outbound option of the partner 1000 we need to maintain the message type
DELINS and link it to process code ME14. When message type DELINS is triggered the PO then
iDoc will be created for the partner vendor 1000.

14. Inbound Option (Inbound Parameters)
In Inbound options process code is
maintained in the Inbound screen only.
iDoc processing can be triggered by
background program and triggered
immediately.

15. Post Processing (Inbound/Outbound
Parameters)
In the post processing option we can
maintain the workflow details of the
users or positions to which an error
notification will be sent if an iDoc
processing fails.
Telephony (Inbound/Outbound
Parameters)
We can also maintain the contact
details in Telephony Option.
EDI Standard (Outbound Parameters)
EDI standard screens contains the
details of standard EDI terminology
used for iDoc transmission.

16. Idocs structure are of following
types:
▪ Control Records
▪ Data Records
▪ Status Records
These records are stored in the
transparent tables in SAP. These
are.
EDIDC, EDID4, EDIDS.
Control Records (EDIDC)
It contains information such as
Idoc number, direction, idoc status,
Basic Type, Message Type, Partner
(Sender/Receiver), date and time of
creation/update, Interchange File or
ISA number etc.

18. Data Records (EDID4)
It contains the details of the idoc
segments.
Idoc segement has fields that
contain data necessary for posting
the documents.

19. Status Records (EDIDS)
Idocs Status defines the processing
status of the idoc and its various
processing states, Status Number
represents the idoc status. Current
status of the idoc is present in
Control record.
Initial Statusnumbers are 64 for
Inbound and 03 for Outbound.
Successful status is 53 for inbound
and 16 for outbound idocs.

20. Triggering an Outbound Idoc :
Outbound idocs can be triggered
from the output message types of
Purchase Orders, deliveries,
Material documents, invoices etc.
The following figure shows that
output ZXX1, of PO XXXXX 1is
processed an idoc 000000XXXXX1
is added/created.
The relationship between idoc and
Application document can be
found in two type:
1. Relationship tab of idoc
2. Relationship of Application
document e.g. PO, SO, Material
Document, etc.

21. The initial status of the idoc will be 30 which after
successful processing will be convert into status
16. The different validation steps are:
01: IDoc generation successful
30: IDoc is ready to be processed by IDoc
Processing job
03: IDoc data is passed to the Port
18: IDoc successfully triggered EDI subsystem
06: IDoc data translated to EDI format
12: IDoc is dispatched successfully to the partner
16: Partner has received the IDoc successfully
IDoc can possibly fail at any of the above steps
during validation.
Receiving an Inbound Idoc
The initial status of an inbound IDoc is 64 and
successful status is 53.
Different validation steps for inbound IDocs are
explained below:
50: IDoc received successfully in the system
64: IDoc is ready to be processed by IDoc
processing job
53: Application document created and saved
successfully. The document number can be found
by expanding the status node 53.
An Inbound Idocs goes though all the above
statuses (50-64-53)

22. Automatic/Immediate Processing :
In this case Idoc are processed
immediatelyas they generated or added
in the system. The check “Transfer Idoc
immediately” is selected in Outbound
Options and “Trigger Immediately” is
selected in Inbound Option. These checks
are generally used when the real time
information exchange is necessary
between two systems.
Manual Processing :
Idocs can also be manually processed the
T-Code : BD87
Processing Via Background Job :
.
Idoc processing by background is most
preferred way to processing the Idocs.
Following Programs are used from
processing the Idocs using background
job:

23. Reprocessing of Idocs :
On the basis of Idocs statuses different programs can be used for reprocessing of failed Idocs.

24. If an Idocs contains error in the data then such Idocs can be edited using T-code : WE02 or
WE05. When and Idoc is edited the original Idoc information (backup) is saved in a New Idoc
under status 70 (for Inbound)/ 33 (For Outbound), These Idoc stays in the system for reference
only and cannot be processed. The status of the edited Idoc become 69 (Inbound) and 32
(Outbound). These Idocs can be processed using BD87 transaction or batch jobs. Can be done
Debugging of Idocs can be done using by copying the Idocs using T-Code WE19. WE19 is a test
tool for Idoc processing. W19 copies the existing idoc and creates new Idoc which can then be
modified as per testing needs. The newly generated Idoc can also processed using BD87.

25. Report RC1_IDOC_SET_STATUS can be used to change the status of Idoc. Status change s are
generally needed to move an Idoc to status 68 – no further processing.

26. Idoc can be displayed in system via T-code: WE02 and WE05. If Idoc number is not known then
search can be made on the bases of Idoc date, Direction, BASIC TYPE, MESSAGE TYPE, and
PARTNER NUMBER. Partner number can be found in the Output message of the documents.

27. Idoc search can also be made on the bases of ISA or Transfer file

28. T-Code : WE09 If we are looking for specific information within the Idocs segments then this
can be found. This is useful if you are searching for a particular information in similar kind of
Idoc within Idoc segments. For example if you want to search a particular purchase order
number for example100000001 in multipleIdocs which lies in segments E1EDK01of an Idoc
under field BELNR. Then the search can be extended in the following manner.

29. The Idoc failure may not be related to any of the above mentioned reasons, the best way to
fiend the Idoc error is to compare the existing Idoc with the good example. Good example Idoc
can be easily searched with any of the Idoc search methods as describes below.

30. Idoc documentation can be found using T-Code WE60 and can be helpful to obtain information
of the Idoc Type or its particular segment. It also provides information such as mandatory and
optional segments, minimum and maximum number of segments etc.

31. The following list gives the Basic Type and Message Type combination for common Idocs.

32. As Idocs grow older they are archived and deleted from the database. Archive Idocs can be
viewed using T-Code SARI in Achieve Explorer using archiving object as Idoc. Following are the
few program that are used for archiving and deletion of Idoc from database.

33. We should always try to reuse Idocs Message Types
provided with standard SAP content, there could be
scenarios where you need to create completely new
Message Type and iDoc type with in your own custom
processing logic.
Overview of Steps to Create Custom IDocs Types.
1. RegisterLogical System– BD54 or Sale
2. Create custom iDocs – WE31
3. Define idoc – WE30
• Create iDoc type
• Assign segments to iDoc
• Configure segment properties
WE30 → Set release the segment
WE31→ Set iDocs release

34. 4. Create custom message type – WE81
5. Assign iDoc Basic type to Message type
– WE82
6. Create Function Group- SE82
7. Develop iDoc processing Function
Module – se37
▪ Define iDoc processing Function
Module
▪ Code iDoc data processing ABAP
logic
8. Assign FM to Message Type/Basic Type
combination – we57
9. Configure characteristics of
processing FM – bd51
10. Configure custom inbound Process
Code – we42
▪ Create inbound Process Code
▪ Assign processing FM to Process
Code
▪ Assign iDoc Message Type to
inbound Process Code
11. Setup Partner Profile – we20
▪ Create Partner Profile
▪ Configure inbound parameters of
the Partner Profile

35. ALE is a tool which can help to transfer the data from one SAP system to another SAP system. It
also transfer data from SAP to Non-SAP system. To transfer data from SAP to Non-SAP system
use translator that are → TIBCO / XI
Translator find out the language sender to receiver.
We need transfer of data ?
• A Client having operations in multiple countries and wants a central location where the data is
stored.
• If a customer is using SAP then we need the data transfer from his system to our system.
for example if a customer send us the Purchase Order to us through Idoc, then we can use that
and create a Sales Order .
SAP is an integration of many third party system and also SAP systems. It means ECC R/3
system can be communicate with GTS server or TM server.
Data transfer can be happen between all these system.
Advantages of ALE :
• It will save the time off the end user.
• It will minimize the paper work.
• It will minimize the manual errors.
Idoc is an Intermediatedocument which contain the data. It is a data container which carry the
data from one source system to the target system.

36. • That might be from SAP system to Non-SAP system.
• Each Idocs having a unique number with this number we can track whether this Idoc
successfully sent or not.
Idoc Structure : Itscontains three type of records
▪ Control Record : Headerdatawhat is send and to whom is send?
▪ Data Record : Whetherit is Inbound or Outbound, the fields in which datarecord
▪ Status Record : tellsabout it is successful or not and where it is got save.
As a functional consultants we need to go display idocs structure>
T-Code: WE02 – Display the Idoc structure
SAP Non-SOP
iDoc

37. EDI is a tool that helps to transfer the data from SAP to Non-SAP or Non-SAP to SAP. We use EDI
if the customer is using industry specific documents. Industry specific docs are ANSI format. If
we use EDI as a tool to transfer the data we require translators.
Standard messagetypes from which data is sent from one system to another system:
Material Master ====➔ MATMAS
Customer Master ==➔ DEBMAS
Vendor Master ====➔ CREMAS
Order ===➔ ORDERS
Delivery ===➔ DESADV
Invoice ===➔ INVOIC
T- Code : WE02/ WE05/WE07/WE09 – To display Idocs
T- Code : BD10 to send Material Master from sender to receiver.
T- Code : BD12 to send Customer Master from sender to receiver.
T- Code : BD14 to send Vendor Master from sender to receiver.
For Outbound Messages Number Range is → 0 to 49
For Inbound Messages Number Range is → 50 and above
Success message number in Outbound is → 03
Success message number in Inbound is → 53
Failure message in Inbound is → 51
T- Code : BD87 – to reprocess the data with the same Idoc no.
T- Code : WE19 – to reprocess the data with different Idoc no.

38. S.N0 Job Sender System Receiver System
1 Prerequisite The pass word and the ID should
be able to access for both the
client with in the IDES System.
The pass word and the ID
should be able to access for
both the client with in the IDES
System.
2 Client 800 810
3 Define Logical
System T-code SALE
Basic Setting➔Logical
System➔ Define Logical
System→ RLS800 - Sender LS
RLR810 –Receiver LS
As this is cross client no need
to create in client 810
4 Assign Logical
System to Client T-
Code : SALE
Basic Setting➔Logical
System➔ Assign Logical
System→ Select Client 800 →
Enter LS RLS800 - Sender LS
and save
Basic Setting➔Logical
System➔ Assign Logical
System→ Select client 810 –
Enter LS RLR810 - Receiver LS
and save
5 Maintain RFC
destination
T-Code: SM59
Execute
Then create a RFC destination in
sender system create the RFC
for the Receiver Logical System
RRL 810, all the basic
connection need to setup
Job 1,
Then create a RFC destination
in sender system create the
RFC for the Receiver Logical
System RLS 800, all the basic
connection need to setup
Job 1 to 5 is done by Bases Consultant

41. S.N0 Job Sender System Receiver System
Job of Functional Consultant
6 Create a PORT
T-Code: WE21
Execute Click on Transaction
RFC click on create Select radio
button Own Port Name R800-810
click on radio button doc record
types in SAP release 4x , enter
click on save
Creation of port not required in
receiver system
7 Maintain distribution
Model T-Code: BD64
Click on change mode, click on
model view, then create model
view, Enter Name RMaterial
Technical – R800-810 and save
Scroll down select created
model click on add message
Type MATMAS , SYNC
Then view again highlight the
Distribution model go to
environment→ click on generate
partner profile→ Execute then
again click on edit→ Click on
model view→ Distribute
Not need to create it is
distributed automatically.
8 Generate Partner
Profile T-Code WE20
Click on Partner Tab Logical
System Extend select Receiver
Logical System RLR810 double
click on it display all details in
Outbound Parameters, Double
click on MATMAS
Generate Partner Profile In
client 810 select partner type
LS click on create enter the
details Partner no RLS800,
Type User, Agent User name
save click on save.

42. S.N0 Job Sender System Receiver System
Job of Functional Consultant
8 Create Partner
Profile
Click on insert icon in Inbound
Parameters, Enter RLS800
Message Type MATMAS,
Partner Process code MATM,
click on save.
9 Create Material in
Client 800
10 Send the Material
using T-Code : BD10
11 To check the Idoc T-
code : WE02
Idoc is successful
created and
distributed.
Check the material in client 810