Electronic Data Interchange (EDI)

Electronic Data Interchange (EDI)

One of the first major attempts to electronically enable the supply chain was the development of the Electronic Data Interchange (EDI) specification. Although computers had been introduced into the supply chain since almost the first year they had been commer-cially available, processes and methods were far from standard. In addition, these sys-tems needed an effective way of communicating between disparate points in the supply chain. Using telecommunications, companies could transmit data electronically over reg-ular telephone lines or private networks and have the resultant data inputted directly into their trading partners’ business applications.

However, this means of computer telecommunications only solved part of the problem in tying together the parts of the supply chain. These early electronic interchanges were based on proprietary formats agreed to in advance between trading partners. As the num-ber of trading partners increased, it became increasingly more difficult to exchange data in a reliable manner. Estimates suggest that 70 percent of all computer input has previ-ously been output from another computer. Each reentry of data is a potential source of error. It has also been estimated that the cost of processing an electronic requisition can be one tenth the cost of handling its paper equivalent. Therefore, a standard format for the exchange of data was needed. Work began in the 1960s as a cooperative effort between industry groups mainly in the transportation sector to produce such a standard format. In 1968 the United States Transportation Data Coordinating Committee (TDCC) was formed to coordinate the development of translation rules among four existing sets of industry-specific standards. It evolved to become the EDI specification in the 1970s, gaining first national and then international standard status in subsequent years. The stated goals of the EDI format were as follows:

   To reduce the labor-intensive tasks of exchanging data, including data reentry

   To be hardware independent and unambiguous in message content so that these messages could be used by trading partners of all types

   To provide a reliable means for the delivery of transactions and messages

One of the major features EDI has enabled is a concept called vendor-managed inventory (VMI). The concept around VMI is to shift the responsibility for analyzing sales and for deciding when the buyer will receive new product to the seller rather than the buyer. Using raw sales data sent by the buyer in EDI format, the seller is enabled to make judg-ments as to which products should be produced for sale. In this manner, risks and responsibilities are shifted from the buyer to the seller.

There are two primary syntaxes for EDI: The Accredited Standards Committee (ASC) X12, used mainly in North America, and the Electronic Data Interchange For Administration, Commerce, and Transport (EDIFACT), used in Europe and Asia.

EDI has historically used a standardized, secure, and reliable electronic transmission medium, originally known as the value-added network (VAN), to transmit individual EDI messages between participants in the supply chain process. The VAN provides a common connection point for participants by means of electronic mailboxes. The VAN functions in much the same way as a post office, providing not only a means to get messages from point to point, but also providing a means to guarantee that a message is received in a secure and robust manner. EDI participants dial in to a VAN, deposit all their outbound EDI messages, and simultaneously pick up any EDI messages destined for them.

VANs provide basic services, such as message tracking, that record whether and when messages arrive, are transferred, and are picked up. Faults and disputes can easily be resolved by referring to VAN audit trails. VANs also have the capability to deal with a wide variety of different computers and communication protocols. In effect, the VAN serves as an intermediary that helps to assist in the communication process by serving as a standard, neutral transportation layer—much the same role that the Internet plays today.

Although the VAN is considered by many to be an outdated mode for transportation of EDI messages, it nonetheless is in widespread use. There have been many efforts to move EDI transmission to the Internet, based on its capability for delivering messages at a relative low cost and with simplicity. However, many companies still rely on the VAN for reliable, robust, and secure transmission of their documents. Perhaps that may change in the future, but the VAN will have long-lasting influence as long as EDI remains in use.

EDI messages are text-based, positional, structured messages that are arranged into trans-action sets. Each transaction set represents an exchange between supply chain partners in order to execute some business process. As a result, transaction sets are very focused in nature. The X12 Release 3030 contains 161 transaction sets. Many of them are quite spe-cific; some are shown in Table 20.1.

TABLE 20.1    Sample EDI Transaction Sets

Transaction Set :  Description

130    Student educational record (transcript)

810    Invoice

819    Operating expense statement

820    Payment-order/remit-advice

822    Customer account analysis

823    Lockbox

830    Planning schedule

832    Price/sales catalog

837    Healthcare claim

840    Request for quotation

843    Response to request for quote

844    Product transfer account adjust

845    Price authorization acknowledgment

846    Inventory inquiry

849    Response to product transfer

850    Purchase order

855    Purchase order acknowledgment

856    Ship notice/manifest

860    Purchase order change

861    Receiving advice

862    Shipping schedule

863    Report of test results

865    Purchase order change acknowledgment

867    Product transfer and resale report

869    Order status inquiry

870    Order status report

997    Functional acknowledgment

EDI transactions are processed by a well-choreographed set of software applications and systems. EDI software packages perform two fundamental tasks: encoding data into the EDI format and subsequently decoding response messages. Major components of this system include “translators” to go between EDI and non-EDI systems, “mappers” to associate differing versions of EDI transaction sets, connection software to facilitate

and enable the use of VAN or Internet-based transfers, and internal software integration applications.

Despite the lofty goals of EDI, many of its core benefits have not come without costs and challenges. EDI systems aren’t inexpensive to set up. Most EDI “hub” implementations average over $1 million to set up, whereas individual “spokes” require an investment averaging over $45,000—and these are just the primary implementation costs. Maintenance and ongoing services easily double this figure. In addition, systems take between several days to months before trading partners are up and running.