AN INTRODUCTION TO EDI

Getting started with EDI can seem like a daunting proposition. At first sight it can be difficult, highly technical, and even
obscure. Once you dig a little deeper, however, you quickly see that EDI can be a great deal of help to small and mid-
sized businesses that are seeking to automate their order processing and invoicing systems. From reduced workforce
costs to increased accuracy, EDI can deliver the promise of E-Commerce to small and mid-sized businesses around the
world. With this free E-Book you will get an in-depth introduction to EDI along with a primer on getting the most out of
your EDI investment.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 Contents Integration with IT Policies 22

AN INTRODUCTION TO EDI 1 Proactive: Bringing EDI In-House & Under Control 22

Overview of EDI 3 Strategic: Using EDI for Growth & Profitability 23

EDI Terminology 3 Getting Strategic with EDI 23

ANSI ASC X12 Interchange Control Structure 6 5 Keys to EDI Integration Success 23

Reading An ISA Line 6 Key #1 - Understand what you are getting yourself into 24

EDIFACT Interchange Control Structure 8 Key #2 - Start, learn, correct, expand 24

Reading The UNA And UNB Lines 10 Key #3 - It's all about the data 25

Reading a UNG Line 11 Key #4 - Selecting the right software 25

Reading a UNH Line 11 Key #5 - Selecting the right vendor 26

Functional Acknowledgments 12 DiCentral, the mid-market choice for business intelligence,

EDI and, integration 27
EDI and Data Communications 12
Learn more 27
The Value Added Network Concept 13

Data Communications Terminology 14

Communication Types 15

Signaling Speed 15

Data Compression 15

Error Control 15

File Transfer Protocol 15

Data Communication Standards 15

Electronic Commerce in the 21st Century 16

The Business-to-Business e-Commerce Value Chain 17

The Transaction Orientation 17

Fully Automated Electronic Commerce Solution 18

The case of the automobile industry 18

Hybrid Electronic Commerce Solution 19

Manual Electronic Commerce Solution 20

Getting Strategic with EDI 21

Reactive: Getting Started with EDI 21

Security 22

Availability 22

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 3
Overview of EDI
Electronic Data Interchange (EDI) is the computer-to-computer movement of routine business data in an approved stan-
dard format (e.g., ANSI ASC X12, EDIFACT or TRADACOMS). Companies that decide to trade business data with each
other using EDI are called trading partners. The trading partners must decide which transaction sets (EDI business docu-
ments) will be exchanged electronically, what information will be included (i.e., what segments and data elements within
the transaction set should be sent and received), and what method of communications will be used (e.g. asynchronous
communications via a Value Added Network or bisynchronous direct communications).

The EDI Standard data format can be thought of as a common language that allows all companies to communicate with
each other. That is, if all companies were able to accept or send data not only in their company's internal format(s), but
also in an EDI standard format (ANSI ASC X12, EDIFACT or TRADACOMS), then all companies would have one data
format in common for trading EDI mail.

DiTranslator translates the data coming into and going out of your PC, so you and your trading partner will be able under-
stand each other's data. An example of an EDI exchange could involve a buyer and a seller. Suppose the buyer identi-
fied an inventory need. A purchase order is produced by manual data entry or from data within the buyer's business
application.

DiTranslator will take this data and translate it into EDI standard format. The EDI data then passes through communica-
tions software that routes it over an electronic communications link to the seller. When the seller receives the transmis-
sion, the data is converted into a format that can be passed to the seller's order entry system or printed using their EDI
software.

Once the seller has received the data, a Functional Acknowledgment should be sent to the buyer indicating the transmis-
sion was received, and detailing any errors found when the transmission was validated against the EDI standard. Then
the seller may initiate an EDI Invoice to the buyer, and perhaps the buyer will respond by acknowledging the Invoice and
paying for the items with an EDI Payment Order/Remittance Advice.

EDI Terminology
Interchange

A group of data consisting of three components: an Interchange Control Header, a series of functional groups, and an
Interchange Control Trailer. The Interchange Control Header and Interchange Control Trailer encloses the series of func-
tional groups. An interchange can be thought of as a large envelope from your trading partner. Inside that envelope are
individual, smaller EDI mail envelopes.

Transaction Set and Message

The terms transaction set and message mean essentially the same thing. The differences are found in the details of their
structure. Both transaction sets and messages can be defined as follows: a collection of business related data called
segments that are exchanged between two trading partners. Each segment in a collection is followed by a segment
terminator.

Segment

A segment is a collection of elements that has a segment identifier, followed by one or more data elements. Between
each data element is a data element separator.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 4
Segment Identifier (ANSI ASC X12) and Segment Tag (EDIFACT)

A code that uniquely identifies a segment as specified in the appropriate segment directory. For example, the ANSI
ASC X12 Invoice Name segment identifier is “N1.” Note: “Segment Identifiers” are also used in EDIFACT. An EDIFACT
Segment Identifier is a unit of information consisting of a Segment Tag, which may be followed by a list of numbers that
control how many collections of segments appear in the data.

Element

A unit of information within a segment.

Composite Data Element

A collection of two or more data elements.

Data Element

The smallest unit of information in a transaction set or message.

Data Element Separator

A character used to separate elements in a segment.

Sub-element Separator

A character used to separate the data elements of an ANSI ASC X12 composite data element. Currently, sub-element
separators are reserved for future use.

Composite Data Element Separator

Used in EDIFACT to refer to a separator that appears between each data element of a composite element.

Segment Terminator

A character used to indicate the end of a segment. Usually not a printable character in ANSI ASC X12, and typically an
apostrophe (‘) in EDIFACT.

Envelope

The control information, such as identifiers and addresses, that surrounds data. The data is bound together by header and
trailer information. For details, see the ANSI ASC X12 or EDIFACT Interchange Control Structure section in this chapter.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 5
ISA Interchange Control Header
GS Functional Group Header
ST Transaction Set Header

PO #1 (Segments)

SE Transaction Set Trailer

ST Transaction Set Header

PO #2 (Segments)

SE Transaction Set Trailer

GE Functional Group Trailer
GS Functional Group Header
ST Transaction Set Header

INV #1 (Segments)

SE Transaction Set Trailer

ST Transaction Set Header

INV #2 (Segments)

SE Transaction Set Trailer

ST Transaction Set Header

INV #3 (Segments)

SE Transaction Set Trailer

GE Functional Group Trailer
IEA Interchange Control Trailer

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 6
ANSI ASC X12 Interchange Control Structure
Trading partners send data in a very specific format called the Interchange Control Structure. There are three basic levels
of ASC X12 envelopes: the interchange envelope, the functional group envelope, and the transaction set envelope. The
outermost envelope of EDI data is the interchange. An interchange consists of three components: an ISA Header seg-
ment, a series of functional groups, and an IEA Trailer segment. Header and Trailer segments contain sender and receiver
addresses. They envelope the series of functional groups.

Receipt Tag=960717, 1601

ISA*00*0000000000*00*0000000000*ZZ*7083179000
*12*3122721850
*960717*1113*U*00304*00000001*0*T*>
GS*PO*7083179000*3132721850*960717*1113*1*X*003040
ST*850*000000001

