SAP IDOC

1. IDOCS Tcodes
: jayprakash Barik (JP), @: chikujp@gmail.com
Intermideate documentes
SAP to SAP : ALE(Application link emblening)
SAP to NON SAP : EDI (Electronic data interchange)
Direction :Inbound : 1
: Outbound : 2
Status : 1 to 50 : outbound
and 50 above : inbound
Sucess : 53 sucess for inbound idcoc
: 12 Sucess for outbound idoc
•
IDoc or Intermediate Document is a standard SAP document exchange format. IDocs allow
different application systems to be linked via a message-based interface. The IDoc interface
consists of the definition of a data structure (where the data structure is the IDoc) and a
processing logic for this data structure. There are three main aims behind the use of IDocs:
•
The structured exchange of business documents so that they can be processed automatically.
•
The various degrees of structural complexity as displayed by different application systems can
be reduced to a structure which is as simple as possible.
Example: The structure of an SAP application document and the structure of the corresponding
EDI message under the UN/EDIFACT standard.
•
IDocs allow for extensive exception handling before the data is posted to the application.
•
Electronic Data Interchange (EDI) was the first form of data transfer to use IDocs. In EDI
application scenarios, the processes, by definition, involve two partners: The sender and the
recipient of an EDI message. EDI is a bilateral, document-oriented form of data transfer
•
Application Link Enabling (ALE) enables integration of business processes that are developed
across several SAP systems or non-SAP systems. Thus, ALE is oriented to connect different
applications on different systems. System-wide ALE message flows are modelled in a so called
'distribution model'.
A typical scenario is the system data administration, where material master records have to be
distributed from one central to several satellite systems. Nowadays, pure EDI scenarios are
more and more executed on the basis of ALE technology, only that the system connection is
'just' bilateral.

2. •
In an SAP System the Application Link Enabling (ALE) is one of the core integration technologies.
It involves the exchange of hierarchical data documents known as Intermediate Documents
(IDOCs).
Idocs detals
There are 3 record ,will be found out from anyIDOC
1: Control recored 2: Data record 3: Status Record
Control record is a kind of “envelope” record that contains information about the IDOC like












IDOC type (“what data is in the IDOC”)
Message type (“how is the IDOC being processed”)
Sender information (“who is the sender of that IDOC”)
Receiver information (“who is the receiver of that IDOC”)
Latest status of EDI processing.
EDI standard and version.
The only two mandatory fields that must be filled are the
Message type (MESTYP) and
IDOC type (IDOCTP)
Note that you have to use uppercase literals when you fill the two fields
The sender information - along with additional information - is automatically filled in by
the ALE layer (in function module “MASTER_IDOC_DISTRIBUTE”)
The receiver information is optional:
If a receiver is specified, a check is carried out against the Distribution Model if this receiver is valid. If it
is, an IDOC is created; otherwise no IDOC will be created.
If no receiver is specified, “MASTER_IDOC_DISTRIBUTE” will determine all valid receivers that are
maintained in the distribution model for that message type and create an IDOC for each receiver !
Data Record




The IDOC data records contain the data of the message. The data records are passed in an
internal table and they have to match the structure of the IDOC (sequence of segments,
min/max, hierarchy etc.)
EDIDD is a generic structure used for all IDOC segments
SEGNAM field identifies the segment type
SDATA contains the actual data of the segment
Status Record- table EDIDS –Information we get from Status record:





Status number
Message
IDoc type
Direction
Data and time stamp

3. 


Detailed description of status by code and text
Location of exception in Intermediate Document
Detector of exception by program and user.

The statuses for outbound IDocs are between '01' and '49', while the statuses for inbound
IDocs begin from '50'.
When an IDoc is created, the IDoc Interface sets the status in the function module
EDI_DOCUMENT_CLOSE_CREATE. All additional
status records are written explicitly by the function module
EDI_DOCUMENT_STATUS_SET.
It is possible to have Custom Statuses also.



