EDI: Still Important After All These Years

Chapter 1, "There's No Business Like E-Business," describes Electronic Data Interchange ( EDI ) and focuses on its accomplishments and drawbacks, especially for smaller businesses. EDI offers valuable lessons in its 30 years of experience, despite EDI's mixed record with smaller businesses, from which emerging frameworks like ebXML should learn.[7] This section examines these lessons in detail to see how they're being absorbed into the ebXML approach. Understanding the entrenched EDI systems is important in clarifying and distinguishing how ebXML is moving beyond the rigid limitations it encompasses to a new, more powerful model.

Basic Message Structure

The EDI standards, such as ASC X12 in North America and UN/EDIFACT elsewhere in the world, show the value of creating a basic message structure applicable across industries. For example, a variety of industries have adopted the standard X12 invoice (transaction set number 810), advance ship notice (856), purchase order (850), and purchase order acknowledgment (855) transactions. Having a common message structure defined in advance makes it possible for software vendors to develop packages that can address multiple industries, and thus spread their development costs over a wider pool of customers. The basic structure of these transactions provides a template for building common solutions, thus making the job at least somewhat easier. And having a basic transaction structure helps make it possible for companies in various industries to agree on a common message structure (although using the implementations of those messages is rare outside the specific industry).

Paradoxically, the success of this approach is also one of its problems. Attempting to shoehorn everyone's business transactions into one fixed set limits the scope and breadth of what can be achieved. Moving beyond these limitations is the key to success for ebXML and also the lynchpin of the approach of the technical architecture for ebXML.

Interchangeable Components

A further aspect of EDI is the use of interchangeable components in business messages, which can be reused across many industries. As mentioned earlier, different industries can use the same basic transaction set (invoice, advance shipping notice, and so on). Each transaction set in turn has three sections called tables : heading, detail, and summary. The heading has data that applies to the message as a whole, such as identification of sender and receiver, and transaction tracking number. The detail area, as the name implies, contains the substance of the message, such as line items on a purchase order or shipping dates and times. The summary table holds data showing totals, such as total number of line items or total monetary amounts in the transaction. The summary can also contain hash totals for quality assurance, in which trading partners can sum the totals in the detail table and compare them to the hash totals.[8]

Each table in turn is composed of data segments, which are functionally related collections of data elements. Chapter 1 presents a data segment that represents dates and times, certainly a piece of information applicable to a wide range of business uses. Data segments then break down into data elements, both simple and composite. The vast majority of the data segments and elements are reusable components, which makes it easier to take advantage of previous EDI development work, as well as to ensure compatibility with modern software development practices. The goal of the ebXML core components group is to create an extensible mechanism for managing reusable groups of information. The traditional EDI view of data segments and elements has been replaced with an XML-based model of parent- and-child groupings of information representing core (common and consistent) pieces of business information and associated process semantics.

Business Semantics

A significant contribution of EDI to business data exchange overall and ebXML in particular is the accumulated experience of defining the semantics for the thousands of companies now exchanging EDI transactions or messages, which are tested over time and designed to meet real-life business needs. The industries and companies using EDI today have thought through the business scenarios, needs of trading partners, and external constraints (such as legal requirements), and brought forward a set of messages and data elements that companies send to each other in high volumes every day. The future development of business data exchange using XML needs to make use of this rich base of practical experience with e-business.[9] The ebXML core component work is designed to allow the reuse of this existing knowledge base.

The vast majority of data segments and elements are reusable components, which makes it easier to take advantage of previous EDI development work, as well as to ensure compatibility with modern software development practices.

Business Procedures

In developing a technology for EDI, the standards committees also established good business practices, which in some cases became part of the standards themselves . Early on, trading partners sending and receiving EDI transactions discovered ”to no one's surprise ”that doing business electronically required a formal set of business procedures. We share a selection of those best practices in this section.

Ground Rules Established in Advance

Business trading partners need to establish agreements in advance stating the ground rules for these exchanges. These agreements correlate in the EDI world to the trading partner agreement ( TPA ). These agreements spell out the business process with its associated electronic transaction sets to be exchanged, responsibilities of senders and receivers, versions of the standards used, and exception procedures (what to do in case of problems). They also offer agreed-upon legal stipulations that apply to all transactions ” often called boilerplate for a particular industry domain and implementation. In EDI messages, trading partners can simply refer to the TPA rather than spelling out its provisions each time. One whole part of the ebXML specifications deals exclusively with the steps required to assemble such electronic collaboration protocol agreements (CPAs), and particularly how to create your own collaboration protocol profile (CPP) to allow your business to participate with others using the ebXML specifications.[10]