The second level of enveloping is a functional group. A functional group consists of three components: a GS Header
segment, a series of similar transaction sets, and a GE Trailer segment. The Header and Trailer envelope the series of
similar transaction sets. For example, if a trading partner sends a transmission containing 50 purchase orders and 30
invoices, all the purchase orders belong to a PO functional group and all the invoices belong to an IN functional group. A
GS Header segment and a GE Trailer segment bind the functional groups together.

The third level of enveloping is the transaction set level. Transaction sets consist of three components: an ST Header seg-
ment, a collection of related segments, and an SE Trailer segment. The ST Header segment and the SE Trailer segment
bind the related segments to a PO functional group and all the invoices belong to an IN functional group. A GS Header
segment and a GE Trailer segment bind the functional groups together.

The third level of enveloping is the transaction set level. Transaction sets consist of three components: an ST Header seg-
ment, a collection of related segments, and an SE Trailer segment. The ST Header segment and the SE Trailer segment
bind the related segments.

Reading an ISA Line

You can view the ISA line when you open the New Mail In file in WordPad, or the text editor you are using. The following
is a sample ISA segment (followed by GS and ST segments). Find ISA (second line down, far left). This marks the begin-
ning of the ISA segment. Find the fields contained within the ISA listed in order and described in the following table.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 7
ISA FIELD DESCRIPTION
* The asterisk (*) is an example of an ANSI ASC X12 data ele-
ment separator character. You will see this character through-
out the ISA segment used for separating the fields.
00 ISA01, Authorization information qualifier. This qualifies the
next element. In the example above, 00 means ignore the next
element.
0000000000 ISA02, Authorization information. This is the sender’s password.
00 ISA03, Security information qualifier. This qualifies the next
element. In the example above, 00 means ignore the next
element.
0000000000 ISA04, Security information. This is the receiver’s password.
ZZ ISA05, Interchange ID qualifier. This qualifies the next element.
7083179000 ISA06, Interchange sender ID. This is the sender’s EDI address.
12 ISA07, Interchange ID qualifier. This qualifies the next element.
3122721850 ISA08, Interchange receiver’s ID. This is the receiver’s EDI ad-
dress.
960717 ISA09, Interchange date. This is the date of the interchange in
YYMMDD format.
1113 ISA10, Interchange time. This is the time of the interchange.
Time is expressed in a 24-hour format.
U ISA11, Interchange standard ID. This identifies the standard for
this interchange. The “U” is the ANSI ASC X12 standard identi-
fier code.
00304 ISA12, Interchange version ID. This identifies the standard ver-
sion/release for this interchange.
00000001 ISA13, Interchange control number. A unique number used to
track interchanges.
0 ISA14, Functional Acknowledgment request flag. The “0” signi-
fies your trading partner does not need to receive an Inter-
change Acknowledgment (TA1) segment.
T ISA15, Test indicator. The “T” signifies this interchange is test
data, as opposed to “P” for production.
> ISA16, Sub-element separator.

Reading A GS Line
You can view the GS line when you open the New Mail In file in WordPad, or the text editor you are using. The follow-
ing is an example GS segment (between the ISA and ST segments). Find GS (fourth line down, far left). This marks the
beginning of the GS segment. Find the fields contained within the GS listed in order and described in the following table.

Receipt Tag=960717, 1601

ISA*00*0000000000*00*0000000000*ZZ*7083179000
*12*3122721850
*960717*1113*U*00304*00000001*0*T*>
GS*PO*7083179000*3132721850*960717*1113*1*X*003040
ST*850*000000001

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 8

GS FIELD DESCRIPTION
* The asterisk “*” is an example ANSI ASC X12 data element
separator character. You will see this character throughout the
GS segment used for separating the fields.
PO GS01, Functional ID code. Indicates the transaction set type for
the transaction sets in this functional group. In the example
above, the code is PO for a purchase order.
7083179000 GS02, Application sender’s code.
3132721850 GS03, Application receiver’s code.
960717 GS04, Group date. The date this functional group was sent in
YYMMDD format.
ZZ ISA05, Interchange ID qualifier. This qualifies the next element.
1113 GS05, Group time. The time this functional group was sent.
Time is expressed in a 24-hour format.
1 GS06, Group control number. A number that is different for
each functional group enveloped by an ISA segment.
X GS07, Responsible agency code. The agency responsible for
this functional group.
003040 GS08, Version/Release indicator. The agency version/release
of the transaction sets in this functional group.

EDIFACT Interchange Control Structure

Trading partners send data in a very specific format called the Interchange Control Structure. The EDIFACT Interchange
Control Structure consists of an optional Service String Advice, followed by three basic levels of EDIFACT envelopes:
the Interchange envelope, the Functional Group envelope, and the Message envelope. The Service String Advice (UNA)
is a character string at the beginning of an interchange, defining the syntactical characters used in the interchange. The
Service String Advice character string is optional. The Interchange Envelope consists of three components: a UNB
Header segment, a series of functional groups or a series of messages, and a UNZ Trailer segment. The UNB header
segment and a UNZ trailer segment contain sender and receiver addresses. The UNB and UNZ segments are mandatory.

A functional group consists of three components: a UNG Header segment, a series of similar messages, and a UNE
Trailer segment. The Header and Trailer segments envelope the series of similar messages. For example, if a trading
partner sends a transmission containing 50 purchase orders and 30 invoices, all the purchase orders belong to the same
functional group and all the invoices belong to another functional group. Functional group segments are optional. If there
are no functional groups, the interchange envelope surrounds a series of messages of the same type. For example, the
messages must all be Purchase Order messages or they must all be Invoice messages. A message consists of three
parts: a UNH Header segment, a collection of related segments, and a UNT Trailer segment. The Header and Trailer seg-
ments envelope the collection of related segments. Message Header and Trailer segments are mandatory. Segments are
used as required.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 9
UNA Service String Advice (Conditional)
UNB Interchange Control Header (Mandatory)
UNGF Functional Group Header (Conditional)
UNH Message Headder (Mandatory)

PO #1 (Segments)

UNT Message Trailer (Mandatory)

UNH Message Header (Mandatory)

PO #2 (Segments)

UNT Message Trailer (Mandatory)

UNE Functional Group Trailer (Conditional)
UNG Functional Group Headder (Conditoinal)
UNH Message header (Mandatory)

INV #1 (Segments)

UNT Message Trailer (Conditional)

UNH Message Header (Mandatory)

INV #2 (Segments)

UNT Message Trailer (Mandatory)

UNH Message Header (Mandatory)

INV #3 (Segments)

UNT Message Trailer (Mandatory)

UNE Functional Group Trailer (Conditional)
UNZ Interchange Control Trailer (Mandatory)

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 10
Reading The UNA And UNB Lines
You can view the UNA and UNB lines when you open the New Mail In file in WordPad, or the text editor you are using.
The following is an example of both the UNA and UNB segments.

UNA: +
UNB+UNOA: 1+TSI12013:01+TSITEST+921216: 1000+5
UNG+CUSDEC+TSIINTL+TP+921216: 1000+5+UN+2:912+12345PASS
UNH+45+CUSDEC:2:912:UN
BGM+AB+111+++TN:800000052

UNA FIELD DESCRIPTION

: Component data element separator used in this interchange.
+ Element separator used in this interchange.
, Decimal notation. A comma “,” or period “.” is used.
? Release indicator. A symbol that allows you to use the character delimiter as data.
Blank Reserved symbol. Place reserved for future use.
' Segment terminator.

