Oracle EDI Gateway Overview

Update 27-Aug-1996 Oracle Applications are open applications. Our applications easily extend and integrate with other products to suit our users need. One example of such integration is the Oracle EDI Gateway product. Oracle EDI Gateway is a product that enables our Applications products to integrate into an EDI environment. This document contains the following sections: I. II. III. IV. V. VI. VII. VIII. What is Electronic Commerce? What is EDI? The EDI Process Overview of Oracle EDI Gateway EDI and Standards Support Outbound/Inbound Interfaces EDI Software Providers Transaction Sets

I. What is Electronic Commerce? "Electronic Commerce, end-to-end business transactions, really changes the way (we) conduct business. It is far more than traditional EDI, and the benefits are correspondingly greater." US Department of Defense "EC Through EDI Initiative" Electronic Commerce (EC) brings together a variety of different technologies in order to automate, streamline and improve the business transactions between trading partners. The most common form of EC today is Electronic Data Interchange (EDI). In addition, Electronic FAX and EMAIL transmission of business information allows for many of the benefits found in a typical EDI implementation and may be more appropriate in some environments. Oracle recognizes the benefits that EC has to offer and is actively working to integrate different forms of EC with Oracle Applications. Release 10.6 is the initial release with support for Electronic Commerce with additional functionality to follow. II. What is EDI? Electronic Data Interchange (EDI) is one form of Electronic Commerce that has developed over the last twenty years as the method through which business documents and more recently business information in general is transferred between interested parties.

EDI in the narrow sense (generally implied in common use) means the transmission of this data in a standard format, usually ANSI X12 or UN EDIFACT. ANSI X12 is the set of standards created by ANSI (American National Standards Institute) for the U.S. and Canada. UN EDIFACT is the set of standards developed by the UN and is primarily used in Europe and Asia. Other industry specific standards or industry specific subsets of the ANSI X12 and UN EDIFACT standards also exist. While EDI has been around for a long time, it is a new concept to many industries. The reasons for the slow spread of EDI are many, but the primary ones are: 1) EDI requires a greater level of cooperation between trading partners than is common 2) EDI is difficult to integrate with traditional non-cooperative applications 3) EDI standards are very flexible, allowing each pair of trading partners the ability to implement the standard in a different way. Thus adding the tenth trading partner may not be any easier than adding the second As a result EDI is best suited for use in the following circumstances: 1) Industries where there is a high volume of transactions between a relatively small number of trading partners 2) Hub-and-spoke industries where one large company dictates to all of its suppliers the requirement that they use EDI 3) Where EDI is required by government regulation This is primarily why you see EDI used in the automotive, retail and transportation industries today. EDI, and more generally Electronic Commerce, is usually thought of in the context of Business Process Reengineering (BPR). By its very nature EDI changes how business is conducted. In order to more fully leverage the investment in EDI technology, implementation of EDI can be most successful when it is part of a BPR process. One of the primary goals of EDI is the application-to-application exchange of information. Today the majority of EDI users do not achieve this goal. Instead they implement EDI in a manner known as "rip-and-read". This means that they have a PC which receives the EDI transactions, they then print out these transactions onto paper and then rekey the information into their system. Thus the PC and EDI software is being used as a glorified FAX machine. This implementation though may make sense if you are being forced to use EDI by an important trading partner whose business you cannot afford to lose, while at the same time the volume of transactions does not warrant building the integration with your existing applications. III. The EDI Process The application-to-application exchange of information made possible by EDI can be implemented in a variety of different ways. Most application vendors today have chosen to implement it using flatfiles in a batch environment. Periodically business data is extracted out of the sending application. This is generally done via a flatfile of textual data. This data is then formatted (known as translation) into the particular standard that is being used by trading partners. This formatted textual file is now an EDI document. This EDI transmission is then sent to the trading partner. This is commonly done via a VAN (Value Added Network). The VAN handles the storage and

