You are on page 1of 12

IDOC

WHAT IS AN IDOC ? -- An IDOC is not a process : The term IDOC stands for Intermediate Document.It is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data.An IDOC is created as a result of executing an outbound ALE or EDI process. -- IDOCs are stored in the database :In the SAP system,IDOCs are stored in the database tables. -- Every IDOC has a unique number :When an IDOC is generated a unique number is assigned to it.This number is unique within a client.

IDOC
-- IDOC are independent of the sending and receiving systems They can be used for SAP-to-SAP and SAP to non-SAP process communication as long as the participating processes can understand the syntax and the semantics of the data. -- IDOCs are based on EDI standards but closer to EDIFACT standards: The size and the format of data elements in an IDOC type are derived from these standards wherever applicable.For example, if a material number is represented by 20 characters in an EDIFACT message, the corresponding data element in the IDOC is also 20 characters.If there is a conflict in data size between standards,the one with greater length is adopted.This approach ensures compatibility with most standards.

IDOC
-- IDOCS are independent of the direction of data exchange: An inbound and outbound process can use an IDOC.For example, the ORDERS01 IDOC is used by the PURCCHASING module to send a purchase order, and it is also used by the SALES AND DISTRIBUTION module to accept a sales order.This technique avoid creating redundant IDOC types for the same information. -- IDOCS can be viewed in text editor and do not contain binary data:Data is stored in a character format.When transferred to the operating system,an IDOC is stored in a file in text format.

IDOC
IDOCS ARE DEFINED IN WE31. The definition of the IDoc structure MATMAS01 is deposited in the data dictionary and can be viewed with WE30. HEADER DATA PLUS MANY DATA RECORDS = 1 RECORD Any IDoc consists of two sections the header record which is always the first line of the file and provides the administrative information. The rest of the file is made up by the data records which contain the application dependent data, in our example the material master data.

IDOC
HEADER RECORD WITH CONTEXT INFORMATION Each IDoc is trailed by a header record, which provides important information about the context under which the IDoc package has been received. The header record has a fixed pre-defined structure, which is defined in the data dictionary as EDIDC and can viewed with SE11 in the R/3 data dictionary. The header will tell us for example, that the IDoc has been received from a sender with the name PROCLNT100 and sent to the system with the name DEVCLNT100 . It further tells us that the IDoc is to be interpreted according to the IDoc definition called MATMAS01

IDOC
SENDER The sender's identification PROCLNT100 tells the receiver who sent the IDoc. This serves the purpose of filtering unwanted data and gives also the opportunity to process IDocs differently with respect to the sender. RECEIVER The receiver's identification DEVCLNT100 should be included in the IDoc header to make sure, that the data has reached the intended recipient. IDOC TYPE The name of the IDoc type MATMAS01 is the key information for the IDoc processor. It is used to interpret the data in the IDoc records, which otherwise would be nothing more than a sequence of meaningless characters

IDOC
CONTENTS OF AN IDOC PACKAGE An SAP IDoc is always made up out of two logical blocks. A Control Record A Table With The IDoc Data

IDOC
CONTROL RECORD SERVES AS A COVER SLIP FOR TRANSPORT The control record carries all the administrative information of the IDoc, such as its origin and its destination and a categorical description of the contents and context of the attached IDoc data. This is very much like the envelope or cover sheet that would accompany any paper document sent via postal mail. CONTROL RECORD NECESSARY TO FIND ITS DESTINATION AND THE PROCESSING FB The control record is necessary to find the correct destination of the IDoc and to determine the processing FB. The control record tells you who sent the IDoc, who is the designated

IDOC
receiver and what kind of data you will see. With these three information bits, the SAP standard workflow facility will determine the FB, to process the Idoc. CONTROL NECESSARY TO PROCESS IDOC DATA Once the IDoc data is handed over to a processing FB, you will no longer need the control record information. The FBs are usually designed in a way, that they are aware of the individual structure of the IDoc type and the meaning of the data. In other words: for every context and syntax of an IDoc, you would write a proper FB to deal with.

IDOC
IDOCS are stored in a couple of database tables EDI* for the data,control data and the log files.

IDOC
ALL INBOUND AND OUTBOUND ARE STORED IN EDID4 All IDoc, whether sent or received are stored in the table EDID4. The corresponding control file header goes into EDIDC. There are standard programs who read and write the data to and from the IDoc base. These programs and transaction are heavily dependent on the customizing, where rules are defined which tell how the IDocs are to be processed.

IDOC