Find UNB (second line down, far left). This marks the beginning of the UNB segment. Find the fields contained within the
UNB listed in order and described in the following table.

UNB FIELD DESCRIPTION

UNOA Syntax identifier
1 Syntax version
TSI12013 Sender ID. Your partner’s EDI address.
01 Sender ID code qualifier. This qualifies the element.
TSITEST Recipient ID. Your EDI address.
921216 Date of preparation. The date this interchange was prepared.
1000 Time of preparation. The time this interchange was prepared.
5 Recipients ref./pass. Your password.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 11
Reading A UNG Line
You can view the UNG line when you open the New Mail In file in WordPad, or the text editor you are using. The follow-
ing is a sample of the UNG (after the UNA and UNB segments and before the UNH and BGM segments).

UNA: +
UNB+UNOA: 1+TSI12013:01+TSITEST+921216: 1000+5
UNG+CUSDEC+TSIINTL+TP+921216: 1000+5+UN+2:912+12345PASS
UNH+45+CUSDEC:2:912:UN
BGM+AB+111+++TN:800000052

Find UNG (third line down, far left). This marks the beginning of the UNG segment. Find the fields within the UNG listed
in order and described in the following table.

UNG FIELD DESCRIPTION

CUSDEC Functional ID code. Indicates the message type for the messages in this functional group. In the example above,
the code is CUSDEC for a Customs Declaration message.
TSIINTL Application sender’s ID.
TP Application receiver’s ID.
921216 Date of preparation. The date this functional group was prepared in YYMMDD format.
1999 Time of preparation. The time this functional group was prepared. Time is expressed in a 24-hour format.
5 Functional group reference number.
UN Controlling agency. The agency responsible for this functional group. The EDIFACT controlling agency code is “UN”
for the United Nations.
2 Message type version number.
912 Message type release number. The UN/EDIFACT standards release number for this functional group.
12345PASS Application password. Your trading partner’s password.

Reading A UNH Line

You can view the UNH line when you open the New Mail In file in WordPad, or the text editor you are using. The follow-
ing is an example of the UNH segment (following the UNA, UNB and UNG segments).

TSI12013:01+TSITEST+921216: 1000+5
TSIINTL+TP+921216: 1000+5+UN+2:912+12345PASS
DEC: 2:912: UN
+++TN:800000052

Find UNH (fourth line down, far left). This marks the beginning of the UNH segment. Find the fields contained within the
UNH listed in order and described in the following table.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 12

UNH FIELD DESCRIPTION

45 Message reference number.
CUSDEC Message type ID. Identifies the type of this message. For example, CUSDEC for Customs Declaration message.
2 Message type version.
912 Message type release number.
UN Controlling agency. The controlling agency responsible for this message. The UN/EDIFACT controlling agency code
is “UN” for the United Nations.

Functional Acknowledgments
The Functional Acknowledgment (ANSI ASC X12 997) transaction set acknowledges the receipt of functional groups.
The Functional Acknowledgment is sent to report the system’s syntactical analysis of received functional groups. The
system analyzes the data based on the ANSI ASC X12 EDI standards. Like all other transaction sets, a 997 Functional
Acknowledgment can be sent or received by a trading partner. For example, if you send an (ANSI ASC X12) 810 Invoice,
your trading partner may send you a Functional Acknowledgment in reply. The Functional Acknowledgment will indicate
whether or not the transaction set had the correct syntax, looping, and structure. The Functional Acknowledgment does
not indicate that the business data within the transaction sets is acceptable to your trading partner.

EDI and Data Communications

Data communications is an essential ingredient in the EDI process. It is the conduit enabling you to exchange electronic
business transactions with your trading partners. In the EDI model, data communications is used as a subsystem to
transfer information from a source computer to a target computer.

It is important to understand that EDI and data communications are two distinct technologies. EDI defines an encoding
standard for business information. Data communications defines mechanisms to transfer this EDI encoded information
between your computer and your trading partner’s computer.

 First, your customer prepares the Purchase Order data following the language rules of EDI standards. The Purchase
Order data resides at a remote location.

 You then launch a data communications session using DiTranslator, which connects your computer to this remote
location. During this data communications session, a file transfer mechanism is used to move the Purchase Order
data, already in EDI format, from the remote computer to your computer. The data communications session is then
terminated.

 You are then able to process the Purchase Order data using DiTranslator. You may need to send an Invoice to your
trading partner. In this case, you prepare the Invoice using DiTranslator.

 You then launch a communications session, which connects your computer to the remote destination. The Invoice, in
EDI standard format, is moved from your computer to the remote computer during this communications session.

Occasionally, EDI standards define guidelines for data communications used in an EDI process. These guidelines may
include time constraints, which help assure that responses to transaction sets received will be sent within a specific time
period. EDI standards also define how the sender’s address and receiver’s address are encoded. However, EDI stan-
dards do not normally define the communications, which actually cause the data to move from source to destination. A
variety of data communications modules are supported by DiTranslator. You simply use the module required to link to the
desired remote location. This topic is discussed in more detail later.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 13
The Value Added Network Concept
When you send a paper business correspondence to a trading partner you normally use the services of a post office or
a private carrier. The Value Added Network (VAN) concept is fundamentally the same as an electronic post office. VAN
services are provided by third party organizations. Using paper correspondence, either you or the recipient pays for the
postage. The same model applies with VAN services. Normally, each sender pays the VAN a service charge based on
the number of characters sent (typically kilo-characters).

Don’t be misled by the term network. This term does not imply a local area network (LAN) nor wide area network (WAN).
A VAN simply contains a network of electronic mailboxes. When you are dealing with a trading partner through a single
VAN, then both you and your trading partner will have private mailboxes in the VAN. Overall, the VAN may contain thou-
sands of mailboxes. The only ones that you will be interested in are your mailbox and your trading partner’s mailbox.

The VAN conceptual model is very simple. Again, let’s consider the example in which you want to obtain Purchase
Orders from your trading partner. Both you and your trading partner have private mailboxes in a single VAN. Your com-
puter is at one physical location. Your trading partner’s computer is at a second physical location. And, the VAN resides at
a third physical location. Your trading partner’s computer first sends the EDI Purchase Orders to the VAN. A file transfer
mechanism is used to move the Purchase Orders from your trading partner’s computer to the VAN. The EDI format
includes an outer envelope (much like the outer envelope of a paper letter), which defines the sender’s address (in this
case your trading partner’s address) and a receiver’s address (in this case your address). Typical envelopes are the ANSI
ASC X12 ISA, BG, and EDIFACT UNB envelopes.

When the VAN receives the EDI Purchase Orders, the VAN reads the envelope to determine the ultimate destination of
the data. In this case, the receiver’s address indicates that the receiver is you, and the VAN will place the EDI Purchase
Orders in your electronic mailbox. The communications session between your trading partner’s computer and the VAN
is then terminated. Note that your computer is not yet directly involved with this process. At this point, the EDI Purchase
Orders are stored in your mailbox. You may, then, use DiTranslator to launch a communications session between your
computer and the VAN at your convenience. The DiTranslator communications module that you are using will automati-
cally request the VAN send the data contained in your mailbox. The VAN will then send the EDI purchase orders from
your mailbox in the VAN to your computer. Note that your trading partner is not directly involved in the communications
session between your computer and the VAN.

