IDoc (intermediate document)

E-mail Print A AA AAA LinkedIn Facebook Twitter Share This RSS Reprints

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions. A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another. IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands. An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.

What is an IDoc?
An IDoc Type is SAP's format for data being moved between applications. Essentially, SAP has defined what a sales order, financial statement, invoice, etc will look like electronically. This includes how fields are grouped together (segments), the order and hierarchy of these groupings, and the format of each individual field.

If you're familiar with EDI at all, then an IDoc will look very familiar to you. Nearly everything you're used to is there: from segment name to allowable codes to min/max occurs.

It is important to note that an IDoc Type is really just a structure defined on the system and given a name (i.e., ORDERS04). An actual IDoc, however, consists of data, which fits within the defined structure of the IDoc Type. This IDoc is identified by a number rather than by a type.

What is IDOC?
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 NonSAP) 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.

What is the different between ALE, IDOC and BAPI?

ALE ALE is SAP proprietary technology that enables data communications between two or more SAP R/3 systems and/or R/3 and external systems. When a new enterprise resource planning (ERP) solution such as R/3 is implemented, companies have to interface the ERP system with legacy systems or other ERP systems. ALE provides intelligent mechanisms where by clients can achieve integration as well as distribution of applications and data. ALE technology facilitates rapid application prototyping and application interface development, thus reducing implementation time.

The ALE components are inherently integrated with SAP applications and are robust, leading to a highly reliable system. ALE comes with application distribution/integration scenarios as well as a set of tools, programs, data definitions, and methodologies that you can easily configure to get an interface up and running. BAPI BAPIs provide a stable, standardized method for third-party applications and components to integrate into the Business Framework. These interfaces are being specified as part of SAP's initiative with customers, partners and leading standards organizations. Also, SAP has implemented the emerging Object Application Group (OAG) specifications with BAPIs.

Application Link Enabling (ALE)

E-mail Print A AA AAA LinkedIn Facebook Twitter Share This RSS Reprints

Application Link Enabling (ALE) is a mechanism for the exchange of business data between loosely-coupled R/3 applications built by customers of SAP, the enterprise resource management program. ALE provides SAP customers with a program distribution model and technology that enables them to interconnect programs across various platforms and systems. There are three layers in the ALE system: application services, distribution services, and communication services. The vehicle for data transfer is called an IDoc (intermediate document), which is a container for the application data to be transmitted. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system. If the data is distributed from a master system, the same transaction performed by the sender will be performed by the receiving system, using the information contained in the IDoc. Changes made to fields in master data tables can be set to trigger distribution of the changes to slave systems, so that multiple database servers can update the same information simultaneously.

IDocs carry information directly between SAP systems. In order to communicate with a nonSAP system, an IDoc is first transmitted to an intermediary system that translates the data to a format that will be understood by the receiver. Return data also passes through the translating system, where it is again encapsulated into an IDoc.

What is EDI ,ALE and iDOC?

Posted on January 30th, 2011

EDI, stands for Electronic Data Interchange, is the electronic exchange of structured business data between different applications. EDI Architecture

EDI Architecture consists of 1. EDI-enabled applications :They support the automatic processing of business transactions. 2. The IDoc interface: This was designed as an open interface. The IDoc interface consists of IDoc types and function modules that form the interface to the application.

3. The EDI subsystem: This converts the IDoc types into EDI message types and vice versa. This component of the EDI architecture is not supplied by SAP. Advantages of EDI process

Reduced data Entry Errors Reduced Processing cycle time Availability of data electronic form Reduced Paper Work Reduced Cost Reduced Inventories and Better Planning Standard Means of Communicating Better Business Processes Competitive Advantage

What is ALE ?
ALE supports the distribution of the business functions and process across loosely coupled SAP R/3 systems (different versions of SAP R/3). Connections from R/2 and non SAP systems is also supported. ALE supports-

Distribution of applications between different releases of R/3 Systems Continued data exchange after a release upgrade without requiring special maintenance Customer-specific extensions. Communication interfaces that allow connections to non-SAP systems. Coupling of R/3 and R/2 Systems.

Difference between ALE and EDI ?

ALE is used to support distributed yet integrated processes across several SAP systems whereas EDI is used for the exchange of business documents between the systems of business partners (could be non-SAP systems) ALE is SAPs technology for supporting a distributed environment whereas EDI is a process used for exchange of business documents which now have been given a standard format Both ALE and EDI require data exchange. An Idoc is a data container which is used for data exchange by both EDI and ALE processes.

What is IDOC?
IDOC is simply a data container used to exchange information between any two processes that can understand the syntax and semantics of the data. In simple words , an idoc is like a data file with a specified format which is exchanged between 2 systems which know how to interpret that data. IDOC stands for Intermediate Document 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 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.IDOCs are independent of the sending and receiving systems.(SAP-to-SAP as well as Non-SAP)