
Electronic data interchange (EDI) is the structured
transmission of data between organizations by electronic means. It is
used to transfer electronic documents or business data from one computer
system to another computer system, i.e. from one trading partner to
another trading partner without human intervention.
It is more than mere e-mail; for instance, organizations might
replace bills of lading and even cheques
with appropriate EDI messages. It also refers specifically to a family
of standards.
In 1996, the National
Institute of Standards and Technology defined electronic data
interchange as "the computer-to-computer interchange of strictly
formatted messages that represent documents other than monetary
instruments. EDI implies a sequence of messages between two parties,
either of whom may serve as originator or recipient. The formatted data
representing the documents may be transmitted from originator to
recipient via telecommunications or physically transported on electronic
storage media." It distinguishes mere electronic communication or data
exchange, specifying that "in EDI, the usual processing of received
messages is by computer only. Human intervention in the processing of a
received message is typically intended only for error conditions, for
quality review, and for special situations. For example, the
transmission of binary or textual data is not EDI as defined here unless
the data are treated as one or more data elements of an EDI message and
are not normally intended for human interpretation as part of online
data processing."
EDI can be formally defined as the transfer of structured data, by
agreed message standards, from one computer system to another without
human intervention.
It can be argued that EDI got started when the first telegraph
messages were sent in the 1840s, which coincided with the beginning of
the "golden" era in US railway development. Railways were among the
first enterprises to use telegraphy, and by the 1870s it was used on a
large scale for railway operations management. In time each company
developed unique codes to minimize the number of Morse code characters
required per message, and also provide a degree of security against
their competitors' eavesdropping. The codes consisted of groups of 3 or 4
characters each assigned a specific meaning, which eliminated the need
for spelling out whole sentences. (A similar code, the radio amateur Q-code, is still in use today.) The US Civil War
and WWI saw the first use of message-based communications for the
management of troop movements and supplies, which reached their zenith
during WWII and enabled the development of large integrated logistics
and supply chains to support the concurrent war efforts in Europe and
the Pacific. Also during WWII, the invention of Frequency-Shift Keying
(FSK) teletype further increased the capacity and speed of data
transmission.
After WW II the computer emerged as a viable and effective business
tool. Interestingly, the early developers and adopters of purpose-built
business computers were not American but British companies. By the
mid-1960s computers were used for everything from accounting, to
point-of-sale, to inventory management. However, for practical purposes
business data communication by electronic means was still in the
telegraph age. Message-based digital communication systems were
aggressively being developed for military use, while in business data
was still conveyed via teletype, fax or courier and then manually
entered into incompatible data bases; a slow and tedious process with
significant opportunities for error. (This heritage is still reflected
in the EDI operations of today: data files exchanged between trade
partners are commonly referred to as a "mailbag".) Large US retailers
such as Macy's and Sears, who could afford the expense of owning and
operating the enormous computer systems of the time, started to develop
proprietary message-based EDI systems for supply chain management that
initially copied their existing paper-based forms and processes. This
further accentuated the problem of incompatible databases, and created
significant barriers to adoption for smaller and overseas suppliers. The
situation continued practically unchanged until the late 1980s when the
personal computer, together with the advent of "Software as a Service",
back-office integration and the adoption of international standards
made EDI the most effective way to exchange data between trading
partners. The advent of the Internet did not (as some authors had
predicted in the early 1990s) render EDI obsolete; to the contrary: by
abstracting the (physical) transport layer, developers could focus their
efforts on data translation and integration, which typically are the
strongest enablers to the client hence the highest value components of
the EDI solutions business.
[edit] Standards
EDI is considered to be a technical representation of a business
conversation between two entities, either internal or external. Note
that there is a perception that "EDI" constitutes 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. EDI is very useful in supply chain.
The EDI 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 synchronous), FTP, e-mail, HTTP, AS1, AS2, etc. It is important to differentiate between the
EDI documents and the methods for transmitting them. When they compared
the synchronous
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 12, 2005, an IETF working
group ratified RFC4130 for MIME-based
HTTP EDIINT (a.k.a. AS2) transfers, and is preparing a similar RFC for FTP transfers (a.k.a. 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) and quantities. Another example
is the set of messages between sellers and buyers, such as request for
quotation (RFQ), bid in response to RFQ, purchase order, purchase order
acknowledgment, shipping notice, receiving advice, invoice, and payment
advice. 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.
[edit] Specifications
Organizations that send or receive documents between 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.
[edit] 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[when?]
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".
[edit] Value-added networks
In the most basic form, a VAN (value-added network) 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 VANs also provide an advantage with certificate 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.
- Value Added Networks are the go-between in EDI communications.
- The VAN is responsible for routing, storing and delivering EDI
messages. They also provide delivery reports
- Depending on the VAN type, messages may need extra envelopes or may
be routed using intelligent *VANs which are able to read the EDI message
itself.
- VANs may be operated by various entities:
- telecom companies;
- industry group consortia;
- a large company interacting with its suppliers/vendors.
[edit] Internet/AS2
Until recently[when?],
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.[2]
AS2 (Applicability Statement 2) is the draft specification standard
by which vendor applications communicate EDI or other
business-to-business data (such as XML) over the Internet using HTTP, a
standard used by the World Wide Web. AS2 provides security for the
transport payload through digital signatures and data encryption, and
ensures reliable, non-repudiable delivery through the use of receipts.
[edit] EDI via the
Internet (Web EDI)
The Internet, as with VAN providers, uses its own communications
protocols to ensure that EDI documents are transmitted securely. The
most popular protocols are File Transfer Protocol Secure (FTPS), Hyper
Text Transfer Protocol Secure (HTTPS), and AS2.
The Internet has provided a means for any company, no matter how
small or where they are located in the world, to become part of a major
supply chain initiative hosted by a global retailer or manufacturing
company. Many companies around the world have shifted production of
labour intensive parts to low-cost, emerging regions such as Brazil,
Russia, India, China, and Eastern Europe. Web-based EDI, or webEDI,
allows a company to interact with its suppliers in these regions without
the worry of implementing a complex EDI infrastructure.
In its simplest form, webEDI enables small to medium-sized businesses
to receive, turn around, create and manage electronic documents using
just a web browser. This service seamlessly transforms your data into
EDI format and transmits it to your trading partner. Simple
pre-populated forms enable businesses to communicate and comply with
their trading partners' requirements using built-in business rules.
Using a friendly web-based interface, EDI transactions can be received,
edited and sent as easily as an email. You will also be able to receive
EDI documents and send EDI invoices and shipping documents with no
software to install. All you require is an Internet connection. WebEDI
has the added advantages that it is accessible anywhere in the world and
you do not need a dedicated IT person to manage any software
installation.
Even though VANs offer a very secure and reliable service to
companies wishing to trade electronically, the Internet is making EDI
more available to all. This is especially important in the emerging
markets where IT awareness and infrastructure are very limited. WebEDI
is traditionally based on the "hub and spoke'"model, with major trading
partners or Application Service Providers (ASPs) being the hubs and
smaller partners being the spokes.
- Hubs or ASPs implement EDI using email or virtual mailboxes
- Trading partners can send EDI messages directly to a web-enabled EDI
messaging site, via the hub. EDI messages are simply sent using a web
browser
- Systems that are currently being developed will enable EDI messages
to be displayed in a web browser and directed via open standard XML,
directly into the user's accounts system
- WebEDI-based users can interact with VANs without incurring the
costs of setting up a dedicated VAN connection
[edit] Interpreting data
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) system.
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.
[edit]
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, 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. Another advantage of
EDI is reduced errors, such as shipping and billing errors, because EDI
eliminates the need to rekey documents on the destination side. One very
important advantage of EDI over paper documents is the speed in which
the trading partner receives and incorporates the information into their
system thus greatly reducing cycle times. For this reason, EDI can be
an important component of just-in-time production systems.
According to the 2008 Aberdeen report "A Comparison of Supplier
Enablement around the World", only 34% of purchase orders are
transmitted electronically in North America. In EMEA, 36% of orders are
transmitted electronically and in APAC, 41% of orders are transmitted
electronically. They also report that the average paper requisition to
order costs a company $37.45 in North America, $42.90 in EMEA and $23.90 in APAC.
With an EDI requisition to order costs are reduced to $23.83 in North
America, $34.05 in EMEA and $14.78 in APAC.
[edit] 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 the 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 increases 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.