There are a number of questions that might arise at this point. First, “How do I know if there is mail in my mailbox before
I call?” The answer is you don’t know. Some VANs provide mailbox contents reports that you receive via a separate com-
munications session. Normally, you simply check your mailbox at various points in time. If you call the VAN and there is
no mail in your mailbox, the VAN will send a ‘no mail’ indicator during the communications session and DiTranslator will
report the ‘no mail’ status to you. You can configure DiTranslator to periodically call the VAN to check for mail while you
are away from the computer. See Automating DiTranslator for details.

Another question that might arise is, “Will my mailbox only contain data from one trading partner?” If you are only deal-
ing with one trading partner on the VAN, your mailbox will contain only mail from that one trading partner. If you are
dealing with multiple trading partners on the VAN, your mailbox may contain mail sent by one or more trading partners.
Remember that when you are dealing with a VAN, your computer doesn’t connect to your trading partner’s computer.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 14
So far, we have considered the case in which you receive mail sent by your trading partner through a VAN. Now let’s
consider the case in which you send mail (such as Invoices) to your trading partner through a VAN. It is once again a
two-stage process. First, you use DiTranslator to start a communications session between your computer and the VAN.
DiTranslator will then send the Invoices to the VAN. The communications session between DiTranslator and the VAN is
terminated. The VAN processes the envelope and determines to whom you are sending the mail. The VAN then depos-
its the mail in your trading partner’s mailbox. At some later point in time, your trading partner picks up its mail from its
mailbox.

Note that when you call the VAN, you can send mail to multiple mailboxes belonging to your trading partners, but you can
only receive mail from your mailbox. Similarly, your trading partner and other users of the VAN services cannot extract
mail from your mailbox.

In certain cases, a situation might arise in which you prefer to use a particular VAN and a trading partner prefers to use a
different VAN. DiTranslator can connect you to multiple VANs. Or, if you prefer, some VANs perform transparent inter-
connection between each other. You deal directly with your VAN and your trading partner deals directly with the other
VAN. The two VANs take care of the rest. This is commonly known as a VAN interconnect. VAN communication is very
common when exchanging EDI data with your trading partner. A second common approach is to use what is called point-
to-point communication. In point-to-point communication, your computer establishes a direct connection to your trad-
ing partner’s computer in order to exchange EDI files. Under normal circumstances, your trading partner will rarely call
your computer in order to establish a communications link and exchange EDI files. The most common occurrence is for
DiTranslator to initiate the communications session. This is true for both VAN and point-to-point communication.

Data Communications Terminology

The data communications field is flooded with terms used to describe a wide variety of concepts. Data communications
technology is continually enabling faster data rates on normal dial lines, and as a result, the complexity is increasing. The
data rate has roughly doubled every 3 years. Fortunately, you don’t have to be a data communications expert to utilize
data communications in EDI. DiTranslator does the hard work for you. However, it is a good idea for you to become
acquainted with fundamental data communications terminology. This knowledge will enable you to make decisions when
faced with multiple data communication options in dealing with EDI and trading partners. A data communications ses-
sion is accomplished via a combination of software and hardware installed in your computer. The hardware consists of
a modem, interconnection cables, as well as the telephone line. A modem (MOdulator / DEModulator) converts digital
signals from your computer to analog signals on the telephone line, and vice versa.

Data communications software and modems work as a unit to accomplish a successful communications session. There
are five major attributes, which collectively specify a communications session. They are:

 Communication Types

 Signaling Speed

 Data Compression

 Error Control

 File Transfer Protocol

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 15
Communication Types
DiTranslator supports two types of data communications: asynchronous and bisynchronous. Asynchronous is the most
popular data communications type. The shift towards asynchronous communications in EDI has gained momentum.
Today, just about all VANs Support asynchronous communications. During an asynchronous communications session,
start and stop bits are used to frame the data characters. This framing approach allows varying gaps of time to occur
between each character sent. The two end points do not need to be precisely synchronized when data is sent. The
receiving node can receive a character, and then wait idly for the next character. The start bit indicates the next character,
and the stop bit flags the end of the character. This asynchronous approach does not require elaborate modem synchro-
nization circuitry, which is why asynchronous modems are significantly less expensive than bisynchronous modems.

Signaling Speed
Two modems must use the same signaling speed during a communications session. The signaling speed is usually
designated as the number of bits per second (bps) sent. Common speeds are 1200, 2400, 9600 and 14400 bps. The
trend is definitely toward higher data rates, 9600 bps, 14400 bps, and higher. Not all VANs support these higher speeds.
For cases in which a VAN does support a higher speed, you are not always guaranteed the data throughput will be at the
highest speed. Noise bursts and low quality lines can cause higher speed modems to fall back to a lower speed, some
modems do this automatically, some do not. The situation is much like that of a high performance car: you can’t usually
utilize all the horsepower it has.

Data Compression.
A common characteristic of the new breed of asynchronous modems is to have provisions to compress data before it is
sent as electrical signals on the communications line. This has the overall effect of increasing the throughput while still
using the same signaling speed. There are varying degrees of data compression offered by the various data compression
standards. As with signaling speed, if a certain type of data compression standard is used, both modems must support it.
Common data compression standards are tabulated later in the Data Communication Standards section.

Error Control
Error-free communications is absolutely essential. An error, which drops or adds a digit in an invoice, could mean disaster.
There are a number of different error detection and correction standards used in modems and software today. The trend
towards higher data rates underscores the need for assurance of error-free data transfers. A number of different error
control mechanisms are tabulated later in the Data Communication Standards section.

File Transfer Protocol

The file transfer protocol used during a communications session defines the ground rules that must be followed by the
two nodes. A common bisynchronous protocol is the 3780 bisynchronous protocol. Common asynchronous protocols
include xmodem, ymodem, zmodem, and kermit, to name a few.

Data Communications Standards

Now that we have reviewed the general attributes associated with a communications session, let’s take a closer look at
specific data communications standards. Recall that data communications standards are separate from EDI standards.

Any particular modem can contain any combination of the standards depending on how a modem manufacturer wants to
position itself in the market. For example, a particular model can contain V.32 bis for signal speed, V.42 for error control
and MNP for data compression. Modem manufacturers mix and match which set of standards their modems support.
The important fact to remember is that not all asynchronous modems are compatible with each other, and not all asyn-
chronous modems are compatible with all VANs.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 16
Electronic Commerce in the 21st Century
There are a number of ways to define the term ”Electronic Commerce." Today, most consumers think of electronic com-
merce as the use of a Website to search and place an order or purchase a product. In fact, electronic commerce is sig-
nificantly more involved and has been in practice for a number of years prior to the explosion of our current definition of
e-commerce. As far back as 1994, the need was driven by work performed related to the electronic exchange of transac-
tion documents for several large corporate entities (the most basic definition of electronic commerce), and the difficulties
faced in performing tasks within this field.

One of the lessons from this work was that transactions can exist within separate business entities and between groups
or divisions within the organization. This concept of ‘trading partners’ clearly shows that there are often many different
trading patterns within and between organizations, and that there is no one solution that addresses both. Consider that
within business-to-business markets, most businesses do the majority of their trading volume with a few loyal custom-
ers who have set trading patterns. Nevertheless, most businesses also have a lot of customers who trade with them in
irregular patterns. This, of course, is a result of the inherent nature of the market and the position of different businesses
within their market categories. There is very little if anything that an individual business can do to change this fact. As a
result, the electronic commerce solutions they implement should take this inherent nature of doing business into account.
Electronic commerce solutions are implemented as a tool in order to reduce costs and increase efficiency.

