EDI Tutorial
1) What is EDI?
EDI is an abbreviation for Electronic Data Interchange,
which is the sending and receiving of business documents
via an electronic network between companies. These networks
can be based on the Internet or private networks, so
called Value Added Networks for EDI (VANs).
A central concept of EDI is that the
business documents that are exchanged must be machine-readable.
This means that a computer must be able to interpret
the EDI data that is sent or received. To accomplish
this, two factors must be present:
a) a standard for how the EDI data should be structured
per business document; and
b) a data parser to interpret the EDI data
There are two major, and several minor (industry specific
or geographic) EDI standards. The UN EDI standard EDIFACT
developed by the United Nations to be the basis of international
trade. It is used in Europe and most of the world. The
other significant standard is ANSI X12, developed by
the American Standards Council. This is used mostly in
North America. In addition to these two, there is the
ODETTE EDI standard that is used mostly within the automotive
industry in Europe. The TradaComs EDI standard
is mostly used in Britain and began in 1982.
The EDI data parser or EDI interpreter is a software
tool that uses data transmitted over a network and makes
it understandable for a machine or humans. This tool
can, for example, take data transmitted as an EDI message
and transform it into a purchase order that a person
can look at. This requires data transformation, which
is necessary if the data is to be read by an accounting
system or an individual.
The networks that the data travels through can be either
private networks for EDI, called VANs (Value
Added Networks) or it can be transmitted over the Internet.
To send EDI data over the Internet many companies use
FTP (File Transfer Protocol), FTPS (Secure File Transfer
Protocol) or AS2/AS3 (Applicability Statement 2 or 3).
Sending EDI data over the Internet is by far the most
inexpensive since VAN charges can become onerous over
time. Wal-Mart was the fist company to utilize AS2 communications
in a major manner for the transmission of EDI messages.
To summarize, Electronic Data Interchange or EDI is
a standard for enabling businesses to transact their
business electronically, rather than by fax, telephone
or email. EDI is primarily used in fixed trading relationships,
where the partners will be doing business for some time.
EDI came about because it was necessary for businesses
to become more efficient, and to do this, business transactions
needed to become automated.
2) Why do I need to do EDI and what are the benefits?
Most companies start using EDI software to transact
business because a larger and more powerful trading partner
that requires EDI as a prerequisite of the business relationship
mandates them to do so. Some companies begin using EDI
to make their business processes more efficient, though
these are in the minority.
As mentioned above, there are two major reasons to use
EDI. Firstly, because companies are forced to use EDI
software, and secondly because enterprises see that implementing
EDI can improve their business processes and make their
operations more efficient.
If you are like most companies who start using EDI because
of a larger trading partner, keep in mind that the reason
they want you to use EDI software is because transacting
business using EDI saves them time and money. The question
is, will EDI save you time and money, or is sending and
receiving business data via EDI just another pain you
have to endure to maintain the business relationship?
In the first phase of EDI adoption, few companies see
the concrete value of doing EDI as it actually may increase
the complexity of their business processes. This however,
is because most companies that begin using EDI utilize
EDI software that requires manual input. When the company
takes the next step and integrates their EDI data directly
with their accounting or ERP system the inherent potential
of utilizing EDI will become apparent. This removes the
necessity for manual entry of data between the EDI software
system and other computer applications that need the
data. Since manual processes are removed, errors due
to manual entry in the EDI process will also disappear.
This leads to cleaner data, faster turnaround times,
fewer fines from the trading partner and improved cash
management.
Some companies start utilizing EDI because the above
benefits are apparent to them. In these cases the company
is often a little larger. Since EMANIO has developed
new technology to cost-effectively facilitate the integration
of EDI data into a company’s backend systems, there
is no longer any reason for a company to utilize manual
processes when transacting EDI. Using integrated EDI
software is now easier than using manual EDI software.
Essentially, you need to use EDI to become more efficient
in your trading relationships. While some of your trading
partners may mandate that you use EDI software to do
business with them, this should not be the primary reason
to consider using EDI. The benefits to you in terms of
cash and operational management are significant. As mentioned
before, cleaner data, faster turnaround times and improved
relationships with your customers or suppliers will be
the result of implementing EDI in your organization.
3) What do I need to do EDI?
To be able to do EDI a company must acquire a few vital
components; EDI software, a method of communication over
an electronic network, and the trading partner’s
specific information of how they need the EDI to be sent
to them. We will explain each of these necessary EDI
components in detail below.
A. EDI Software: this is primarily an EDI parser or
translator that functions as an interface between the
EDI document that is sent/received and the person entering
the data manually into the internal accounting or ERP
system. EDI software can often interface directly with
internal systems using a process called EDI integration.
When an EDI message is received, it first comes into
the EDI software from the network of choice (FTP, AS2
or VAN). The EDI software then validates the message,
meaning that it checks whether 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 and segments of data conform
to the agreed upon standards. After the validation, the EDI
software creates a file (of fixed or variable length,
sometimes in XML tagged format). For environments that
don’t have EDI integration the
received EDI message is printed and manually entered
into the accounting or ERP system. For environments where
the EDI is integrated, the EDI software converts the
EDI file into the proper data format that allows the
EDI data to be automatically imported into the accounting
or ERP system. The EDI document is then imported.
When an outbound EDI message is created in an integrated
environment, a file is exported from the accounting/ERP
system that is converted to the file format the EDI software
uses. The process is the reverse of the one described
for an inbound EDI document. The file is validated to
ensure compliance to trading partner standards and transformed
into the EDI format by adding appropriate identifiers,
qualifiers and control structures. The EDI file is then
sent to the trading partner via a VAN or other communications
protocol.
Since an EDI document is a legal business transaction,
there is need for an audit trail to ensure tracking and
history. An audit trail is essential in the trading partner
relationship as the sending/receiving of EDI messages
will have strong economic implications and affect cash
flow, warehousing, stocking, shipments, etc.
When we use “inbound” or “outbound” in
relation to EDI documents, we mean how the document travels
with respect to the EDI software, which may be different
from the flow of products or money. An EDI document requesting
payment (invoice) is an inbound document in relation
to the company that is going to pay, but an outbound
document from the company requesting payment.
- EDI network communication (AS2/AS3, FTP/S and
VANs): An EDI document is a business document that
transmits vital information for the operation of
the enterprises involved. As a result, it is important
that the information in the EDI message is transmitted
quickly, accurately and securely. To accomplish this,
there are several modes of communication that have
been developed to ensure that EDI information is
transmitted securely. First among these are the EDI
VANs or Value Added Networks for communication. These
were developed as hosted services and are “go-betweens” between
the EDI trading partners. EDI VANs transmit all kinds
of EDI messages, including those formatted as XML,
and often perform value added services such as data
conversion between EDI and another format. For many
small and mid-sized businesses, EDI VANs have proven
prohibitively expensive, and many large and trend-setting
companies, such as Wal-Mart, have chosen to move
away from EDI VANs in favor of Internet-based EDI
communications. The protocols that are used for Internet-based
EDI communications are FTP, FTPS and AS2/AS3. Using
Internet-based EDI communication is significantly
more cost efficient than using EDI VANs.
Internet-based EDI communication is also called Internet
EDI. What is most often meant by Internet
EDI is simply the protocols used to enable EDI
messages to be transmitted via the Internet rather
than via an EDI VAN. Most EDI trading partners require
their EDI messages to be transmitted via the Internet
securely. To do secure Internet
EDI communications, several methods have been devised,
most recently the AS2 and AS3 protocols. Applicability
Statement 2 (AS2) and Applicability Statement 3 (AS3)
have been developed specifically for this purpose.
AS2 specifies how to connect, deliver, validate and
acknowledge data. AS2 creates an envelope for an EDI
message which is then sent securely over the Internet.
Security is achieved by using digital certificates
and encryption.
C. Partner Specific EDI Standards: All EDI communication
is based on standards developed by bodies such as the
American National Standards Institute or the United Nations
EDIFACT body. These EDI standards are both thorough and
have taken years to develop. Each major EDI trading partner
that desires their suppliers or customers to transact
with them electronically, use these standards to create
their own specific customizations. This means that every
major EDI trading partner has their own “flavor” of
the EDI standard they are using. As a consequence, even
if you know which EDI standard and version a trading
partner is using, it will need to be customized for that
particular trading partner. Normally the trading partner
will provide an EDI Implementation Guide that clarifies
the particular customizations that have to be adhered
to, beyond the EDI standard and version. When starting
a relationship with a new EDI trading partner, you must
ensure that your EDI vendor or consultant has created
these customizations or has the expertise to do so.
4) How do I get my EDI orders into my ERP or accounting
system?
EDI integration is the process of importing and exporting
data between the EDI solution and
the backend systems like accounting and ERP. EDI integration
often comes as a secondary phase of implementing EDI
software – in the first phase a company generally
commences with EDI transactions by
handling them manually.
When a company decides to integrate EDI, it is because
it has become clear that the business processes of the
company can become significantly more efficient. By integrating
EDI, companies ensure that the errors due to manual entry
of data between accounting and ERP systems on the one
hand, and the EDI solution on the other, is minimized.
In addition, the EDI activities are no longer characterized
by double data entry and the high costs in personnel
required when a company start doing a higher volume of EDI
transactions.
Within EDI integration there are several ways to manage
the actual data integration. In the US many companies
use flat file based integration, while in Europe it is
more common to integrate the EDI directly via databases.
In recent years it’s also becoming common to utilize
XML for integrating EDI into backend systems. Regardless
of the data integration method, EDI integration follows
a few basic steps:
- exporting the EDI data
- transforming the EDI data into an intermediary format
that the backend accounting or ERP system requires
- importing the formatted EDI data into the backend
system
The above process requires significant knowledge of
both the EDI software system and the backend ERP or accounting
system. The level of detail required extends to knowledge
of the location and meaning of individual fields in the
data tables within the backend system. As a consequence,
most small or mid-sized businesses have difficulty performing
EDI integration wholly on their own.
Your EDI vendor, or accredited consultants, can easily
perform the EDI integration for your company. In fact,
the more advanced EDI vendors will have pre-configured
integrations between your backend system and the EDI
software. That means that most of the “heavy lifting” in
EDI integration will already have been done by your vendor.
EMANIO has developed the easiest EDI integration offering
in the market, where all the accounting systems and ERP
software have been pre-configured for EDI integration.
This has resulted in an implementation time of about
2 hours for something that used to take weeks or months.
The two most common forms of EDI integration are:
- Self-managed integration where the company desiring
EDI integration will purchase software (and often
consulting services) to accomplish this. It generally
takes a significant amount of time in planning and
execution. This type of EDI integration often costs
$40,000 or more, depending on the complexity of the
integration.
- EMANIO’s form of EDI integration where the
backend system and trading partner configurations have
been pre-mapped to create an EDI integration solution
that requires minimal consulting or management by the
customer. This type of integration typically costs
from $3,000 and up.
5) What should I look for in a good EDI solution?
The question of what is a good EDI solution is very
dependent on knowing what your needs are. In a general
sense, a good EDI solution should be intuitive to use
and easy to install. This means that the EDI solution
(in a non-integrated environment) must have a user interface
that enables someone who is not an EDI expert to be able
to perform the tasks of sending and receiving EDI purchase
orders or invoices. Alternatively, if you have integrated
EDI, a good EDI solution is easy to get into production
between your EDI trading partner and ERP/accounting system.
This means that it will be unnecessary to invest in expensive
consulting services since much of the integration work
will already have been performed by your EDI software
provider.
When looking for a good EDI solution, it’s important
that you research thoroughly. There are many different
offerings in the market, all purporting to offer good
EDI solutions. Since this is going to be a system that
controls much of your communication with some of your
most important customers or suppliers, it’s important
that the EDI solutions are investigated well. Some of
the concrete issues to research are:
Accessible audit trail – how easily can you research
transactions and trails?
Intuitive error handling – what happens when something
goes wrong?
Intuitive user interface – is it easy to learn
and use?
Easy partner management – can you add and change
trading partners easily?
Facilitation for EDI integration – can you grow
and improve your business processes?
Technical support services (preferably find out what
other customers have experienced)
A centrally important consideration in choosing a good
EDI solution is to realize that you will require technical
support when you have problems. Remember that the EDI
solution will be mission critical for your trading operations.
As a consequence, the level of technical support that
your EDI solution vendor will provide you, and at what
expense, is an important consideration. Many EDI companies
are small and have only a small ability to provide good
customer support on the EDI solutions they sell. As a
consequence, the EDI solution is incomplete without good
technical customer service.
6) Why are my large trading partners forcing me to do
EDI? EDI Training
Implementing an EDI solution is necessary in many trading
relationships with larger organizations. Larger companies
have implemented EDI solutions decades ago in order to
generate concrete strategic and operational benefits,
such as:
Strategic:
- improved cash and inventory cycles
- ability to rapidly incorporate trading partners into
business processes
- decreased operating costs
Operational:
- reduced paper, postage and sorting activities
- reduced inventory
- reduce manual processes, double entry and errors
- greater security in message delivery and transaction
processing
The above benefits of implementing an EDI solution have
caused larger companies to implement EDI software and
also require that their customers and suppliers do business
via EDI. In many cases, large companies will not enter
into a business relationship unless they are sure that
the trading partner will implement an EDI solution.
Large companies generate an enormous amount of paper – which
requires an enormous infrastructure to receive, send,
sort, store and maintain. The very nature of paper is
that that it can easily be lost, misplaced or destroyed.
When an EDI solution is implemented, the paper flow in
the organization is significantly reduced. SAP EDI
EDI has been available in the US in one form or another
since the mid 1960’s. In 1968 a group of railroad
companies concerned with the quality of inter-company
communication and the exchange of transportation data
created a consortium to find a solution. This organization
became known as the Transportation Data Coordinating
Committee (TDDC). While this was happening, other
multi-national corporations such as General Motors, Sears
and K-Mart were investigating ways to improve inter-corporate
communication – especially concerning the movement
of documents such as purchase orders and invoices, by
using proprietary electronic systems with their larger
trading partners. While these systems were not
true “EDI”, they laid the groundwork for
what would eventually become the EDI standard. By the
mid 80’s, K-Mart was the largest user of such an “EDI” system,
with well over 500 companies using their EPOS electronic
system.
Unfortunately, each EDI system was specific to the company
that created it. The proprietary nature of this
arrangement meant that trading partners needed to use
multiple EDI systems to transact with their customers
or vendors. The concept of EDI was there, but the
ease and scalability of EDI was not.
In the grocery industry, EDI standard began to proliferate.
Large national grocers understood that for EDI to work
there must be an EDI standard. They were, however,
concerned that a universal EDI standard was impractical
given the available EDI technology. Around the same time,
several industries were beginning to sponsor a shared
EDI system managed through third-party networks. These
EDI networks would later become known as VANs (Value
Added Networks). VANs such as IBM IVANS and ORDERNET,
which served respectively the insurance and pharmaceutical
industries, had the same disadvantage of a proprietary
EDI format and a limited scope and reach. Because of
these limitations, they could not interact with other
EDI systems or VANs. In 1973, the TDCC decided to develop
a set of EDI standards that would allow companies using
EDI to work together. This led to the first industry-wide
EDI standards covering air, motor, ocean, rail and banking
industries. What evolved from this system became
known as the ANSI X12 EDI standard that was first made
available in 1981. European development of the TRADCOMS
EDI standard, the ODETTE and JEDI EDI standards started
in 1984. In 1985 the EDIFACT EDI standard was
created under the auspices of the United Nations to enable
a broader global EDI trading capability. |
