|
This article needs sources or references that appear in
reliable, third-party publications. Alone, primary sources and sources affiliated with the
subject of this article are insufficient for an accurate encyclopedia article. Please include more appropriate citations from reliable sources. |
An inter-company, application-to-application communication of data in standard format for business transactions Electronic
Data Interchange (EDI) is a set of standards for structuring
information that is to be electronically exchanged between and within businesses, organizations, government entities and other
groups. The standards describe structures that emulate documents, for example purchase orders to automate purchasing. The term
EDI is also used to refer to the implementation and operation of systems and processes for creating, transmitting, and receiving
EDI documents.
Despite being relatively unheralded, in this era of technologies such as XML services, the
Internet and the World Wide Web, EDI is still the data
format used by the vast majority of electronic commerce transactions in the
world.
Standards
Generally speaking, EDI is considered to be a technical representation of a business conversation between two entities, either
internal or external. Note, there is a perception that "EDI" consists of the entire electronic data interchange paradigm,
including the transmission, message flow, document format, and software used to interpret the documents. EDI is considered to
describe the rigorously standardized format of electronic documents.
The EDI (Electronic Data Interchange) standards were designed to be independent of communication and software technologies.
EDI can be transmitted using any methodology agreed to by the sender and recipient. This includes a variety of technologies,
including modem (asynchronous, and bisynchronous), FTP, Email, HTTP, AS1, AS2, WebSphere
MQ, etc. It is important to differentiate between the EDI documents and the methods for transmitting them. While comparing
the bisynchronous protocol 2400 bit/s modems, CLEO devices, and value-added networks used to
transmit EDI documents to transmitting via the Internet, some people equated the non-Internet technologies with EDI and predicted
erroneously that EDI itself would be replaced along with the non-Internet technologies. These non-internet transmission methods
are being replaced by Internet Protocols such as FTP, telnet, and e-mail, but the
EDI documents themselves still remain.
As more trading partners use the Internet for transmission, standards have emerged. In 2002, the IETF published RFC 3335, offering a standardized, secure method of transferring EDI data
via e-mail. On July 12th, 2005, an IETF working group ratified RFC4130 for MIME-based HTTP EDIINT (aka. AS2) transfers, and is
preparing similar documents for FTP transfers (aka. AS3). While some EDI transmission has moved to these newer protocols the providers of the value-added networks remain active.
EDI documents generally contain the same information that would normally be found in a paper document used for the same
organizational function. For example an EDI 940 ship-from-warehouse order is used by a manufacturer to tell a warehouse to ship
product to a retailer. It typically has a ship to address, bill to address, a list of product numbers (usually a UPC code) and quantities. It may have other information if the parties agree to include it.
However, EDI is not confined to just business data related to trade but encompasses all fields such as medicine (e.g., patient
records and laboratory results), transport (e.g., container and modal information), engineering and construction, etc. In some
cases, EDI will be used to create a new business information flow (that was not a paper flow before). This is the case in the
Advanced Shipment Notification (856) which was designed to inform the receiver of a shipment, the goods to be received and how
the goods are packaged.
There are four major sets of EDI standards:
- The UN-recommended UN/EDIFACT is the only
international standard and is predominant outside of North America.
- The US standard ANSI ASC X12 (X12) is predominant in
North America.
- The TRADACOMS standard developed by the ANA (Article Numbering Association) is predominant
in the UK retail industry.
- The ODETTE standard used within the European automotive industry
All of these standards first appeared in the early to mid 1980s. The standards prescribe the formats, character sets, and data
elements used in the exchange of business documents and forms. The complete X12 Document
List includes all major business documents, including purchase orders (called "ORDERS" in UN/EDIFACT and an "850" in X12)
and invoices (called "INVOIC" in UN/EDIFACT and an "810" in X12).
The EDI standard says which pieces of information are mandatory for a particular document, which pieces are optional and give
the rules for the structure of the document. The standards are like building codes. Just as two kitchens can be built
"to code" but look completely different, two EDI documents can follow the same standard
and contain different sets of information. For example a food company may indicate a product's expiration date while a clothing
manufacturer would choose to send color and size information.
Standards are generally updated each year.
Specifications
Organizations that send or receive documents from each other are referred to as "trading partners" in EDI terminology. The
trading partners agree on the specific information to be transmitted and how it should be used. This is done in human readable
specifications (also called Message Implementation Guidelines). While the standards are analogous to building codes, the
specifications are analogous to blue prints. (The specification may also be called a mapping but the term mapping is typically
reserved for specific machine readable instructions given to the translation software.) Larger trading "hubs" have existing
Message Implementation Guidelines which mirror their business processes for processing EDI and they are usually unwilling to
modify their EDI business practices to meet the needs of their trading partners. Often in a large company these EDI guidelines
will be written to be generic enough to be used by different branches or divisions and therefore will contain information not
needed for a particular business document exchange. For other large companies, they may create separate EDI guidelines for each
branch/division.
Transmission
Trading partners are free to use any method for the transmission of documents. In the past one of the more popular methods was
the usage of a bisync modem to communicate through a Value Added Network (VAN). Some organizations have used direct modem to modem connections and
Bulletin Board Systems (BBS), and recently there has been a move towards using
some of the many Internet protocols for transmission, but most EDI is still transmitted using a
VAN. In the healthcare industry, a VAN is referred to as a "Clearinghouse".
Value Added Networks
In the most basic form, a VAN acts as a regional post office. They receive transactions, examine the 'From' and the 'To'
information, and route the transaction to the final recipient. VANs provide a number of additional services, e.g. retransmitting
documents, providing third party audit information, acting as a gateway for different transmission methods, and handling
telecommunications support. Because of these and other services VANs provide, businesses frequently use a VAN even when both
trading partners are using Internet-based protocols. Healthcare clearinghouses perform many of the same functions as a VAN, but
have additional legal restrictions that govern protected healthcare information.
VANs also provide an advantage with certifcate replacement in AS2 transmissions. Because each node in a traditionally
business-related AS2 transmission usually involves a security certificate, routing a large number of partners through a VAN can
make certificate replacement much easier.
Internet
Until recently, the Internet transmission was handled by nonstandard methods between trading partners usually involving
FTP or email attachments. There are also standards for embedding EDI documents
into XML. Many organizations are migrating to this protocol to reduce costs. For example,
Wal-Mart is now requiring its trading partners to switch to the AS2 protocol.
Interpreting data
Often missing from the EDI specifications (referred to as EDI Implementation Guidelines) are real world descriptions of how
the information should be interpreted by the business receiving it. For example, suppose candy is packaged in a large box that
contains 5 display boxes and each display box contains 24 boxes of candy packaged for the consumer. If an EDI document says to
ship 10 boxes of candy it may not be clear whether to ship 10 consumer packaged boxes, 240 consumer packaged boxes or 1200
consumer packaged boxes. It is not enough for two parties to agree to use a particular qualifier indicating case, pack, box or
each; they must also agree on what that particular qualifier means.
EDI translation software provides the interface between internal systems and the EDI format sent/received. For an
"inbound" document the EDI solution will receive the file (either via a Value Added Network or directly using protocols such as
FTP or AS2), take the received EDI file (commonly referred to as a "mailbag"), validate that the trading partner who is sending
the file is a valid trading partner, that the structure of the file meets the EDI standards and that the individual fields of
information conforms to the agreed upon standards. Typically the translator will either create a file of either fixed length,
variable length or XML tagged format or "print" the received EDI document (for non-integrated EDI environments). The next step is
to convert/transform the file that the translator creates into a format that can be imported into a company's back-end business
systems or ERP. This can be accomplished by using a custom program, an integrated proprietary "mapper" or to use an integrated
standards based graphical "mapper" using a standard data transformation language such as XSLT. The final step is to import the transformed file (or database) into the company's back-end
enterprise resource planning (ERP).
For an "outbound" document the process for integrated EDI is to export a file (or read a database) from a company's back-end
ERP, transform the file to the appropriate format for the translator. The translation software will then "validate" the EDI file
sent to ensure that it meets the standard agreed upon by the trading partners, convert the file into "EDI" format (adding in the
appropriate identifiers and control structures) and send the file to the trading partner (using the appropriate communications
protocol).
Another critical component of any EDI translation software is a complete "audit" of all the steps to move business documents
between trading partners. The audit ensures that any transaction (which in reality is a business document) can be tracked to
ensure that they are not lost. In case of a retailer sending a Purchase Order to a supplier, if the Purchase Order is "lost"
anywhere in the business process, the effect is devastating to both businesses. To the supplier, they do not fulfill the order as
they have not received it thereby losing business and damaging the business relationship with their retail client. For the
retailer, they have a stock outage and the effect is lost sales, reduced customer service and ultimately lower profits.
In EDI terminology "inbound" and "outbound" refer to the direction of transmission of an EDI document in relation to a
particular system, not the direction of merchandise, money or other things represented by the document. For example, an EDI
document that tells a warehouse to perform an outbound shipment is an inbound document in relation to the warehouse computer
system. It is an outbound document in relation to the manufacturer or dealer that transmitted the document.
Advantages of using EDI over paper systems
EDI and other similar technologies save a company money by providing an alternative to, or replacing information flows that
require a great deal of human interaction and materials such as paper documents, meetings, faxes, email, etc. Even when paper
documents are maintained in parallel with EDI exchange, e.g. printed shipping manifests, electronic exchange and the use of data
from that exchange reduces the handling costs of sorting, distributing, organizing, and searching paper documents. EDI and
similar technologies allow a company to take advantage of the benefits of storing and manipulating data electronically without
the cost of manual entry or scanning.
Barriers to implementation
There are a few barriers to adopting electronic data interchange. One of the most significant barriers is the accompanying
business process change. Existing business processes built around slow paper handling may not be suited for EDI and would require
changes to accommodate automated processing of business documents. For example, a business may receive the bulk of their goods by
1 or 2 day shipping and all of their invoices by mail. The existing process may therefore assume that goods are typically
received before the invoice. With EDI, the invoice will typically be sent when the goods ship and will therefore require a
process that handles large numbers of invoices whose corresponding goods have not yet been received.
Another significant barrier is the cost in time and money in the initial set-up. The preliminary expenses and time that arise
from the implementation, customization and training can be costly and therefore may discourage some businesses. The key is to
determine what method of integration is right for your company which will determine the cost of implementation. For a business
that only receives one P.O. per year from a client, fully integrated EDI may not make economic sense. In this case, businesses
may implement inexpensive "rip and read" solutions or use outsourced EDI solutions provided by EDI "Service Bureaus". For other
businesses, the implementation of an integrated EDI solution may be necessary as increase in trading volumes brought on by EDI
force them to re-implement their order processing business processes.
The key hindrance to a successful implementation of EDI is the perception many businesses have of the nature of EDI. Many view
EDI from the technical perspective that EDI is a data format; it would be more accurate to take the business view that EDI is a
system for exchanging business documents with external entities, and integrating the data from those documents into the company's
internal systems. Successful implementations of EDI take into account the effect externally generated information will have on
their internal systems and validate the business information received. For example, allowing a supplier to update a retailer's
Accounts Payables system without appropriate checks and balances would be a recipe for disaster. Businesses new to the
implementation of EDI should take pains to avoid such pitfalls.
Increased efficiency and cost savings drive the adoption of EDI for most trading partners. But even if a company would not
choose to use EDI on their own, pressures from larger trading partners (called hubs) often force smaller trading partners to use
EDI.
See also
External links
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