Extranets Internet
Marketplace Network

Transaction Information

Fully Automated Solution

Hybrid Solution

Manual Solution

Raw materials Sub Assemblies Manufacturing Distributor Dealer CUSTOMER

Product Avalibility & Design
Market And Demand Information

The Business-to-Business Electronic Value Chain

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 17
The Business-to-Business e-Commerce Value Chain
The Internet has revolutionized electronic commerce and has provided a standard protocol for the exchange of informa-
tion, thus giving companies a window into a worldwide market for their products. Though electronic commerce has
been around for a long time, electronic commerce has historically been prohibitively expensive for small and mid-sized
businesses. The introduction of the Internet has made it possible for companies of any size to benefit from e-commerce.
Figure 1 illustrates the electronic commerce value chain where the marketplace network is the Internet or Internet
technology-based network. There are two orientations in the e-commerce value chain: (1) Transaction orientation and (2)
Information orientation.

The Transaction Orientation

The transaction orientation is focused on business transactions that take place on the Internet, i.e., purchase orders,
order confirmations, invoices, payments, etc. Network-based business transactions can be done by using the Internet
or other types of networks. The characteristics of the different transaction-oriented electronic commerce solutions are
listed in the table below.

SOLUTION CHARACTERISTICS
AUTOMATED No Human Involvement
Computer to Computer
Time & accuracy are critical
Computer system integration
HYBRID Web-based purchasing
Computer to computer exchange of data
Flexibility and on-line information are critical
System integration to achieve efficiency and accuracy
Computer to computer exchange of data
MANUAL Web-based purchasing
Flexible & easy to use
Very low cost to the purchaser
Efficient for the supplier

Information oriented transactions on the other hand are practically always restricted to the Internet. The Internet has
opened vast opportunities for suppliers to exchange information with their customers. Information about product design,
specifications, capabilities, and availability flows freely through the value chain, while the supplier gets feedback through
the value chain on market demands and needs. This information is not only restricted to product information, services
can be offered and demanded, project plans can be exchanged and worked on by several parties, and workgroups can
be formed to exchange joint information. A basic characteristic of the information orientation is that no transaction or
purchase is performed. The transaction or purchase has taken place or will take place depending on the information
exchanged.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 18

order dispatch
invoice
information notice

purchase order
generated
In-house order
automatically
and inventory
by in-house
supplier CUSTOMER
application

supplier electronic
customer
purchase order

The Fully Automated e-Commerce Solution

Fully Automated Electronic Commerce Solution

The definition of a fully automated solution is that there is full integration between the information systems on both ends.
A significant characteristic of the fully automated electronic commerce solution is that each trading partner only works
within their business application. The process is initiated by either an application or by an operator registering information
into the business application. An example, for instance, is registering purchase orders in the purchase order system. The
electronic commerce system will then automatically communicate this purchase order to the vendor. In a fully automated
system all further exchange of information will be done by software applications. All necessary actions are triggered by
the system. Companies with established trading relationships are using fully automated solutions with suppliers and/
or customers.Usually, the trading pattern is high volume and repetitive in nature. Important aspects are lead times, fault
tolerance, and accuracy.

The Case of the Automobile Industry

A common trait for the automobile industry in more recent times has been “just-in-time” delivery and manufactur-
ing. Since cars are high cost items, excess inventory is costly, and there is a risk of producing units that will not move
in showrooms, increasing the need for discounts and purchase incentives. As a result, automobile manufacturers have
increasingly pushed the inventory risk of raw material and sub-assemblies over to their suppliers, resulting in a massive
focus on delivering materials and sub-assemblies only when needed by the manufacturers, a concept commonly known
as “just-in-time” deliveries. In fact, it is fairly common for a supplier to build a new factory and warehouse close to the
automobile assembly plant in order to fulfill the terms of their contracts of delivering just-in-time. Naturally, this has also
led to high demands on the information system infrastructure in both organizations. The automobile manufacturers have
fully automated assembly plants, where each and every aspect of logistics, planning and purchasing is being handled
by the computers. The human involvement has been reduced to the minimum, as the risk of not having the right part at

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 19
the right place at the right time, is too high. Car manufacturers have demanded that their suppliers cater to this situation
by instituting similar information-systems capability on their side to handle the flow of information back and forth. Most
supplier contracts within the automobile industry have specified time limits for the processing and response to any given
exchange of information, with accompanying fines should these limits be exceeded. Some also risk the cancellation of
contracts should they miss deadlines repetitively. In this environment, electronic commerce is not only an efficient tool,
it is absolutely necessary in order to operate the business. It also means that there is a very high level of integration
between the information systems being used on both sides, and the exchange of data is fully automated. This character-
izes the Fully Automated Electronic Commerce Solution.

Hybrid Electronic Commerce Solution

Hybrid electronic commerce solutions use the World Wide Web in the electronic commerce process. The hybrid solution
implies that there is at least one manual process involved to complete the exchange of data, and that this operation is
done outside the customer's business application. A typical configuration could be a distributor that uses a web site that
allows customers to manually make purchases. Four criteria have to be fulfilled to qualify as a hybrid solution: The cus-
tomer enters the purchase order manually on the supplier's web site. The order confirmation is returned from the supplier
both to the browser as a web page and an application-readable structured message (order confirmation/purchase order
copy) is returned either through the browser as an ActiveX object, a Java Bean or an XML message, or an application-
readable structured message (order confirmation / purchase order copy) is returned by e-mail. The structured message
is automatically interpreted and registered in the customer’s business application/ERP system. On the supplier side, the
process will be totally automated, while on the customer side there is one manual operation only – entering the purchase
order on the web. The hybrid solution ensures that there is a complete integration between the business applications
of both trading partners. The hybrid solution offers some superior qualities compared to the fully automated solution
and the manual solution. Compared to the fully automated solution the hybrid solution is superior under the following
circumstances:

 The customer wants to have instant access to product availability before purchasing

 The customer wants to have information about delivery times prior to purchasing

 The customer wants to have information about substitute products available and the availability and delivery times of
such products

None of this information is available in a fully automated e-commerce solution since the purchase order is either gener-
ated automatically or the person entering the purchase order can only access information stored in their own business
application. Yet, the hybrid solution is inferior to the fully automated solution when the above mentioned circumstances
are not of importance. The hybrid solution is superior to the manual solution under the following circumstances:

 The customer needs to have all purchase orders registered in his own business application

 The volume of purchase orders from the specific supplier is large enough to defend the substantial in-vestment the
hybrid solution needs compared to the manual solution

The hybrid solution is not yet widely in use because the software technology is not commercially available yet.
Companies can create a hybrid solution today by combining a web site for customers to make purchases as well as
software for fully automated solutions to send an order confirmation to the customer. However, the technology where
a structured message is sent back to the customer in ActiveX, XML, or Java Bean and integrated with the customer’s
business application is not yet available. DiCentral is in the forefront of researching this technology and is committed to
providing products that enable companies to take advantage of the superior qualities of the hybrid electronic commerce
solution. We think that the hybrid solution will grow to become the most important business-to-business electronic com-
merce solution for purchases of production related products. The flexibility and integration capabilities of this solution

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 20

