ASSIGNMENT-II

TOPIC- EDI ARCHITECTURE, PURPOSE AND ITS USES

SUBMITTED BY,

Jyothi.T [11079E093]

IV yr, B.Tech[IT]
ABSTRACT:

Electronic Commerce is the movement of everything involving business to the Internet and the
World Wide Web. Just as the term implies, it is commerce done electronically. Parties involved
in a transaction interact electronically in a way similar to businesses using Electronic Data
Interchange (EDI) concept.

INTRODUCTION:
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.

 CONTENT:

Electronic Data Interchange (EDI) what is it? EDI is the exchange of business data, in an agreed-
upon format, between the computer systems of two or more companies that agreed to exchange
this information. There are four major thoughts here:
1.      “The exchange of data” – this means the data itself, not an image of the data.
2.      “Between the computer systems” – this implies minimal if any human intervention.
3.      “In an agreed-upon format” – the use of some standard that the companies can recognize.
4.      “Between companies that have agreed to exchange this information” – there is some
agreement in place that shows prior discussion, knowledge and commitment to exchange this
information.
What is not defined is what technology will be used to exchange the data. This allows for
changes in technology to be used with changing the entire concept.

EDI ARCHITECTURE:

EDI is implemented through a hub and spoke configuration.  The main EDI site (hub)
interconnects their selected business data with that of their business partners (spokes).  This
relationship provides the partners with direct access to each other’s operations data that is
maintained within a system connected to the EDI network.  These electronic alliances can
provide incredible strategic advantage to participating partners.  For example, EDI can notify a
supplier that one of their customer’s primary production lines has broken, which in-turn will
affect the amount of product required from the supplier.  The level of EDI integration between
participants depends on the participant’s objectives.  Some companies implement EDI to secure
market position while others implement EDI to improve internal operating
procedures.  Generally, companies find greater return on investment with more, rather than less,
EDI implementation.  For example, Texas Instruments (TI) found very limited pay back from its
EDI program initially, but the return on investment (ROI) took off as TI’s processes began to
work together. TI’s large-scale integration included procurement, marketing,
telecommunications, accounts payable and receivable, quality, treasury, benefits, payroll, and
management information systems.  Bringing all these functions together brought TI a
considerable ROI.

Electronic Data Interchange (EDI) in a “middleware” context. Middleware integrates data

among different applications. Since EDI involves exchanging data between in-house applications
and applications at other companies, comprehensive middleware architecture often includes it.
 
Yet while EDI might be considered “middleware”, it also shares characteristics with applications
in their own right. Although it lies between applications like other middleware, the applications
to one side of it do not belong to your company! The whole point of EDI is to enable your
company to communicate with other applications that are:
 
1. Always on the distal end of some long-distance link, and
2. Always “black boxes” from the viewpoint of your own network and applications.
 
The whole point of EDI is to make data exchange possible with applications whose nature you
cannot know, and whose behavior you cannot control. This makes EDI a special case of
middleware, one better treated as an application (a suite of applications) unto itself.

 
THE EDI DOMAIN
 
EDI is like a set of nested boxes with the X12 document representation protocol in the center of
it. Surrounding this are the mechanisms needed to exchange data over various public and private
networks. Some large companies relegate to their EDI departments only those data exchanges
that involve X12 conversions, giving over any other data exchange (for example the use of
proprietary formats) to a different department. The communication protocols used to exchange
data (versions of ftp, http, sockets, etc) may be under the control of yet a third department. This
arrangement makes for a cumbersome architecture involving two or three departments in any
new trading partner relationship.
 
The operations of a “data communications” department can be viewed both functionally, from
the viewpoint of the ISO 7 layer network model, and structurally towards the rest of a
company. EDI traditionally occupies layers 5 and 6. Layer 5 comprises its workflow, encryption
(at the document layer), and auditing functions. Layer 6 encompasses format translation and
sometimes data type transformation (e.g. ASCII to EBCDIC) features. At the same time, a robust
EDI department must also have a say in what goes into and on in layer 4. First because its
workflow uses the layer 4 utilities. Second, in fulfilling the business’s needs for trading, the EDI
department must have its choice of layer 4 protocols. Encryption choices also exist at layer 4 and
should be at the disposal of data communications. A robust EDI department should not have to
say to the business side of the company “we can’t connect to partner X because we don’t support
the connection types the partner has available.”
 
 The EDI department is special because it is the only department in your company that talks
direct to another company’s systems! This is a great privilege, and a great responsibility. The
“good citizen” of the data communications universe will send only properly formatted and
packaged data, perform timely acknowledgments of the data of other’s, and always be able to
receive proper data from external partners over agreed-upon channels. Only a department
isolated from the affects of changes to all other applications can assure the corporation of this
ability. That is the reason for isolation.
 