forwarding of the EDI transmission until the trading partner picks up the EDI transmission off of the VAN. The trading partner then performs the same set of steps in reverse. They pick up the EDI transaction from the VAN, translate it from the EDI standard format to an application specific format, then load the data into their application. IV. Overview of Oracle EDI Gateway Oracle does not plan to build its own EDI translator in order to support EDI functionality within our applications. Instead, we are creating open application interfaces that support EDI, allowing any EDI vendor (including our strategic partners) to integrate their EDI translators with Oracle Applications. By having open interfaces, we allow the customer to choose the best translation tool for their needs. They can continue to use in house EDI translation software with their in house or legacy applications. They can also offload EDI translation to a PC or some other system. Hence, they are allowed the flexibility to choose the EDI translation software and hardware platform that best suits their needs (the main benefit of open systems). Oracle EDI Gateway provides the following components: Oracle Applications Concurrent Program Manager Used for outbound documents to launch the data extract program and for inbound documents to launch the data load program. Transaction-specific Interface Tables Used with outbound documents to store data extracted from the Oracle Applications. Transaction-specific Extension Tables Used with outbound documents to store user supplied data or data from a non-Oracle Applications source that is required by the target EDI documents. Interface Tables Table Used with outbound documents to store the starting record identifier of each section of the output file and to track which transaction-specific interface and extension tables are related. The data extract program uses this information to write the next possible identifier at the beginning of each record line in the output file. Interface Columns Table Used with outbound documents to store the assigned location of the output file of each data element. The data extract program uses this information to write data to the correct position in the output file. Data Extract Programs Used with outbound documents to provide a standard flatfile format that can be mapped to in the EDI translation and mapping software. This flatfile contains all of the data elements stored within Oracle Applications, including the descriptive flexfield data. Stored Procedures

Used with outbound documents to provide encapsulated application logic to record the EDI transaction. (e.g. the Oracle Purchasing product tables need to be updated to reflect the sending of a PO to a supplier.) Data Load Programs Used with inbound documents to load the Oracle Applications Open Interface via SQL*Loader from a standard flatfile format that can be mapped to in the EDI translation and mapping software. Oracle Applications Open Interface Used with inbound documents. Consists of temporary interface tables and a concurrent program. The temporary interface tables are used to store the data loaded by the Data Load Programs. The Concurrent Program is used to validate the data in the temporary interface tables and populate the Oracle Application tables. Validation errors are marked for correction and reprocessing. Documentation Installation and product reference manuals to assist users on how to install, configure and use the Oracle EDI Gateway product. V. EDI and Standards Support No part of the Oracle EDI Gateway product is specific to any EDI standard (ANSI X12, UN EDIFACT, or others), but instead is a generic format that will work with all standards. The standards supported will depend on the EDI translator you chose. However, most translators today will support both ANSI X12 and UN EDIFACT. VI. Outbound/Inbound Interfaces Outbound EDI transactions are supported by providing outbound interfaces via interface tables from our Applications. Interface tables are used to denormalize the data into a format that closely resembles the business document being transacted. Thus for a PO the PO header would contain the vendor name as one would expect, even though in the underlying tables the vendor name is stored in a separate table from the PO header. Using interface tables allows you to get at the data you need with no knowledge of the underlying tables. From these interface tables an extract program runs to download the data from the interface table into a flatfile that in turn can be used by the EDI translation and mapping software to create the final EDI transaction. Alternatively, if your EDI translation software supports direct access to an Oracle database, you can load the data directly from the outbound interface tables and avoid the extra step involved in producing the interim flatfile. We are currently working with our strategic EDI partners to provide this direct interface. Inbound EDI transactions leverage the Open Interfaces we currently have in our Applications products. These Open Interfaces exist to load transactions into our Applications from external sources. EDI is one of those sources. To aid in the use of our Open Interfaces, we provide a SQL*Loader control file that can be used to load the interface tables from a flatfile produced by the EDI translation and mapping software. If your EDI translation software supports direct access to an ORACLE database, you can load the data directly to the Open Interface tables and avoid the extra step involved in producing the interim flatfile. We are currently working with our strategic EDI partners to provide this direct interface.

VII. EDI Software Providers Our goal is to openly integrate with any EDI software product. To make the choice easier Oracle is working with a few EDI translation software providers to integrate their products with Oracle Applications. This work is being done through the Cooperative Applications Initiative (CAI) program which facilitates the integration of third party software products with Oracle Applications. For more information on the CAI program contact Melissa Bailey (MBAILEY.US) in the Global Alliances, Design Migration Services group. A current list of CAI approved EDI translation software providers is available in CAI collateral, part #C10925. VIII. Transaction Sets Our goal is to support all EDI transaction sets that are applicable to the applications we produce. This is a large number of different transactions and each transaction has two different implementations, depending on the direction of the data. For example, a PO outbound transaction requires an interface from Oracle Purchasing to get the information; however, a PO inbound transaction utilizes the Open Interface in Order Entry to load the data into the application. Thus, to fully implement the EDI transaction set for a purchase order requires interfaces in two different Applications products. Reference EDI Gateway product Statement of Direction (part #: A34196) for list of supported EDI transactions.