order dispatch purchase

information notice order created
automatically

integration
supplier CUSTOMER
manual order entry

order confirmation
order confirmation
web server
(xml, activeX to back-end)
order confirmation
html to browser browser

supplier customer
The Hybrid e-Commerce Solution

satisfy both the supplier's and the customer's needs and wishes for an efficient electronic commerce solution. The
hybrid solution truly reduces costs and increases the productivity of the trading partners, but it especially caters to the
needs of the customer when using the World Wide Web to purchase products.

Manual Electronic Commerce Solution

The modern manual electronic commerce solution is focused on Internet shopping, where there may be no prior relation-
ship between the supplier and the customer. The key distinction between the manual electronic commerce solution and
other solutions is that there need not be any prior relationship between supplier and customer since there is no data flow
between the parties’ applications. In both the fully automated solution and the hybrid solution both parties need to agree
on the structure of the application-to-application data flow. These characteristics make the manual electronic commerce
solution not only the only viable solution for consumer-based electronic commerce, but also superior for new and infre-
quent business customers. The manual solution provides an effective tool, as it does not require any system integration
on the customer side. Thus, the manual electronic commerce solution does not require an investment from the cus-
tomer. For small and medium-sized businesses with low volume this is a very efficient way to purchase goods from their
vendors. The purchasing volume for such companies is not large enough to make the necessary investment to move into
a hybrid electronic commerce solution or a fully automated electronic commerce solution. The supplier’s Web site gives
the customer immediate feedback on stock availability and delivery times.

The supplier enjoys the benefits of selling and marketing on the World Wide Web and, depending on the level of integra-
tion with the business application, the supplier can enjoy cost reductions and productivity increases in order-entry and
order-processing.

The manual electronic commerce option is well suited for purchasing nonproduction products, such as office equipment,
since the customer’s need for updating internal inventory systems is limited.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 21

requires additional
software

optional
integration
order entry

supplier CUSTOMER
web server browser

manual input manual input

order confirmation
html to browser
printout
printout

supplier customer
The Manual e-Commerce Solution

Getting Strategic with EDI

Your business has been profitable and successful for years, you understand your market, your product provides a solution
to a critical need, and you just signed a major national retailer that will mean significant expansion for your business. The
only problem is that you keep being told that you need to implement EDI and you are not quite sure where to turn. Your
problem is not unique, in fact even companies that understand and use EDI often struggle with how much or how little
attention to pay to EDI. Having a critical understanding of EDI, how it impacts your business, and how you can maximize
use of this technology is critical for any small and mid-sized business in today’s market of margin pressures and high
competition. As a business embarks on the road to effectively using EDI, it naturally progresses through three phases:

 Phase 1 - Reactive - At this phase you have just started using EDI, usually as a result of pressure from a significant
trading partner, EDI becomes a required nuisance.

 Phase 2 - Proactive - Eventually the business begins to see the advantages of EDI and realizes the potential cost
savings and decreased time to revenue. EDI becomes more important and dedicated resources are assigned to its
expansion.

 Phase 3 - Strategic - Ultimately EDI becomes a mature part of an integrated IT infrastructure with data seamlessly
being shared with trading partners directly out of in-house ERP systems and becomes a critical strategic component
of the company’s IT infrastructure in support of revenues and cost reduction.

Reactive: Getting Started with EDI

As a small business, your first exposure to EDI is often a forced one. Most frequently small businesses are faced with a
daunting proposition: you have signed an agreement with a major national retailer - great news for your business - but in
order to work with that business you are being mandated to use “EDI technology” to exchange transaction documents

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 22
like purchase orders, advance shipment notices, etc. At this phase of the EDI adoption curve most businesses will
typically opt for out-sourced services or for low cost, easy to use in-house software. Of course the benefits of the out-
sourced service is that the EDI work is done with little or no involvement from the business - there is no software to
buy, no complicated terminology to learn - you just simply use a web-based system to receive purchase orders and enter
advanced shipment notices, invoices and other transaction documents. While such a solution is perfectly viable for many
small organizations that are gaining first exposure to EDI, questions begin to eventually arise that make an in-house solu-
tion more viable - both for the small business and for the growing one.

Security
Regardless of available technology we have all seen stories in the press about sensitive credit card data, user informa-
tion, and other types of restricted data being compromised. The simple truth of the matter is that there is only one way
to guarantee that your data will not be at risk of compromise: keep it within your firewalls. Of course with any web-based
system this is simply not feasible.

Availability
As with security, the availability of a web-based system is 100% reliant on an outside party. As a business begins to rely
more and more on EDI, not having access to that data can have dire consequences on financial results in understated
revenues, mis-allocated expenses, and break-downs in relationships with critical trading partners due to faulty or missing
EDI data exchanges.

Integration with IT Policies

Although web-based systems try to account for issues such as secure access, integration of a web-based system into
broader IT policies can be daunting. Disaster recovery, business continuity, access and security planning, and other mis-
sion-critical IT functions and policies are simply not designed to account for a web-based system; the task often proves
impossible. It is at this stage that businesses begin to look to bring EDI in-house.

Proactive: Bringing EDI In-House & Under Control

Once a business has made the decision that EDI is important to the organization there are several considerations that
need to be made. Carefully planning an EDI purchase, deployment and integration within the larger context of an IT policy
must be done cautiously and in advance. 1) Selecting the right Vendor: Selecting a vendor with a solid reputation for
developing reliable and easy to use EDI software is a critical first step. As a mid-sized business you want to ensure that
the vendor has significant experience with EDI, that they will be able to understand your problems and provide you with
the type of advice that you need in order to properly establish EDI as a critical function of your business. 2) Selecting
the right software for your needs: Is the software easy to use? Does it have a reputation as a trusted, reliable product
that can grow with your needs? Ensuring that you have positive answers to both questions will mean that you will have
an easier time setting up EDI properly and that your staff will use it accordingly. 3) Understanding the growth potential:
Does the vendor you are selecting provide an upgrade path to more sophisticated products? Will you be able to start with
a single-user system and grow to a multiuser and perhaps to an integrated system as your EDI needs grow? Ensuring
that you have growth opportunity with the investment you are making will mean not having to re-invest in new and
unproven equipment as your business grows. 4) In what other ways can my vendor help? Can the vendor provide you
with consulting services to help you best utilize your newly purchased EDI software? Will they provide you with reviews
of your environment to help you identify areas that need bolstering? Ensuring that you work with a vendor that can help
you and will treat you as a key customer is critical for the small and mid-sized business that does not want to get lost in
the “other” revenue category of a multi-national corporation that happens to also provide EDI software.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 23
Strategic: Using EDI for Growth & Profitability
Eventually as your business grows you will find that having EDI as a stand-alone, dedicated system begins to become
cumbersome and begins to use too much man-power in managing data and reports. As your business matures and you
invest in more sophisticated business tools it’s critical to keep EDI in the forefront of that planning. Integrating your EDI
transactions into your ERP back-end system can save you money in faster transaction turn-around, reduced errors due
to mistakes in re-keying information, and improved usage of EDI. Ensuring that the vendor you have selected for your
EDI software can help you through this transition is critical to ensuring that when your EDI software becomes integrated
with your ERP system it will be done quickly, efficiently, and with few worries. An integrated EDI system will have some
significant up-front costs, but the long term benefits to a growing business will mean a return on investment measured
in mere months. At this stage of development it’s also critical to understand how EDI will fit into the larger IT perspec-
tive. Is EDI part of the IT department’s disaster recovery plan (DRP)? Are you considering issues relating to security and
access and how they relate to EDI? For EDI to become a strategic aspect of your company it must become a key com-
ponent for both line of business and IT departments. At this stage having the right vendor to assist you and provide you
with the right advice and the right tools will be critical.