Unique Identification

The next important aspect is that every message sent and received needs a unique identification number. Unique identifiers on the messages, companies exchanging EDI transactions could not distinguish one particular message from others in a business process sequence. Also, any auditing of message traffic requires unique identifiers on messages. In case of problems, auditors need to establish an electronic audit trail[11] to determine responsibility for actions. Unique identifiers help avoid processing duplicate messages as well. ebXML embraces this principle and supports multiple classification schemes for unique identifiers.

The parties in the transactions also need unique identification. Paper forms can capture company name and address locations, which is all a reader needs to tell one party from another. With electronic transactions, however, sending and receiving systems need more reliable indicators of the parties involved in the transactions. As a result, some industries have established their own identification systems, the most well known being the company codes assigned by the Uniform Code Council for bar codes and retail transactions. The common Universal Product Code ( UPC )[12] found on retail grocery labels has a one-digit UCC prefix that identifies the particular numbering system, such as regular product identifiers or store coupons . A five-digit company code assigned by UCC follows the prefix. When combined with the UCC prefix, the resulting identifier is guaranteed to be unique.[13]

Many companies already have a D-U-N-S number for credit reporting; thus, using it for electronic transactions adds little burden to the respective trading partners.

Other industries have chosen to use identifiers assigned by a third party, such as Data Universal Numbering System (D-U-N-S) codes, a nine-digit string assigned by Dun and Bradstreet (D&B). Companies doing business with the U.S. government, for example, now need a D-U-N-S number for federal agencies to accept their transactions. Many companies already have a D-U-N-S number for credit reporting; thus, using it for electronic transactions adds little burden to the respective trading partners.[14]

Meanwhile, the need for unique identification extends to products documented in EDI transactions. The use of manufacturer product numbers across the supply chain is a practice started in the grocery industry, and is now ubiquitous. The bar code scanners in retail stores capture the same identifiers applied to the product label by the manufacturer. Wholesalers or distributors in the chain also use that number. As a result, all parties in the transactions have the same product identifiers, which simplifies the transactions and reduces uncertainties.[15]

Transmit Variable Data

We described earlier how trading partner agreements let companies establish the legal ground rules for transactions and also provide a document that they can reference in their messages without repeating the information each time.That same principle applies more generally to data sent in EDI transactions, namely that trading partners send only variable data ”new or changed information ”not data that the companies already have in their information systems. For example, a shipping notice sent by a seller of goods to a buyer can reference the purchase order number that authorized the shipment in the EDI transaction, rather than repeating all of the details in the order. As a result, the electronic ship notice does not need to supply the delivery date requested by the buyer; the buyer already has that information in the purchase order.

Functional Acknowledgment

Nearly all EDI transactions trigger an acknowledgment from the receiving party. The purpose of this acknowledgment is to verify to the sender that the receiving system not only got the transaction but was also able to process and interpret the business information without any problems. Any problems are reported back to the sender accordingly . The transaction used for this purpose most often in X12 is called the functional acknowledgment (transaction set number 997 in the X12 standard), which provides for a verification of receipt as well as a review of the X12 syntax in the EDI file.[16]

Companies exchanging messages need to be aware of the limitations of standard functional acknowledgments, however. While the functional acknowledgment transaction can document receipt of the original message by the receiving system, it doesn't indicate when the receiving company used the data to update its files or engaged in any action that the message requested. The EDI standards include separate transactions to report on these business activities. For example, the purchase order transaction set in the X12 standard has a matching purchase order acknowledgment transaction, as well as related order change and change acknowledgments. And while the functional acknowledgment can test the X12 syntax in the original message, it doesn't check the business content. If an electronic purchase order has incorrect product identifiers or part numbers, for example, only the trading partners' internal systems can catch these errors.

The ebXML Transport Packing and Routing specifications provide extended mechanisms that completely address these needs and provide new systems for today's web services and electronic marketplaces that EDI never supported.