Below are the SAP TCodes for 'Idoc '. Click on the TCode for more details and click on the Functional Area to see all the tcodes specific to that module/sub-module.' Click on the TCode for more details and click on the Functional Area to see all the tcodes specific to that module/sub-module.' Jul 27, 2019 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 a 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.
IDOC or Intermediate Documents are commonly used in case of data migration between SAP systems or between SAP and legacy system or vice versa.This blog details the steps involved in configuring a new IDOC and also list’s down the various transactions that are used while working with IDOCs.
IDOCs can be classified into two . Inbound IDOCs and Outbound IDOCs.
Inbound IDOC : These are IDOCs which get the data into SAP system from external source i.e PI system or any other external system.
Outbound IDOC: These are IDOCs which are sent out from SAP system to any other system. i.e PI system or any other external system.
Step 1 : We need to check the RFC connections to the target system , it can be PI system or any external system. If it is to a PI system then we need to check the connection under ABAP connections in SM59 transaction and for external system under HTTP Connections to External System.
Step 2: Create a port in transaction WE21 which shows the target system’s RFC destination.
Step 3 : In transaction WE20, create a partner profile and mention the message tpe details .In case of Oubound IDOC’s , mention the message types under Outbound Parameters.In case of Inbound IDOC’s , mention the message types under Inbound Parameters. For outbound parameters ,maintain port and IDOC details, because port describes to which system the IDOC has to flow. Whereas in Inbound IDOC,mention the process code details which determines the inbound function module for processing the data.
Step 4 : Message type SYNCH is the default message type for outbound parameters. Choose a particular message type and maintain the below settings. Under the receiver port mention the port created in transaction WE21. In Output mode, choose Transfer IDOC immediately. In IDOC type mention the IDOC associated with the Message Type.
Step 5: For Inbound IDOCs, mention the process code as APL1 and choose option Trigger Immediately under Processing by Function Module.
Step 6 : In transaction BDFG, we can see which ALE function module we need to enhance for our requirement. In case, we are working with Business Partner we can choose the FM as CRMXIF_PARTNER_SAVE and the Business Object Type as ‘BUS1006’. In IDOCs , SAP by standard provides us to exchange the business partner master data details , BP relationships and BP Hierarchies.
Step 7: In case we are working with Business Transactions we can choose the FM as CRMXIF_ORDER_SAVE and the Business Object Type as ‘BUS20001’.
Step 8 : In our example let us work upon Business Partners. Select the FM name and the Business Object type and click enter. By default all standard messages types would be displayed out.Now to create a new message type , click on Create button as shown below. You will get a popu where in you can enter a Z name.
Step 9 : Once the Z message type is created. Release it as shown.
Step 10 : Select the Z message type and click on the Display button to view the details.
Step 11 : With Z Message Type , Z FM’s for both Inbound and Outbound gets created.
Step 12 : In transaction WE30 we can check the IDOC created.
Step 13 : In transaction WE31 we can check the IDOC segment .
Step 14 : For Inbound IDOCs in transaction code WE42 , select the process code APL1 and click on display . Assign a Z Fm-ZAPPL_IDOC_INPUTI . Create a copy of the standard FM APPL_IDOC_INPUTI into ZAPPL_IDOC_INPUTI .
Step 15 : Under Logical Message , mention the Z message type created.
Step 16 :In transaction WE81 , we can see the message type details.
![Idoc Idoc](/uploads/1/2/5/6/125640371/680136096.png)
Step 17 : In transaction WE82 , we can see the message type and basic type details.
Step 18 : For outbound IDOCs in transaction BD64 , create a distribution model. Goto change mode and click on ‘Create Model View‘. Enter a description and Technical name.
Step 19 : Add the message type under the Distribution Model and maintain the sender and receiver system details.
Step 20 : In transaction BD82, generate the partner profile for the newly created distribution model.
Step 21 : In transaction SMOEAC , we create the sites and subscriptions.Site is the destination where the data needs to be sent.Subsricption is to identify what is the object to be exchanged. (In case of BP data it will be All Business Partner MESG).Subscriptions are assigned under Sites. Type would vary based on our need.
Step 22 : In transaction CRMXIF_C1 , we maintain the message type details against the Site name.
Step 23 : We can even restrict an Outbound IDOC flow based on any condition to a particular Site. A times there could be multiple sites in a system , we can control the flow of IDOC here as well.This can be achieved by maintaining an entry in table – SMW3FDCUST, we assign a copy of standard FM – SMW3_OUTBOUNDADP_CALLADAPTERS against BDoc Type BUPA_MAIN, which is used to do any further customizations. We can do the same for other IDOC types.In the Z FM ,input parameter HEADER we get the Site ID details , based on that we can control the changing parameter – RECEPIENTS.
Step 24 : Apart from the above steps we can use Transaction WE02/WE05 to display any IDOC and WE60 for IDOC Documentation.To reprocess any IDOC use transaction WE19 adn inoput teh IDOC number, a new number gets generated.
Step 25 : Any IDOC has 3 records types – Control, Data and Status.Control Records displays the direction of the IDOC, message type/basic type details.
Data record display the data under multiple segments. In Status Record we can check the IDOC status whether it is a success or failure.
Tables for these 3 record types are as below.
Control Record – EDIDC
Data Records – EDIDD
Status Record – EDIDS
IDoc, short for Intermediate Document, is a SAP document format for business transaction data transfers.[1]Non SAP-systems can use IDocs as the standard interface (computing) for data transfer.[2]IDoc is similar to XML in purpose, but differs in syntax. Both serve the purpose of data exchange and automation in computer systems, but the IDoc-Technology takes a different approach.
While XML allows having some metadata about the document itself, an IDoc is obliged to have information at its header like its creator, creation time etc. While XML has a tag-like tree structure containing data and meta-data, IDocs use a table with the data and meta-data. IDocs also have a session that explains all the processes which the document passed or will pass, allowing one to debug and trace the status of the document.
Different IDoc types are available to handle different types of messages. For example, the IDoc format ORDERS01 may be used for both purchase orders and order confirmations.
IDoc technology offers many tools for automation, monitoring and error handling. For example, if the IDocs are customised that way on a particular server, then a user of SAP R/3 system creates a purchase order; this is automatically sent via an IDoc and a sales order is immediately created on the vendor's system.
When this order cannot be created because of an application error (for example: The price per piece is lower than allowed for this material), then the administrator on the vendor's system sees this IDoc among the erroneous ones and can solve the situation. If the error is in the master data at the vendor's system, he can correct them and order the IDoc to be processed again.
Because of the flexibility and transparency of IDoc technology, some non-SAP technologies use them as well.
Structure of the IDoc[edit]
An IDoc consists of
- Control record (it contains the type of IDoc, port of the partner, release of SAP R/3 which produced the IDoc etc.)
- Data records of different types. The number and type of segments is mostly fixed for each IDoc type, but there is some flexibility (for example an SD order can have any number of items).
- Status records containing messages like 'IDoc created', 'The recipient exists', 'IDoc was successfully passed to the port', 'Could not book the invoice because..'
The IDoc itself is a structured Text-File, that means IDocs can be used on all platforms, there is no need to translate binary data. Each record is identified by the name of the record. The load (data) is stored in a 1000 byte long container. Use transaction WE60 in a SAP-System to get documentation for IDocs, like HTML files and C-header files.
IDoc Transactions in SAP[edit]
The following transactions can be used to create and process IDocs. The list does not include any transaction required for the development of new IDoc types. Please note that you get a comprehensive list of available transactions by using area menu WEDI.
- WE02 - IDoc List report
- WE05 - IDoc List
- WE09 - IDoc Search for Business Content
- WLF_IDOC - IDoc Processing
- This transaction is used to display and edit IDocs.
- WE19 - Test Tool for Idoc Processing
- WE20 - Partner Profile
- This transaction determines a processing code based on the partner profile identified by the control record of the IDoc.
- WE21 - Ports in IDoc processing
- This transaction identifies an external port (RFC, File, ABAP-PI, etc.) that controls the IDoc flow to an external system.
- WE30 - IDoc Type Development
- WE31 - Development IDoc Segment
- WE32 - Development IDoc View
- WE41 - Outbound process code
- This transaction links an outbound processing code specified in a partner profile to a function module.
- WE42 - Inbound process code
- This transaction links an inbound processing code specified in a partner profile to a function module.
- WE60 - IDoc Documentation
- BD87 - Inbound processing
- This transaction processes outbound IDocs.
NAST[edit]
NAST is a technique in SAP-Systems to create messages. Messages can be printed, sent or transferred into IDocs. SAP uses this for many applications e.g. Purchase Orders (PO ). The PO can create a message which might be printed, sent by FAX, or translated into an IDoc of type ORDERS. The IDoc ORDERS can be forwarded in an B2B-process to a vendor.
Error Handling[edit]
SAP provides a standard report (WE02) or (WE05) to display and edit IDocs. Unfortunately, the provided functionality is very basic; therefore, most customers are forced to create their own custom solution.[citation needed].
References[edit]
- ^'SAP Help IDoc Types'. Archived from the original on 2014-05-15. Retrieved 2014-09-16.Cite uses deprecated parameter
|deadurl=
(help) - ^'SAP Library: IDocs'. Retrieved 2017-01-30.
External links[edit]
Retrieved from 'https://en.wikipedia.org/w/index.php?title=IDoc&oldid=876961635'