An IDoc is a container that can be used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure used in SAP to store application data. This feature enables SAP to rearrange its internal structure without affecting the existing interfaces.
An IDoc represents an IDoc type and IDoc data, depending on the context in which the word IDoc is used. An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type INVOIC01 defines the format of an invoice document. IDoc data can be seen as an instance of an IDoc type.
IDocs types are based on EDI standards (ANSI X12 and EDIFACT). They are closer to the EDIFACT standards than to ANSI X12. The size and format of data elements in an IDoc type are derived from these standards wherever applicable. The IDoc format is compatible with most EDI standards.
An IDoc structure consists of several segments, and segments consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, and optional versus mandatory segments. Segments define a set of fields and their formats.
An IDoc is an instance of an IDoc type. Each IDoc is assigned a unique number for tracking and future reference. An IDoc serves as a focal object for tracking the state of the process that generated it. An IDoc consists of the following three types of records.
Parts of Idoc
- One control record
- One or many data records
- One or many status records Control record. There is only one control record per IDoc. The control record contains all the control information about an IDoc, including the IDoc number, sender and receiver information, and other control information such as the message type it represents and IDoc type. The structure of the control record is the same for all IDocs and is defined by SAP. The field values, of course, can be different.
- Data record. An IDoc can contain multiple data records, as defined by the IDoc structure. Segments translate into data records. Data records store application data such as purchase order header information, purchase order details lines, and other relevant information.
- Status record. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process as the IDoc achieves different milestones. A status code, date, and time are assigned at every milestone.
In the outbound process, after the IDoc is passed from SAP to the subsystem, the status records are generated by the subsystem and passed back to SAP. For the inbound process, SAP generates the status records because after an IDoc is generated, it stays in the system. Status records help you determine the status of the process and whether an IDoc is in error.
Multiple Messages per IDoc Type
A message represents a specific type of document that is transmitted between two partners. Orders, order responses, order acknowledgments, invoices, and shipment notices are examples of messages. An IDoc type in SAP can be used to represent several messages or business documents. Of course, the messages must be logically related.
For example, in the figure , an IDoc type represents all possible information about an employee. This IDoc type is being used to send two separate messages to two separate applications. One message is the Employee Salary Information; the other is the Employee Security Information. The difference between the two messages is the set of segments used.
SAP uses a single IDoc type for several logically related messages. For example, the Orders IDoc type (ORDERS02) is used for several messages, such as Order (ORDERS), Order Response (ORDRSP), and Order Change (ORDCHG).
See complete course about ALE IDOC'S HERE.
Related Posts about EDI:
EDI outbound process
EDI Process components AND part two Business Processing using EDI Introduction to EDI EDI converter for SAP EDI standards EDI architecture
EDI Work flow part one, two, three and four
EDI Interface testing
Out bound testing for EDI and part two
Inbound Process utilities