This article is about EDI (Electronic Data Interchange) basics and also includes some of the basics doubts we get about EDI. This article speaks about the general Terminology and helps you understand the high-level overview of the EDI process. The material here is particularly important for someone who is new to EDI technology. I will try my best to keep it in very simple words. Why EDI Evolved? Let us consider a simple business scenario. A customer who wants to purchase an item creates a purchase order and then faxes or mails it to the vendor. The vendor receives the purchase order and manually keys in a sales order. The vendor’s system generates a confirmation date that is sent back to the customer via fax or mail. The vendor then ships the goods via a carrier. The carrier delivers the products to the customer. When the goods are shipped, the vendor invoices the customer. The customer makes the payment by check, and the vendor deposits the check in the bank. Finally, funds are transferred from the customer’s account to the vendor’s account. 
Figure 1.1: Typical business documents exchanged by business partners Now think how much of information needs to be transferred and tracked to run the business. This simple scenario requires the exchange of various documents between several business partners at different times. All this electronic data was exchanged using floppy disks and other secondary devices. So, ANSI committee was formed to define the standards. Hence the electronic exchange of business documents in a standard format gave birth to what is known as EDI. What is EDI? EDI (Electronic Data Interchange) is the electronic exchange of business documents* between the computer systems of business partners, with a standard format over a communication network. It can also be called as paperless exchange. 
Key Terms: Business Documents: It is a legal document that speaks about the transaction that is been conducted between two different Parties. Examples of Business Documents are: • Purchase Requisitions • Purchase Orders • Sales Order • Invoices Standard Formats: The business documents that is been exchanged between business partners need to be in a standard format. ANSI X12 (American National Standards Institute) or EDIFACT (Electronic Data Interchange For Administration, Commerce, and Transport) are two standards which supply a common language for formatting the information content that is been exchanged. Note: EDIFACT is widely used when compared to ANSI X12. Components in the EDI Process The components are: • Sender • Receiver • Language • Content • Medium In EDI, the senders and receiver are called trading partners (Customers and Vendors) and the ANSI X12 or EDIFACT standards supply a common language for formatting the information content of common messages. Software tools called translators (Tibco, Macerator) enable trading partners to communicate in standard language, supplying the messaging medium. * SAP refers to these translators as EDI Subsystems. What is an IDoc? An IDoc is a container that can be used to exchange data between the trading partners. So, this IDoc is nothing but your business document that is been exchanged for any particular transaction. IDoc Type: Every IDoc is identified with IDoc type and IDoc data, depending on which the IDoc is processed. An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type ORDERS02 defines the format of an Order document. IDoc data is nothing but the instance of the IDoc type. These IDoc types are based on EDI standards (ANSI X12 and EDIFACT). They are closer to the EDIFACT standards than to ANSI X12. IDoc: Each IDoc is assigned a unique number for tracking and future reference. An IDoc consists of three types of records: • One Control record • One or many data records • One or many status records Control record: There is only one control record per IDoc. It consists of • IDoc Number • Sender and Receiver information • IDoc Message Type* • IDoc Type Data record: An IDoc can contain multiple data records, as defined by the IDoc structure. Data records store application data such as purchase order header information, purchase order details 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 like status code, date and time at every stage. * An IDoc type in SAP can be used to represent several messages or business documents. Let say, Employee information is IDoc type which can used in Employee Salary or Employee Security which is nothing but IDoc Message type. 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 (ORDERSP), and Order Change (ORDCHG). SAP EDI Process The SAP EDI process comprises two distinct processes: • Outbound Process • Inbound Process Translate these terms from the SAP system side. The Outbound Process: The outbound process sends document from the SAP system to a business partner. Let see what the steps involved in the outbound process: 1. The application document is created. The first step in the outbound process is creation of the application document using the SAP system such as purchase order or sales order. This is not any special step it is common as a vendor or customer has created the sales order or purchase order using the SAP application. The document when created leaves some hook for the EDI process to begin. 2. The IDoc is generated. The application document just created is now formatted to an IDoc format. 3. The IDoc is transferred from SAP to the operating system. The IDoc created in above stage resides in the SAP database. For other EDI subsystem to process, IDoc needs to be converted into a file format. In this step it is transferred to the operating system as a text file. 4. The IDoc is ready for use. Any third-party software called translators carriers out the transformation process and response status back to the SAP systems. Thus, from the SAP’s perspective after the IDoc is delivered to the subsystems, SAP does not have control over the process, but it maintains the status reported by the EDI subsystems. The Inbound Process It is simply reverses the steps of the outbound process. SAP receives an IDoc (purchase order) from a business partner and created SAP application document in the database. 1. IDoc is transferred to the SAP layer. SAP receives an IDoc from a business partners and then SAP start further processing of the received IDoc. 2. Application Document is created. The IDoc received from the sub-system is passed to a posting program. This program creates an application document such as sales order, purchase order. 3. The application document can be viewed. The application document created via EDI is the same as any document created manually in the system. SUMMARY SAP supports the EDI process by providing EDI- enabled applications capable of sending and receiving IDoc messages. IDocs are SAP’s proprietary format for exchanging data between business applications. IDoc are based on EDI standards and have a very flexible structure to accommodate business rules for representing data. These IDocs are mapped to an EDI standard format by EDI subsystems, which are third-party tools.