TCODES
WE31 IDoc segments
WE30 : Idoc creation
WE19: To change the IDOC
WE02/WE05/WE09 : to search the IDOC
WE09 : To search the IDOC by segment
WE30 IDoc types
WE81 Message types
WE82 IDoc type / message
WE57 Message/Application objects
WE42 Assign a process code to the message type
WE34 IDoc styles
WE32 IDoc views
WE05 IDoc list
WE02 Display IDoc
BD51 Set Function attribute
BD64 Display distribute model
BD67Link the function module to the process code
BD54 Define logical system
SCC4 Assign logical system name to client
SM59 Define RFC destination
BD87 : Reprocess the IDOC
SALE - IMG ALE Configuration root
WE20 - Manually maintain partner profiles
BD64 - Maintain customer distribution model
BD71 - Distribute customer distribution model
SM59 - Create RFC Destinations
BDM5 - Consistency check (Transaction scenarios)
BD82 - Generate Partner Profiles
BD61 - Activate Change Pointers - Globally

4. BD50 - Activate Change Pointer for Msg Type
BD52 - Activate change pointer per change.doc object
BD59 - Allocation object type -> IDOC type
BD56 - Maintain IDOC Segment Filters
BD53 - Reduction of Message Types
BD21 - Select Change Pointer
BD87 - Status Monitor for ALE Messages
BDM5 - Consistency check (Transaction scenarios)
BD62 - Define rules
BD79 - Maintain rules
BD55 - Defining settings for IDoc conversion
WEDI - ALE IDoc Administration
WE21 - Ports in Idoc processing
WE60 - IDoc documentation
SARA - IDoc archiving (Object type IDOC)
WE47 - IDoc status maintenance
WE07 - IDoc statistics
BALE - ALE Distribution Administration
WE05 - IDoc overview
BD87 - Inbound IDoc reprocessing
BD88 - Outbound IDoc reprocessing
BDM2 - IDoc Trace
BDM7 - IDoc Audit Analysis
BD21 - Create IDocs from change pointers
SM58 - Schedule RFC Failures
Basic config for Distributed data:
BD64: Maintain a Distributed Model
BD82: Generate Partner Profile
BD64: Distribute the distribution Model
Programs:
RBDMIDOC – Creating IDoc Type from Change Pointers
RSEOUT00 – Process all selected IDocs (EDI)
RBDAPP01 - Inbound Processing of IDocs Ready for Transfer
RSARFCEX - Execute Calls Not Yet Executed
RBDMOIND - Status Conversion with Successful tRFC Execution
RBDMANIN - Start error handling for non-posted IDocs
RBDSTATE - Send Audit Confirmations
For testing you can use WE19
Steps to create a new IDOC

5. 
1: The first step in creating a new IDOC is to create all the segments that go into that IDOC.
There are some rules that have to be followed while creating the segments:


The name of that segment type must start with „Z1‟
For each field in the segment you have to define a field name, a data element for the
segment structure and a data element for the segment documentation.
The data element for the segment structure has to be of data type „CHAR‟
The IDOC tools create overall three structures:
Z1nnnnn - field names
Z2nnnnn - data elements for structure definition
Z3nnnnn - data elements for documentation
IDoc type
IDoc structure type
Receiver port/partner type/partner number
Sender port/sender type/sender number









2: Second step

6. WE30
The next step is to create the IDOC type by “assembling” all the necessary segments. Part of our
scenario analysis was to define the layout of the IDOC. We should have addressed the following
questions:
Which segments should be used ?
What is the hierarchy of the segments ?
Which segments are mandatory and which are optional ?
How often may a segment be repeated ?
SAP recommends to create the structures as flat as possible. Usually each level of segment hierarchy
results in a looping structure in the corresponding program. Therefore it’s easier to deal with flat
structures.
Conceptually the IDOC type describes the technical structure of the message

7. 3: Third step








Here is how to create a new IDOC type by assembling previously defined segments:
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type
Select creation of new basic IDOC type
Put segments into the IDOC
Segment -> Create
Enter segment name
Enter attributes (Mandatory/Minimum/Maximum number)

8. 4: Fourth step
WE81

