Electronic Data Interchange
Chapter-1
INTRODUCTION
In
the paper-based business environment, companies conduct their business
activities by exchanging paper documents. This is usually time-consuming and
costly when the volumes are large. The whole process of Document exchanges in a
paper-based business environment invites extensive manual processes (data entry
and re-entry), manual intervention, interpretation, and manipulation, resulting
in time delay, labor costs, and errors.
With
the emergence of computer networks it quickly became apparent to the business
community that business relevant events like purchase orders, invoices, and
payment advices can be sent electronically. This tremendously increases speed
and accuracy over traditional paper-based means. The increase in throughput was
highly beneficial to those businesses that have to process a high volume of
business messages.
As
a consequence electronic document standards first appeared in the 1970s with
SWIFT for electronic banking introduced in 1973, ANSI ASC X12 for general business
transactions in 1979, and EDIFACT in 1988. These standards define the structure
of business messages and the promise is that if businesses comply with those,
the transmission becomes efficient. To large extent this is true. Once the
transmission systems are set up, and the messages are created and consumed
properly, the transmission is efficient.
1.1 EDI as a
part of E-commerce:
E-commerce (electronic commerce or
EC) is the buying and selling of goods and services on the Internet, especially
the World Wide Web. In practice, this term and a newer term, e-business, are
often used interchangeably. For online retail selling, the term e-tailing is
sometimes used.
E-commerce
can be divided into:
·
E-tailing or "virtual storefronts" on Web sites with online
catalogs, sometimes gathered into a "virtual mall".
·
The gathering and use of demographic data through Web contacts.
·
Electronic Data Interchange (EDI), the business-to-business
exchange of data.
·
E-mail and fax and their use as media for reaching prospects and
established customers (for example, with newsletters).
·
Business-to-business buying and selling.
·
Chapter-2
What is EDI?
2.1 DEFINITION
The definition of EDI according to
the EDIFACT (Electronic Data Interchange For Administration, Commerce and
Transport) organization is as follows:
'EDI is the
electronic transfer between separated computer applications of commercial or
administrative transactions, using an agreed standard to structure the transaction
or message data.'
Further
elucidation of this definition is given below:
Electronic
transfer between separated computer applications:
The
data are initiated and produced by one computer application and sent to another
separated computer application, which interprets and processes the data. The
transfer of the data is accomplished by data communication techniques.
No
human interaction is involved in the whole process. Terminal to computer is not
regarded as EDI, although Personal Computers, on which applications can run,
are seen as computers.
Commercial or administrative transactions:
The data sent by EDI are mostly
concerning information of flows of orders and goods.
Using an
agreed standard to structure the transaction or message data:
The whole process of a business transaction is
divided into several messages. These messages are structured and standardized
so that they can be automatically processed by computers.
EDI is often used in combination with fax and electronic mail as
identical means of communication. This is not correct: EDI goes further in
respect to automation than electronic mail or fax.
The principal differences are:
·
Electronic mail and fax use unstructured messages. Automatic
processing is therefore not possible.
·
Electronic mail and fax support communication between persons, not
communication between computers.
Chapter-3
Technical components of EDI
3.1 Construct of standards for EDI
This
shows a business application linking to a message protocol which in turn is
linked to a communications protocol and hence to a communications
line. Working up from the communication line, the file transfer and
communications protocols takes a data file and transfer it via a communication
link and matching protocol to another file on a distant and probably different
machine.
The message protocol has to ensure the correct transfer of
information meaning from one end to the other. EDI specifies the formats of these
messages in terms of message subcomponents, which in turn have their formats specified.
The most basic message components are data elements, which can be filled with
elements of specified code sets, numbers, dates of specified formats, or in
some instances free text.
Components may be mandatory or optional, be allowed to repeat a
maximal number of times, and – for data elements – be expressed with a minimum
and maximum number of characters. Inter-component restrictions are also
specified.
There
are two major EDI standards, EDIFACT, defined as an open standard by the United
Nations, and X12, primarily used in the
The standards are broad enough to encode variations in message
requirements used by different industries. Industry bodies define subsets of
and modifications to the EDI standard for messages which they use. Individual
companies add further restrictions to the EDI messages which they send and
accept. These modifications are applied in order to adjust the standard
definition to specific needs of the companies.
3.2 Components
of EDI
EDI system
contains two major components:
·
EDI translation software that converts and maps EDI formats
to/from internal business applications.
·
Communication channels that deliver EDI documents to the desired
trading partners.
EDI
translation software basically converts the internal proprietary format to the
one that conforms to a standard acceptable to the trading partners; conversely,
it maps incoming standard formats into the proprietary formats recognized by
internal business applications. The functionality of translation software could
be obtained in three ways: lease or purchase software from a vendor; have a
third party (such as a VAN) perform the translation; or develop software in
house.
The
first two alternatives are usually the most cost- and time-effective as they
are easy to install, maintain, and expand. Business documents, once converted
by the translator, are ready to deliver via communication channels, as
described in chapter 4.
Chapter-4
Communication
Channels
Trading partners exchange EDI
documents via direct link, third-party VANs and internet (World Wide Web).
4.1 Direct
link networks
Direct link networks, including
leased lines, are the most straight-forward communication method. They allow a
company to dial up and connect directly to partners’ computers. They are most
cost-effective alternative for transmitting high volumes of data and are thus
very appealing to those large companies that must transmit huge amounts of data
daily. With direct link, each trading partner provides its own technical
support to address issues such as protocol and speed conversion, because
different computer systems use different communication protocols and
transmission speeds. In addition, companies must have phone lines available at
the same time, deal with substantial administrative overheads to ensure
reliable delivery, provide audit control and recovery procedures in case of
communication link failure or unavailability, and so on.
These issues are compounded when the number of direct linked
trading partners increases. As a result, direct link network is only applicable
to large companies that must transmit high volumes of data daily.
4.2
Value-Added Network
Value-Added Network plays an
intermediary role analogous to a post office or delivery service that provides
reliable delivery of documents in a secure environment. VANs provide the
following value added services to support EDI: mail boxing, protocol
conversion, standard conversion, reliability, security, administration,
implementation assistance, etc.
Value-Added
Network is a system where a network leases communication lines from a
communications common carrier, enhances them by adding improvements such as
error detection and/or faster response time, and then allows others to use this
service on those lines for a fee
Mailbox services were the initial business provided
by VANs, where incoming EDI documents from senders were stored in recipients’
mailboxes, from which they could be retrieved at any time, or delivered
directly into a recipient’s system if requested by the recipient. Building upon
mailbox services, a VAN supports administration functions such as audit and
control of exchanged documents, message tracking, reports, and billing
services. For those companies that do not have in-house EDI translation
software, a VAN offers in network translation services that convert formats between
different EDI standards (e.g., X12 and EDIFACT), between EDI formats and
proprietary formats, and between EDI formats and other media formats, namely
E-mail, FAX, Telex, and a hard copy.
4.2.1 VAN Benefits
Maintaining
a private network is a sizable task, requiring specialized equipment, software
and technical support. The VAN provides a very easy solution to EDI
communications needs.
Flexibility
A
major advantage of using a VAN is that you can be certain of being able to
communicate with the VAN using a wide variety of standard communication
protocols.
Cost
The
cost of using a VAN is relatively inexpensive. While billing methodologies
differ from one VAN to another, subscribers will typically pay per-transaction
charges, and a pro-rated charge based on data volume. VANs are somewhat more
expensive than postage, but a cost benefit analysis that considers reduced
handling costs and the cost-avoidance of alternate methods of communication
will lead you to conclude that the pricing of VAN services is reasonable and
cost-effective.
Security
A
VAN allows the user to send and receive information only to and from their own
electronic mailbox. The VAN handles all transfer of information from the
sender’s mailbox into the receiver’s mailbox. This allows trading partners to
be certain that they can freely exchange information but at the same time they
can avoid giving direct access to their own internal systems.
Maintenance
All
of the communications hardware and software is maintained by the VAN. A
business is only responsible for maintaining the communications equipment which
provides access to the VAN.
Accountability and Auditing
Networking
activity and costs can be tracked and quantified on a detailed basis. While
billing services vary, most VANs provide itemized breakdowns of charges in much
the manner as credit card companies provide similar services to their accounts.
User Services
VANs
may provide translation services in cases where such EDI software is
unavailable for your hardware platform. Many VANs provide consulting services
to help you plan and carry out EDI implementation in your business. The support
of experienced EDI VAN personnel for implementation and continuing operations
should not be minimized. Full service EDI and electronic commerce providers
provide extensive capabilities and support on a global basis for their
customers.
How EDI works?
5.1 The Building Blocks
First,
we will take a look at what composes an EDI document then we will describe how
a business can make use of the basic building blocks to send a document
electronically.
The challenge of
defining the electronic document is that it must be specific enough to be able
to serve the needs of any business without imposing unnecessary requirements.
Because it must be done by computer, there can be no ambiguity. Each required
piece of information requires explicit definition.
For example, if you are
sending an electronic purchase order, the paper document must be translated
into a specific standard formal (e.g. ANSI X12 or EDIFACT) for purchase orders.
This need to define everything down to the last period and comma leads to a
necessary amount of detail that may seem a bit bewildering on first glance.
An overview of what the
pieces are and how these pieces fit together should help eliminate some of the
mystery about what an EDI document actually is. We’ll begin by describing the
basic building block of all EDI messages—the Data Element. Then we’ll review
how these elements are combined into Segments, which in turn form Messages that
are transmitted in electronic Envelopes.
5.2 The Data Element
The basic building
blocks of an electronic document are data elements, which represent unitary
pieces of information. An address is not a data element, because it can be
broken down into several elements such as street address, city, state and
country.
Each of
these pieces of information cannot be further divided, and therefore represents
elements. A phone number is an example of data that can be further divided into
elements such as country code, area code, and local number.
The data element definition will describe:
- The type of data (numeric, alphanumeric, date, time).
- The minimum and maximum length allowed.
- Code or conditional values that must be observed with a
particular type of data.
Definition
of a data element for unit cost would allow you to stipulate the exact length
and number of decimal places. A currency code would allow you to indicate what
currency is being used in the unit cost field.
5.3 The Segment
If
you were filling out information on a purchase order, you would expect to see
groups of related data. The shipping address is one such logical group that is
composed of several elements. The address has meaning only when all required
elements are present. These elements, when taken together, represent a logical grouping
of information, and are referred to as a segment.
Segments are very
important in structuring an electronic message because they provide a way of
tying together related data elements. Segments also allow us to distinguish
between like data elements. If, as will frequently be the case, there are two
different addresses, each will have its own segment. Both segments will contain
identical data elements, but each will contain a code specifying what type of
address is contained in the segment.
For each type of
document, there is a standard definition of the data segments that can be used
to build the document, along with a dictionary of which data elements can be
used in each segment Data segments have been defined broadly enough that they
may serve the needs of many types of messages. A segment for vendor name may be
used not only in a purchase order, but also in an invoice, and a shipment
notification. In each different document, the segment will have different
information requirements.
The segment definition for a specific message
will identify:
- All mandatory data elements.
- Any optional or conditional data elements.
- The required sequence of data elements within the
segment.
- The maximum number of occurrences of the segment.
An
optional data element may not be required depending on other information
present. For example, while unit-of-measure would be mandatory, data elements
related to discounts might be optional. A currency type would be conditional
based upon the countries of the sender and receiver.
5.4 The
Message
When all the segments
are collected together into a prescribed sequence they form a complete electronic
document. This electronic document is referred to as a message, or transaction
set. A complete message is the equivalent of one business document, such as a
purchase order, invoice, or advance shipping notice.
For each message,
complete documentation is available to define specifically what information is
required.
The definition of a message will include:
- Which segments may be used in the message.
- The required sequence of the segments.
- Which segments are mandatory and which are optional
- How many times a segment may be repeated.
- Specific rules for repeating, looping and usage.
5.5 The Envelope
Paper business documents
are sent in envelopes and it is possible to mail many documents in a single
envelope. It is no different with electronic documents. EDI incorporates
several levels of envelopes, in order to insure that each document is correctly
identified, and that only like documents are grouped together.
The electronic envelope
will actually be composed of two parts: a “header” placed at the beginning of a
series of related records, and a “trailer” that will follow that last of the
records.
There are three standard types of electronic
envelopes.
- Message Envelopes.
- Functional Group Envelope
- Interchange Envelope
·
Message
envelopes define the
start and end of a specific document, and will describe the type of document,
and the number of segments included in that document.
·
Functional
Group envelopes are used to
enclose all message envelopes of a specific transaction set type. So all
purchase orders will be included in one functional group, and all invoices will
be included in a second functional group.
·
Interchange
envelopes enclose all functional
group envelopes being sent to the same destination. The interchange envelope
contains the identity and electronic mailbox address of the sender and the
receiver, control information, and counts of transactions.
5.6 Documents and Envelopes
Envelope Levels:
1st: Transaction Set (ST/SE)
2nd: Functional Group (GS/GE)
3rd: Interchange (ISA/IEA)
5.6.1 Transaction Set Envelopes
The
innermost level is the Transaction Set identified by the ST/SE segments. The ST
segment always has two data elements.
They are:
·
Transaction Set ID
(Purchase Order, Invoice, Functional Acknowledgement)
·
Control Number (e.g.,
1001)
The SE segment contains the Number
of Included Segments in the transaction set and the same Control Number as the
ST segment.
5.6.2 Functional Group Envelopes
The
second (middle) level of enveloping is the FUNCTIONAL GROUP Envelope. Its
purpose is to group similar types of Transaction Sets within a transmission. The Functional Group Envelope is defined by the
GS/GE segments.
The GS segment has a number of data elements.
Examples of some are:
- Functional
Group Set ID (Purchase Order, Notice/Manifest, Functional Ack)
- Format
and Version of the document, and Date/Time Stamp Numbers
5.6.3 Interchange Envelopes
The outermost level is
the INTERCHANGE envelope that is defined by ISA and IEA segments. The
Interchange envelope encloses the data from one sender to one receiver. The ISA
is a fixed length segment.
Some items contained in the ISA/IEA segments
are:
- Structured mailbox addresses of the sender and receiver
- Interchange control numbers
- Counts of the functional groups within the interchange
- Time/Date stamp (similar to functional group, but does
not include the century)
- Version of the interchange envelope
- Characters in the ISA segment used for data element
separators, sub-element separators, and segment terminators
5.7 The
Basic Steps of EDI
The process of sending an electronic
document requires a series of steps on the part of the sending and receiving
partners. Once you have defined all of the building blocks of your EDI message,
most of these steps will either be automated or proceduralized.
5.7.1 Steps the Sender Must Take
The
sender of any EDI document must generally take three steps. First, the
information for the electronic document must be prepared. Then the document
must be translated into a standard format. Finally, the document must be
transmitted to the receiver.
5.7.2 Document Preparation
The first step in any
sequence of Electronic Data Interchange is the collection and organization of
data. For example, instead of printing a purchase order, the system creates an
electronic file with the necessary information to build an electronic document.
The sources of data and the methods available to generate the electronic
documents are as varied as there are businesses and applications.
They can include:
- Human
data entry via screens.
- Transcribing
data into a software translation product.
5.7.3 Outbound
Translation
The next step is to
translate this electronic file into a standard format using the appropriate
segments and data elements. Specialized “translation” software “maps” the data
from the electronic purchase order file into the message format required by the
purchase order message. Translation software is available to suit just about
any computing environment and budget, from large mainframe systems that handle
thousands of transactions daily to PC packages that need only process a few
hundred transactions a week.
5.7.4 Outbound
Communication
The sender’s computer
will connect to a Value Added Network, or VAN. The file is transmitted to the
electronic version of an “out” box. Upon successful receipt, the VAN will
process and route the transaction to the electronic mailbox of the receiver.
5.7.5 Steps the Receiver Must Take
The receiver of the EDI
document must take these same three steps, in reverse order. The first step is
to retrieve the document from the sender. Then the document must be translated
from the standard format into data that the receiver’s systems can use.
Finally, the translated file is applied to the receiver’s application database.
5.7.6 Inbound
Communication
The receiver’s computer
connects with the VAN and receives any files waiting in its electronic “in”
box. The computer stores the file where it will be accessible to the receiver’s
translation software.
5.7.7 Inbound
Translation
The receiver’s
translation software will reverse the process that the sender went through by
“mapping” or translating the file from the standard PO message format into a
format that the receiver’s internal system can understand. This process will
strip out any data in the file used for routing or control purposes.
5.7.8 Processing
Electronic Documents
The receiver’s internal
customer order processing system processes the newly received and translated
purchase orders. As with document preparation, a variety of options for
processing the translated file are available. A significant addition to the
transfer of an electronic document is the confirmation. When the transaction is
successfully processed by the receiver a functional acknowledgment is sent to
advise the sender that the file has been successfully received.
Chapter-6
EDI SECURITY
The
major threats that have been identified for EDI primarily relate to message
security for an 'end to end' transmission between trading partners. This concept
of ‘end to end' security is very important as it enables the ultimate recipient
of a message to have confidence that it was sent from the stated originator
without modification, even though it may have been handled by third parties
during transmission.
The key
threats to security are as follows:
·
Masquerade - Is the originator whom he claims to be.
·
Modification - Has the message been tampered with in transit?
·
Repudiation - Can the message only have been sent by the
originator?
·
Replay - Have duplicate
messages been transmitted.
·
Leakage - Has third party extracted information en route.
The major threat,
in the above list, is that of message leakage. This is where the third parties can eavesdrop on messages
for the information content within them. Encryption of the ED1 messages will
prevent most message leakage as the message cannot be read by a third party.
However, even
encrypted messages offer some leakage of information - the knowledge that
messages are being exchanged between specific trading partners even if the
content cannot be read. However
in normal trading relationships this
should not be a problem.
The previous
proposals for EDI message security define a security architecture that is
suitable for any EDIFACT message and any security algorithm, symmetric or
asymmetric. A standard EDIFACT message comprises an INTERCHANGE header and
trailer. Within that are optional FUNCTIONAL GROUP headers and trailers. Within
those are individual MESSAGE headers and trailers with the message content
(segments and data-elements) embedded between them.
The security
architecture adds a set of optional security headers and trailers at each
level. Security can therefore be implemented by adding signatures at message
level and or functional group level and or interchange group level. This
defined architecture will be supplemented by suitable control messages to act
as security, functional and application acknowledgements between the originator
and recipients of the message
Chapter-7
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.
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 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. 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.
Chapter-8
CONCLUSION
It
has taken 20 years for ED1 to begin to become an accepted way of doing
business. Change will not remain at this leisurely pace - the forces identified
earlier will lead to an explosive growth in the number of users, use and new
technology.
Technical compatibility among EDI
systems is essential in order to maximize the network externality benefits.
Therefore, solving the problems of EDI standardization is important to speed up
the process of EDI diffusion and EDI external integration in a supply chain or
an industry.
Reference
- Mr. Coen
M.A. Kreuwels, ‘Electronic
data interchange’, 1990. 'Next Decade in Information Technology',
Proceedings of the 5th
- Shiwa
Fu, Jen-Yao Chung, Walter Dietrich, Vibby Gottemukkala, Mitchell Cohen, and Shyhkwei Chen, “A Practical Approach to
Web-Based Internet EDI”, 19th IEEE International Conference on Distributed Computing Systems Workshops on31May – 4 June 1999 Page(s):53-58
.
- B. K. Blacker, “The development of an EDI
system”, IEEE Computing & Control Engineering Journal
, Volume 2, Issue 5, Sept.
1991 Page(s):231 - 237
- John Cobb, Security Implications for EDI -
Standards and Practices in Electronic
Data Interchange, IEE Colloquium, 2004
- www.ieee.org
- http://ieeexplore.ieee.org/iel2/307/3595/00128288.pdf?tp=&arnumber=128288&isnumber=3595
- http://ieeexplore.ieee.org/iel2/307/3595/00128288.pdf?tp=&arnumber=128288&isnumber=3595
- http://ieeexplore.ieee.org/iel5/6309/16867/00776414.pdf?tp=&arnumber=776414&isnumber=16867
- www.edibasics.co.uk
- www.covalentworks.com
Comments
Post a Comment