You are on page 1of 11

IDOC Steps

Skip to end of metadata

Attachments:1 Added by Azhar, last edited by Alon Mizrahi on Nov 01, 2011 (view change) show comment Go to start of metadata

What is a IDOC?
An IDoc is simply a data container that is used to exchange information between any two processes that can understand the syntax and semantics of the data. IDoc is not a process. IDocs are stored in the database. In the SAP system, IDocs are stored in database tables. IDocs are independent of the sending and receiving systems. IDocs are independent of the direction of data exchange.

Creation of IDOCs
Transaction code: WE 30

Steps of Defining Segment


Creating Segment : Tcode - WE31 Creating Message Type : Tcode - we81 Assigning Message type to Idoc type: Tcode - we82

Process
The two processes for IDoc are Outbound Process and Inbound Process.

Outbound Process
When the data is sent out from the system, the process is called Outbound Process and the IDoc is known as Outbound IDoc.

Inbound Process
When the data is coming in, the process is called Inbound Process and the IDoc is known as Inbound IDoc.

Outbound Process (Sending System) Steps :

1) Goto Tcode SALE: Creating the logical system Click on Sending and Receiving Systems Select Logical Systems--Here Define the Logical Systems Click on Execute Button Go for New Entries 1) System Name : LOG1:Description: Sending System 2) System Name : LOG2:Description: Receiving System Press Enter & Save it will ask for Request if you want new request create new request or press continue for transferring the objects. Assigning Client to the Logical System: Select Assign Client to Logical Systems Client Logical System and also Client : Receiving System Logical System Save this Data. : LOG2 : Sending System : LOG1

Step 2) For RFC Creation: Goto Tcode SM59 and Select R/3 Connects Click on create Button RFC Destination Name should be same as partner's logical system name and case sensitive to create the ports automatically while generating the partner profiles Give the information for required fields: RFC Destination Connection type Target Host System No Client User Password : LOG2 :3 : sappdc.wipro.com : 00 : 210 : Login user name :

Save this & Test it and Remote Login Step 3) Goto Tcode BD64: Click on the change button>Click on the create model view Short Text: model view Technical Name: LMOD Save this & press ok Select just created model view Name: "LMOD" Goto add message type Model Name : LMOD Sender Receiver : LOG1 : LOG2

Message type: ZAZHARMESS Save and press Enter.

4) Goto Tcode BD82: Give Model View : LMOD Partner system : LOG2 Execute this by pressing F8 It will gives you sending system port No: A00000000089 (Like)

5) Goto Tcode BD64: Select the model view Goto >Edit >model view > Distribute Press ok & Press Enter.

Run your Zprogram REPORT ZIDOC1 DATA: Begin of imara occurs 0, matnr like mara-matnr, mtart like mara-mtart, end of imara. DATA: wamas_con LIKE edidc, imas_data LIKE edidd OCCURS 0 WITH HEADER LINE, icom_con LIKE edidc OCCURS 0 WITH HEADER LINE. PARAMETERS: e_matnr LIKE mara-matnr, e_msgtyp LIKE edidc-mestyp, e_rcvprn LIKE edidc-rcvprn. * retrive app. data from DB SELECT matnr mtart FROM mara INTO TABLE imara WHERE matnr = e_matnr. *Master idoc control record wamas_con-rcvprt = 'LS'. wamas_con-rcvprn = e_rcvprn. wamas_con-idoctp = 'ZAZHARIDOC'. wamas_con-mestyp = e_msgtyp. * master idoc data records LOOP AT imara. imas_data-segnam = 'ZAZHARSEG'. move imara to imas_data-sdata . APPEND imas_data. ENDLOOP. CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING master_idoc_control = wamas_con TABLES communication_idoc_control = icom_con master_idoc_data = imas_data COMMIT WORK. .

6) Verifying Transfer of IDOCs Tcode - we05 ALE/IDOC Status Codes (outbound):

01> IDoc Added 30 > IDoc ready for dispatch 29 >Error in ALE service Layer 12 >Dispatch ok 03 > Data passed to port ok.

Inbound Process (Receiving System) Steps:


Do the same step as you did in sending system > Creating IDoc > Defining the Segment > Creating Message Type > Assigning the Message Type > Defining the Logical System > Assigning the Logical System > Creating the Distribution Model 1) Goto Tcode - we57: Assign function module to IDoc type Module: Function module Basic type: Message type: Direction: 2 (inbound) 2) Creating Inbound process code - we42 3) Verifying Idoc List Tcode - we05 4) ALE/IDOC Status Codes (Inbound): 50 > IDoc Added 51 >Application Document not posted 64 >IDoc ready to be transferred to application 62 >IDoc passed to application 53 >Application Document posted

IDOC
Posted on December 2, 2007 by jiteshdua

What is 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). 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 stored in character format instead of binary format. 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. 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 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 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. Where and How IDOC is created 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 enabled i.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 typeto 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) Process Code 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. Partner Profile 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. Change Application Data to be transmitted Change Purchase Order Created using transaction ME22n for the Vendor to which partner profile has been created. Go to 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 be checked using transaction WE02 If the status is 03, it implies that IDOC is passed to Port. 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. 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. Extension Child Segs Basic Type (ORDERS01) F1 F2 F3 F4 F5 Cannot be modified IDOC Views An IDOC type can be used for more than one message type, which results in IDOCs containing more fields than required for a particular message type. IDOC views are used to improve performance in generating IDOCs to ensure only the relevant segments are filled with data. IDOC Views are important only for Outbound Processing. IDOC Type F1

F2 F3 F4 F5 Processing Logic The processing logic associated with the IDOC is the function module that is written to handle the inbound/outbound IDOC. Its written just like any function module but has to follow a standard interface (i.e. Import, Export, Changing & Tables) parameters and it is should be RFC enabled. In this function module we are effectively building up a table of type EDID4 (IDOC Data table) and change the control record.

You might also like