Getting Strategic with EDI

As you explore the brave new world of EDI: or begin to ponder how to make better use of EDI in your business, DiCentral
is ready and able to become a key partner in helping you develop your EDI strategy. With over twelve years of expertise
in EDI, DiCentral has worked with Fortune 500 as well as small and mid-sized businesses and understands the com-
plexities and advantages of a properly implemented EDI strategy. DiCentral can help you navigate EDI across the three
phases of growth; our suite of products provides a robust, easy-to-use EDI translation package that has been deployed
and is being used by thousands of companies world-wide.

5 Keys to EDI Integration Success

Over the course of the past six years the market for ERP software has seen dramatic shifts. During that period, over 60%
of mid-market companies (companies whose revenues are above $100M per year but below $1B) have bought new ERP
systems. As mid-market companies bring new and expanded ERP systems in-house they are beginning to face the same
challenges that were once the exclusive domain of large enterprises. One of these requirements is the need to integrate
data received via Electronic Data Interchange (EDI) into their newly acquired ERP and accounting systems. The benefits
of EDI integration are well established and quantifiable both for major companies and for growing mid-market companies.
The most significant benefit is that of the reduction or elimination of manual data entry and the associated costs - both in
terms of manpower as well as costs associated with errors in data entry due to manual processes. As businesses begin
to consider deployments of new systems they invariable also review internal processes and procedures.

Eliminating the manual data entry process required to move EDI data into ERP systems can produce significant savings
for mid-market companies. A typical manual data entry process often involves a series of steps as laid out in the table on
the following page. With even the most basic EDI transfer procedure, the steps typically involve the printing of a report,
the duplication of this report for the benefit of multiple data entry clerks, and the manual keying of that data into the ERP
system. The manual process does, however, not end here. It continues at the opposite end of the transaction - when
orders are fulfilled the procedure must be reversed with printed reports of pending shipments being duplicated and
provided to data entry clerks, who in turn re-create the data for the EDI system that is then used to communicate with
outside trading partners. As the following table illustrates, the cost of such a procedure when measured in time can be
astounding, especially when one considers that this procedure must be duplicated for every order and transaction that is
processed in-house. Couple this with the enormous costs associated with mistakes and errors that are invariably made
during the manual data entry processes, and an integrated solution that dynamically routes data between EDI and ERP
systems becomes imperative.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 24
KEY #1 - UNDERSTAND WHAT YOU ARE GETTING YOURSELF INTO
The single biggest mistake mid-market companies often make in EDI integration is to underestimate the project they
are about to embark on when they choose to integrate EDI. No matter what you read on vendor sites, EDI integration
is complex; it requires in-depth knowledge of your data and it takes time. Being prepared for that will make you have
more realistic goals of the time-frame involved, and the results you can expect. As you think about the EDI integration
project it’s also important to think about how EDI integration will affect your company - both before and after your data
integration project is completed. The first question is: how will your process change after you integrate your data? As
you think about this question, consider all aspects of how EDI data is handled today. What reports are created? How are
the reports printed? How often? What data is available? What should happen next to that data? Who is responsible for it?
How will all of these processes have to change after your integration is complete? Planning for all these types of ques-
tions will ensure that you minimize the number of surprises you have after your integration project is complete. A second
key question to consider is: who will need to be involved in the integration project? This may seem like an obvious ques-
tion but it’s important to consider all aspects of the project and the people that may have valuable input. Where does the
expertise reside in your organization? As companies grow and manual processes expand, much of the information that is
vital to keeping processes functional and healthy is often undocumented and resides in the minds of the people involved
with the daily work. Involving the people who do the work as early in the EDI integration planning as possible will ensure
that you are exposed to all the different aspects of your manual procedures and how they will affect the integration
process. An important related question is: how will these “manual operators” be affected by the EDI integration after it
is complete? Companies often don’t consider the role these employees will have post-integration, but these people will
come to realize that their jobs will become redundant and unnecessary in an integrated environment. Planning for the re-
purposing of these employees before embarking on the integration project will minimize the frustrations you have to deal
with before and after it’s complete.

THE MANUAL ORDER PROCESS

PRINT DOCUMENTS MANUALLY 9 minutes
MANUALLY ARCHIVE DOCUMENTS 4 minutes 17
MANUALLY FAX DOCUMENTS 3 minutes minutes
MAIL 1 DOCUMENT MANUALLY 1 minute

KEY #2 - START, LEARN, CORRECT, EXPAND

Any EDI integration project is going to have initial problems. Once again, don’t believe the hype - you can plan as much as
you want but you will always find that there are challenges in your EDI integration project that you simply did not foresee.
For this reason, it is critical that you follow a process that allows for mistakes and unforeseen challenges. As your EDI
integration project proceeds, you will notice that it is significantly easier to deal with unexpected circumstances on a
small scale than it is on a large scale. For this reason, we always recommend that our clients begin with a sub-set of their
EDI integration goals. Perhaps it’s integrating only the data from one or two of your trading partners that use EDI - the
smaller ones - so that you can iron out some issues before you move on to the larger trading partners. It’s important to
remember that you are integrating data that is critical to your operational health; act accordingly. As you being to wrap up
your smaller “trial” integration project it’s important to have a review process in place where the team can analyze what
went right, what went wrong, and what could have been done differently or better. Through this process of implementa-
tion, review, and re-implementation, problems will be ironed out and your chances of success will be maximized when
the larger integration project is embarked upon. As you start on the larger EDI integration plan, be sure to set it up so
that the integration happens in stages; don’t attempt to do everything at once. Stage your integration so that each set of
data that can be segmented is handled as an individual mini-project. You may start by integrating by trading partner, or
perhaps by transaction set with all in-bound purchase orders first. Regardless of how you do it, make sure that you have

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 25
thought through a process that you can manage and that has the least negative impact on your organization.

KEY #3 - IT’s ALL ABOUT THE DATA

You have looked at your existing processes, you’ve planned a phased implementation of your EDI integration, you are
ready to go, right? Maybe. For mid-market companies one of the biggest implementation challenges often deals with
data. There are two aspects of the data you are going to be dealing with that you need to consider: data cleanliness and
subject-matter expertise. Data cleanliness simply means that before you embark on your EDI integration project you
should consider the state of your data and how it will impact the project. More specifically, think about issues like duplica-
tion or inaccurate data; for example, you may employ a look-up table to cross reference purchase orders with stock keep-
ing units (SKUs) that your company uses. Duplicate SKU numbers with different descriptions may not be a problem for a
data entry clerk who may intuitively know the difference, but they could create significant problems for your data integra-
tion project. This is just one example of how dirty data could impact your project. As you prepare for your EDI integration
project, review all the data sets that are going to be impacted by the project and ensure that the data has been scrubbed
and corrected.