Facing the trading partners directly are the protocols of the ISO model’s layer 4. These are the
various mechanisms which guarantee that the data which leaves the boundaries of one
corporation arrives at the gates of the other without changing in any particular. While some
network’s do transform data, for our purposes, those networks are a part of the trading partner
since they do in fact represent other system’s whose data format requirements must be respected.
By contrast, non-transforming networks, while they are technically “another company’s
systems”, are effectively transparent to the two companies trading, and the data arrives as it left!
Note that e-mail, normally considered a layer 7 application, behaves in this EDI context as a
transport layer. EDI applications use e-mail protocols to carry data!
 
Security choices available at layer 4 should also be at the disposal of the EDI department. These
include secure ftp, secure sockets, secure http, and others. Security at this layer applies to the
channels through which data flows, though documents themselves are not encrypted. This is a
low-level of security that is convenient for the governing session layer to use and often obviates
other higher-level encryption.
 
The ISO “session layer” matches roughly to EDI’s workflow and auditing functions. Non-EDI
applications in the rest of the corporation use EDI to exchange data with other company’s
applications. Since the communication takes place between EDI departments (or their
equivalents), it follows that the EDI department gates the exchange in both directions. The
session layer is also responsible for any encryption or decryption between documents themselves
as distinct from the protocols used to send them (layer 4). Though individual document
encryption is independent of the protocol used for network exchange, session layer encryption
takes place on the EDI side of the data boundary, transparently to applications, which continue to
create, and consume, unencrypted documents.  Auditing is also a role of the session layer,
sometimes with the presentation (translation) layer. Auditing often amounts to saving work –
pre- translated and post-translated data, checking acknowledgments against sent documents,
producing acknowledgments for received documents, and making retransmissions (as needed by
trading partners) convenient.
 
The session layer implementation takes a wide variety of forms from shell scripts to built-in (to
EDI software) workflow management, to elaborate work-flow packages often referred to as
middleware. While each of these approaches has its merits, consider them in context of the
corporation’s other integration requirements and the structure of the EDI department.
Middleware packages (for example) usually violate the principle of EDI isolation from other IT
departments.
 
The ISO’s “presentation layer” matches EDI’s translation features. The whole point of X12
EDI was to standardize the format of documents exchanged between corporations.
Standardization allows each corporation to use what EDI applications it wishes provided only
that they read and write the standardized documents. Translation is the heart of EDI!  Even apart
from X12, documents must still be translated into and out of any proprietary format agreed on by
the trading partners. As with layer 4 communications, execution and timing of translations is
under the control of the EDI department’s session layer workflow. Implementing translators
takes many forms from rich scripting or other languages to elaborate translation packages.
Packages usually contain their own workflow, but using them it isn’t usually required. Unlike
workflows and audits, which can be self-produced relatively easily, translations can be a time-
consuming development process. Translation packages are frequently a good choice if there are
many standardized (X12 or the emerging XML) documents to exchange. Translators, do not
violate the principle of EDI isolation. Most of them are file-oriented (they take data from, and
leave results in, files), conveniently supporting isolation from other IT applications.
 

THE DATA BOUNDARY LAYER

 
The data boundary is the secret to the EDI department’s capacity to carry out its mission
independent of and insulated from changes in the rest of the corporation’s applications. It also
gives it the freedom to change itself, upgrading specific applications for example, without
affecting the rest of the corporation. All intercourse between EDI and the rest of the corporation
takes place via the exchange of data in this layer (despite a narrow “command channel”
discussed briefly below).
 
At its simplest the data boundary is nothing but files, one for each transaction between a
corporate application and some application at a single trading partner site. EDI and each of the
departments sending or receiving data pre-agrees to names, and formats of data exchanged
between them. File management can be manual, or using some file-management product like
Sterling Commerce’s “Connect Mailbox”, which provides built in logging and auditing support.
Departments put conventionalized files in the data boundary, and EDI translates and sends them
to trading partners. EDI places data received from partners as files in the boundary layer, and
other department’s applications consume them.
 
Files are only one approach to a data boundary. Another approach might be to tokenize
application data as XML, and put the tokenized data, and aggregations of tokens, in the data
boundary, possibly as records in a database. Every element in all the databases of the corporation
(at least all those exchanged with trading partners) might be given a standard XML
representation. Various collections of these tokens are also given XML representations. A
collection might represent an order, a claim, and loan, etc. Instances of tokens stored in a
database with keys, allow EDI to aggregate the individual tokens and convert them for
transmission! Alternatively applications can aggregate individual tokens into collections, and
hand these to EDI via database records, file managers, or files. On the reverse trip, EDI can
translate trading partner documents into collections of tokens consumable by applications. There
are many ways to design the data boundary to suit a corporation’s needs.
 