9. WE82
Once the IDOC type is defined a message type has to be created. A message type determines how the
data in the IDOC is being processed. This allows to use the same IDOC in different scenarios but process
the data differently through different message types. A Message Type is the equivalent of a business
document type. It characterizes the data being sent across systems, e.g. MATMAS is a message type for
Material Master.
Here is how to define a new message type :
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions->IDOC types -> Maintain IDOC type
Go to message type maintenance:

10. Environment -> Message types
Table view -> Display -> Change
New entries
Customer message types should be in the customer name range (starting with Z)
Last step of the IDOC creation process is to link the new IDOC type with the new message type. Later in
the process the message type will be linked to the outbound and inbound programs. With these
configurations it is determined how the IDOC is being processed.
The relationship between IDOC type and message type is a 1-to-many relationship. That means an IDOC
can be associated with multiple message types thus allowing the IDOC to be processed differently, but a
message type refers to exactly one IDOC type.
Here is how to link the message type with the IDOC type :
Go to the maintenance of IDOC types
In the ALE-IMG: Extensions->IDOC types -> Maintain message type for Intermediate structure
Choose function “EDI: Message types and assignment to IDOC types”
Link your message type with your IDOC type
Table view -> Display -> Change
New entries
Message type : Z……
Basic IDOC type: Z…..
5: fifth step
Assignment of Messgae type to the Idoc type
IDOC STATUS
Note:
Harmless events are generated only if the specific IDOC was in an error state in the previous
polling cycle. Otherwise, no events are generated.

11. The following table describes outbound IDOC status codes that generate Tivoli Enterprise Console
events:
Outbound IDOCs
Code
Error
Event Severity
SAP Meaning
02
Yes
Error
Error passing data to port
03
No
Error if transaction SM58
Data pass to port OK
indicates an RFC transmission
error
04
Yes
Error
Control information of EDI subsystem
05
Yes
Error
Translation
06
No
Harmless
Translation
07
Yes
Error
Syntax check
08
No
Harmless
Syntax check
09
Yes
Error
Interchange handling
10
No
Harmless
Interchange handling
11
Yes
Error
Dispatch
12, 13, 14
No
Harmless
OK
15
Yes
Warning
Interchange acknowledgement negative
16
No
Harmless
Functional acknowledgement
17
Yes
Warning
Functional acknowledgement negative
18
No
Harmless
Triggering EDI subsystem
20
Yes
Error
Triggering EDI subsystem
22
No
Harmless
Dispatch OK, acknowledgement still due
23
Yes
Error
Retransmission
24
No
Harmless
Control information of EDI subsystem
25
Yes
Warning
Processing despite syntax error
26
Yes
Error
Syntax check
27
Yes
Error
ALE error
29
Yes
Error
Error in ALE services
30
No
Harmless
Ready for dispatch (ALE)
31
No
Harmless
IDOC is marked for deletion
33
No
Harmless
Original of an IDOC which was edited
34
Yes
Error
Error in control record of IDOC
36
Yes
Error
Timeout error; electronic signature not
performed
37
Yes
Error
IDOC added incorrectly
38
No
Harmless
IDOC archived
39
No
Harmless
Receive confirmed
40
Yes
Error
Application document not created in target
system
41
No
Harmless
Application document created in target

12. document
The following table describes the inbound IDOC status codes that generate Tivoli Enterprise Console
events:
Inbound IDOCs
Code
Error
Event Severity
SAP Meaning
51, 52
Yes
Error
Posting error
53
No
Harmless
Posting successful
54
Yes
Error
Error during formal application check
55
No
Harmless
Formal application check
56
Yes
Error
IDOC with error added
60
Yes
Error
Syntax error
61
Yes
Warning
Processing despite syntax error
62
No
Harmless
IDOC passed to application
63
Yes
Error
Error passing IDOC to application
64
No
Harmless
IDOC ready to be passed to application
65
Yes
Error
ALE error
68
No
Harmless
IDOC is marked for deletion
70
No
Harmless
Original of an IDOC which was edited
73
No
Harmless
IDOC archived