A second aspect of managing data that mid-market companies often have trouble with is access to a subject-matter
expert. It’s important to understand that whether you are doing the data integration with consultants or with services
provided by your EDI integration vendor, their subject matter expertise is data integration - not necessarily the systems
involved. For this reason you will need access to someone who is familiar with your ERP and your EDI systems to be
able to answer technical questions as they arise during the project. Having access to such a subject matter expertise will
make it significantly easier to get your project completed on-time and within budget.

KEY #4 - SELECTING THE RIGHT SOFTWARE

As you research EDI integration solutions for your business, you are bound to find yourself on a vendor’s website with an
impressive list of companies to which they have sold data integration software. As a mid-market business it’s important
to keep in mind that just because it worked for a Fortune 500 organization does not necessarily mean it will work for
you. As you embark on your vendor and software selection process, consider several key issues about the software you
select that will help you narrow your field:

Q1 What is my budget?

This may seem obvious but data integration projects are notorious for going over budget. The reason for this is two-fold:
scope-creep is responsible for a significant part of the problem - companies that have’nt prepared properly have to adjust
for changing circumstances. The second reason, however, is related with poor planning regarding software. It’s critical
that your software budget is established as early as possible so that when possible vendors are selected, you will be
able to quickly gauge whether the software being considered is within your budget.

Q2 Who will do the integration work?

It’s surprising how often companies will embark on an EDI integration project only to realize after they have already
committed to it, that they don’t have any in-house expertise to perform the integration. Learning how to work with data
integration packages is not something you should embark on unless you plan on having that subject-matter expertise in-
house even after your integration is completed. If you decide to do the integration using in-house resources, the software
features and ease-of-use utilized in the implementation process should be important factors in your decision. If, on the
other hand, you will use third party consultants or rely on the software vendor to perform the work, the features of the
software you should focus on might be more related to your post-implementation needs.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 26
Q3 What formats will you need to support?

Understanding the file formats involved in your EDI integration project goes back to having a subject-matter expert
available. How does your ERP system import and export data? Via a flat-file? Proprietary format? XML? APIs? What kind
of format does your EDI system use? Having the answers to the questions will allow you to know to ask the software
vendor if they support the specific formats you need to use.

Q4 How fast does it need to be?

The speed of EDI integration software is a factor that mid-market companies don’t often consider. After all, just about any
data integration package on the market today can handle the data volume generated by a mid-market organization. The
key question to consider however, is room for growth. As your business grows, your data volumes will expand exponen-
tially; and since data integration is not an easy process you want to ensure that your systems will be able to handle the
expanded data volume without having to re-architect your EDI integration solution.

KEY #5 - SELECTING THE RIGHT VENDOR

Choosing the right EDI integration vendor is the fifth, and in some cases, the most critical aspect of your EDI integration
planning. The choices available to mid-market companies for data integration are many, and often selecting the most
appropriate vendor can be a very confusing process. As you seek a vendor, consider a number of key criteria:

Q1 How much experience in integrating EDI does the vendor have?

One of the first aspects of selecting the right vendor is to consider how much experience the vendor has in EDI integra-
tion. There are many vendors of data integration packages; however, working with EDI integration requires a specific skill
set and introduces a set of challenges that are unique to EDI integration. When selecting your EDI vendor, ensure that
you work with one that has been in the EDI integration business and understands the challenges involved.

Q2 What is the vendor’s primary market focus?

Everyone wants to work with the big guys right? The right answer is going to depend on the market focus of your EDI
integration software vendor. Do they primarily focus on enterprise customers? If that’s their main area of focus, how
much attention will you be able to get as a mid-market organization? Will you be on the top of the priority list if there
are any problems? Are you going to get access to the best resources the vendor has available? Select a data integration
vendor that focuses on small and mid-market companies and you are much more likely to get the kind of service that will
mean the difference between success and failure for you.

Q3 Will you have access to professional services?

Even if you have in-house resources, or if you have hired consultants to do most of the EDI integration work, it’s still
important to have ready access to professional services from the software vendor. The reason for this is simple: you may
only rely on them for training, or you may end up needing their expertise to help you resolve a challenging part of your
project. Whatever the case, if you don’t have ready access to professional services it may put your integration project in
jeopardy.

119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m

 27
Q4 Do you have access to more than one integration package?

One size fits all - it’s often one of the biggest challenges of buying EDI integration. A package designed for an enterprise
class deployment at a Fortune 500 organization may be overkill for your organization. Similarly, a package designed to do
basic EDI integration with small business software may not provide the type of processing power or business process
management that your business needs. As you talk to possible software vendors, make sure they have products that
span both ends of the spectrum in a way that allows you to start with low-end packages and migrate upwards as your
needs grow over time.

Q5 Are you getting too many promises?

This last aspect is often one of the biggest challenges of finding a good vendor. It’s common practice in the EDI integra-
tion business to promise first and deal with repercussions later. Be wary of software vendors that seem to be able to
deliver on all of your requirements without any concerns. Over the twelve years that DiCentral has been in the business
of integration, we have seldom run across a project that didn’t force us to ask questions at the very beginning.

As you select your software vendor, these are just some of the questions to consider. The most important aspect of
choosing an EDI integration vendor is to ensure that it is a company with which you are comfortable doing business; you
will be spending a lot of time talking to them over the coming months - make sure it’s someone with whom you can
work.

DiCENTRAL, THE MID-MARKET CHOICE FOR BUSINESS INTELLIGENCE, EDI, AND

INTEGRATION
At DiCentral we understand Business Intelligence, EDI, and data integration. For over twelve years, DiCentral has pow-
ered EDI integration for midmarket companies. Our professional services team has decades of combined experience and
has worked in all phases of EDI integration in a multitude of industries. As a company, DiCentral can help you with all five
elements of buying EDI integration - from planning your integration project to helping you select the right product from
our family rich with EDI and data integration solutions. Our network of resellers and consultants can work with you to
help ensure a successful integration project.

Learn more
Learn more about DiCentral by visiting our web site at http://www.dicentral.com and by downloading our other whitepa-
pers on data integration and EDI.

Since 2000, DiCentral has been an industry leader in supply chain and supplier performance management software
and services. With over 6000 valued customers processing millions of transactions annually, DiCentral has consistently
delivered quality products and services across the retail, chemical, logistics, warehousing, food, consumer goods, and
pharmaceutical industries. In short, our offerings simplify the way you do business through supply chain integration.

By using DiCentral solutions companies of all sizes can be provided with the tools necessary to act quickly with increased
insight, efficiency, and flexibility. In addition, DiCentral solutions streamline the communications that drive commerce,
manage orders and inventory, reduce costs, optimize performance, and provide the insight and agility needed to compete
on a global scale.

© 2010 DiCentral Corporation. All Rights Reserved. All other products, company names or logos are trademarks and/or service marks of their respective owners. v 1 -1/ 12
119 9 N A S A P a r k w a y < H o u s t o n , Tex a s 7 7 0 5 8 < t e l : 2 8 1. 4 8 0 .1121 < f a x : 2 8 1. 218 . 4 8 10 < s a l e s @ d i c e n t r a l . c o m < w w w. d i c e n t r a l . c o m