However one sets up the data boundary, polling discovers new data. Applications poll for new
data to consume, while EDI polls for data to send from the corporation to partners. Although the
EDI department can be insulated from the rest of the corporation by its data boundary, there are
sometimes applications that demand performance (even in remote data trading) that even fast file
or database polls will not satisfy.  Therefore, a narrow “command channel,” a small hole in the
data boundary, is also permissible between IT applications and EDI applications. Applications
are, of course, constrained to proper use of the channel. Applications leave data in the data
boundary, but they use the command channel to trigger an EDI action and pass it a pointer to the
data. In this way, EDI reacts more or less instantly to the presence of new data and does not have
to wait on its polling to signal something to be done.  The same can be done in reverse for data
received.

ROBUST EDI
 
 Although, the “presentation layer” lies between the “session” and “application” layers, from a
functional perspective, “presentation” is sandwiched between two “session layers” (workflows),
which control it.
 
Notice the figure shows two translation engines. Any medium to large sized company will have
translations that are proprietary as well as those that are standards-driven. Both types of
translations can be scheduled within a single workflow context. However it is often more
efficient to have third-party packages perform the standards-based translations, while relatively
simple scripts perform the proprietary translations. It’s tempting to let the workflow features of a
standards-based translator handle movement of data into and out of proprietary translators.
Translator software, however, is not often able, to manage conveniently, data it doesn’t translate.
By contrast, it should always possible to write workflows that pass data into and out of
standards-based translators. Middleware-centric EDI software often makes this otherwise simple
task more difficult than it should be. Modern software should make complex work easier, and
not complicate what used to be simple work! Today’s business computing environments,
whether Unix, Linux Windows, AS400/OS or other operating systems all have rich scripting
languages in which work-flow and auditing features are written fairly easily. Besides writing
such flows, managing them is straightforward given modern WEB-based end user interactions.
Writing WEB-based support for reporting from, and management of, modern scripts is almost
trivial in today’s technological environments.
 
At the partner-facing end of the translation, an EDI department should strive for maximum
flexibility in communicating with the transport level mechanisms available to it. Once again, this
usually means bypassing the package-based workflow features and writing your own to insure
that every transport can interoperate with each translation system in an identical fashion. The
same is true at the corporate-facing end where EDI meets the data boundary. Most EDI packages
can interact adequately with simple file-based data boundaries. Usually some intervening
(proprietary) workflows will have to be written implementing a more sophisticated data
boundary. If you have to write some of it, it is only a small step to writing the rest, assuring
consistency throughout.
 
EDI is a critical ingredient of modern global commerce. An EDI department isolated from other
corporate computer applications by a data boundary, and properly layered, insures maximum
flexibility and reliability. Data exchange with other companies takes many forms, from the
format of the data itself, to the protocols used to exchange it, and the networks over which it
travels. There is no reason a single EDI department cannot be a central hub controlling and
auditing all data exchange into and out of even reasonably large companies. Consolidating data
communications in this way insures consistency from both technical and business viewpoints.

EDI SOFTWARE
EDI standards are directed at the exchange of information among EDI participants; it does not
address end-use of the data, which leaves almost any application candidate for inclusion in a
company’s EDI implementation. However, because of EDI’s open nature, transaction sets must
usually be translated into EDI format by the sender and then translated from the EDI format into
the receiving application’s format.  Mapping data to and from disparate applications may be
difficult to achieve but once in-place, proper data mapping enables free-flow of information
between the applications.  It is this free-flowing data between EDI participants that allows them
to exploit EDI to their advantage.
EDI HARDWARE
EDI systems are written to operate on almost any computer.  There are EDI applications for PCs,
Macs, UNIX machines, and mainframes.  Hardware selection, however, can determine how EDI
integrates with, complements, or impedes current and future operations.

Traditional EDI Data Communication Methods

Dependable and reliable transmission of data is essential for effective EDI
implementation.  Traditionally, most businesses utilized value-added networks (VANs) to
support their EDI communication needs.  In addition to providing secure transmission of EDI
information, VANs act as a sort of EDI “postal system” by storing and forwarding messages for
their clients.  VANs are useful to both hub and spoke companies because they provide an
essential communications link without the expense of maintaining an EDI network.  VANs,
however, charge for their services on a pay-as-you-go basis, which can become quite expensive
for heavy users of EDI.  In addition, trading partners may wish to utilize different VANs which
could incur added translation expenses between VANs or perhaps, even EDI implementation
failure if competing VANs will not carry each other’s EDI traffic.

EDI 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
bisynchronous), 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 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 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 code)
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.

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.

PURPOSE OF EDI:

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 (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 protected healthcare information.

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

 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.

Internet/AS2
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 (Wal-Mart
EDI Requirement).

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.
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.

PROOF:

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
consumers 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) 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 lowers 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 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.

Barriers of 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.
CONCLUSION:

EDI states that electronic data interchange is a computer-to-computer electronic communication

method whereby trading partners in two or more organizations exchange business
transactions. The transactions consist of documents in structured formats that can be processed
by the recipient’s computer application software.  On the surface, EDI appears to be relatively
easy to achieve, but upon further study, one quickly comes to the conclusion that EDI is much
more than it first appears.