EDI 101 A Beginners Guide First Edition Published by David B. Mueller 2009 David B.

Mueller All rights reserved

Table of Contents
Introduction.....4 Chapter 1: EDI Defined.....5 What is EDI?..................................................................................................6 Translators..6 Summary.....7 Chapter 2: EDI Document Structure.......8 Transaction References.....9 Deciphering the Transaction...9 Identifiers, Separators, and Terminators...9 Segments10 Elements......10 Composite Elements..10 Control Envelopes11 Interchange Control Envelope (ISA IEA)12 Group Control Envelope (GS GE)12 Transaction Set Control Envelope (ST SE)13 Summary13 Chapter 3: EDI Guidelines....14 EDI Definitions Hierarchy....................15 Entity Specific EDI Guidelines...................15 Transaction Segment Overview...................15 Loops..................16 Transaction Overview Column Headings...................16 Transaction Notes..................18 Segment Definitions....................18 Segment Definitions Heading...................18 Data Element Summary.................20 Segment Definitions Column Headings..................20 Segment Notes....................21 Reading the EDI Segment.................21
1

Table of Contents (cont.)

Chapter 3: EDI Guidelines (cont.) EDI Mapping.......................22 Summary.................22 Chapter 4: EDI Business Models.....................23 Retail Model..................24 Medical Billing Model.................26 Third Party Logistics (3PL) Model...................27 Functional Acknowledgement (997).................29 Summary.................30 Chapter 5: EDI Implementation......................31 Cost Considerations.................32 Technical Considerations..................32 In-house Systems and VANs..................32 EDI Providers...................34 Communication Protocols...................35 Timing Considerations...................35 Hire an EDI Expert.................35 Summary.................36

Table of Figures
Figure 2-1 Sample EDI Document (unwrapped)........................9 Figure 2-2 Sample EDI Document (wrapped).......................9 Figure 2-3 EDI Segment........................10 Figure 2-4 EDI Segment with Composite Element Separators.......................11 Figure 2-5 Sample EDI Control Envelopes.......................11 Figure 2-6 Characters translators use to learn to read the EDI Document..12 Figure 3-1 Sample Segment Usage Guidelines......................17 Figure 3-2 Sample Segment Detail Guidelines.........................19 Figure 3-3 PO1 Segment......................20 Figure 4-1 Manufacturer/Retailer EDI Business Model......................24 Figure 4-2 Professional Health Care Claim EDI Business Model....27 Figure 4-3 3PL Inventory Management EDI Business Model......................28 Figure 5-1 In-house EDI Document Flow Overview.......................33 Figure 5-2 EDI Provider Document Flow Overview.......................34

Introduction
IF you are reading this then you must fall into one of the following categories:
Your retailer has required you to be EDI capable to receive their orders. Your insurance carriers require you to file your claims electronically due to HIPAA requirements. Your customer needs you to satisfy their EDI requirements for them. Someone who pays you will only do so if you invoice them or send claims to them via EDI. This probably left you asking: What is EDI? How do I implement EDI? Where do I begin? This eBook is designed to help you get started. First, we will explore what EDI actually is. Next, we will look at how an EDI document is structured and how to decipher it. Then, we will go through several examples of how EDI is implemented in different industries. Finally, we will discuss how to efficiently implement EDI into your business processes. In the electronic commerce fields (as this falls within) there are two related standards. One is known as EDIFACT the other as EDI. EDIFACT is very similar to EDI but it is a standard used internationally whereas EDI is used only domestically within the United States (and sometimes in Canada and Mexico). This eBook will focus only on EDI. If you are required to be EDI enabled by one of your customers, it is important for you to be familiar with their program and requirements. That is the goal of this eBook, not necessarily to turn you into an EDI expert. When you complete this eBook you will understand what your EDI experts are telling you and what your customers are asking of you. Although there are thousands of EDI documents designed for a large number of industries, this eBook is designed as a basic book for beginners and we will only look at simple retail, medical provider, and transportation business examples. This eBook is the best place for everyone to start for all industries regardless of how far you intend to take you EDI training.

Chapter 1: EDI Defined

What is EDI? Where does it come from? What
does it mean? Why does it exist? These questions and more will be answered in this chapter. We will look at the agencies that have defined what EDI is. We will define some of the terminology used to describe EDI. We will also look at the reason EDI is used and how EDI translators accomplish this.

What is EDI?
EDI is an acronym meaning Electronic Data Interchange. In the medical industry it is often referred to as ANSI or HIPAA. EDI standards are defined by several voluntary industry specific groups. The highest level of these is called ANSI or the American National Standards Institute. This is an organization that sets national standards for many different industries and is not limited to EDI. ANSI is split into committees for each industry need. The committee that specifies EDI standards across all industries is known as ASC X12. This is why EDI is sometimes referred to as ANSI or ANSI ASC X12 or ASC X12 or just X12. ASC X12 defines all documents used within EDI and all of the data elements usable within each document. Within ASC X12 there exist several industry standard groups, such as VICS in the retail industry. The industry standard groups further define the ASC X12 standards for usage within their specific industry. Some Industries, such as the medical industry, simply use the ASC X12 standards and do not define their own. The use of EDI in the medical industry has been legally required by HIPAA, a federal law called the Health Insurance Portability and Accountability Act, which is a far reaching law that includes a requirement to file health claims electronically using EDI technology. This is why EDI is sometimes referred to as HIPAA. The ANSI ASC X12 committee will occasionally modify the EDI requirements creating new versions. Versions of EDI are usually numbered as such: 4010, 4030, 5010, 5030 and so on. This version is used when specifying what type of document is required in a certain process. All of this sounds complicated but it is not necessary to memorize this, it is just included for background and to explain some terminology used.

Translators
An EDI transaction is basically a text file formatted using predefined standards designed to be readable and usable across any platform. That means that someone can securely send a document from a Windows XP platform to someone who has a Linux platform, or a Macintosh platform, or even an IBM mainframe. This is accomplished using a piece of software known as a translator. An EDI translator basically reads an EDI document and converts it into a format that can be used by the platform on which it is run. The document usually contains data that can go into a database and be processed by other applications, such as accounting or order processing software. EDI translators are available from many different sources for many different platforms. Some
6

companies write their own translator as part of a larger system or as a stand-alone product. There is no preferred way to do this and it is up to each individual company based on the resources they have available. Third party translators tend to be less expensive but are more generic and require more initial setup and maintenance by an EDI expert to meet the specific business needs of the user. This lends itself to making them more flexible for possible future needs. Proprietary or self written translators tend to be more specific to the needs of the party that developed them. They also tend to be less flexible and scalable to future needs.

Summary
EDI is a set of standards used to format a text file into a document that can be read by anybody, regardless of their platform, using an EDI translator. The significance of this is the ability to pass paperless transactions between business entities, greatly increasing the speed of business. Where once it would take a week or more to post a paper Purchase Order it now takes minutes using EDI technology.

Chapter 2: EDI Document Structure

When you view your first EDI document it looks
pretty confusing, almost as if it were written in a secret code. To some extent this is true. In this chapter we will begin to decipher that code. We will look at how the document is actually structured and what all of those symbols mean. This is the first step in learning how to read an EDI document.

Transaction References
There are many types of transactions available to be used for almost any possible business process. EDI transactions are usually specified by a three digit number. For example, the 850 transaction is a purchase order. An 810 transaction is an invoice, and so on. Transactions are often referred to by their three digit document number but are also referred to by name.

Deciphering the Transaction

Figures 2-1 and 2-2 are examples of what an EDI document looks like. At first it looks like gibberish, but if you look at it more closely you start to notice patterns. Every line contains numbers and letters separated by tildes (~) and the line is ended with an asterisk (*). These are called separators. Figure 2-1 is an example of an unwrapped document and figure 2-2 is a wrapped document. It is the separators that tell the translator where the data is delineated.

ISA~00~ ~00~ ~12~5557260541 ~12~5556288340 ~090408~2206~U~00401~600000198~0~P~:* GS~PO~15557844480~5557260541~20090408~2206~600000214~X~004010VICS* ST~850~002140001* BEG~07~RL~5075676~1~20081009* REF~DP~036* CSH~P4* ITD~05~2~0~~0~~30* DTM~037~20090413* DTM~001~20090418* PO1~~80~EA~5~~UP~999999999999~VA~XXXXXXXXX~CB~9999999~BO~001~IZ~33902* CTP~RS~RES~22* PID~F~08~~~TANK WITH LACE:BLK DOTBQT* PID~F~75~~~BLK DOTBQT* PID~F~91~~~SMALL* SAC~N~~VI~TC09~~~~~~~~~KOH3528AT* SDQ~EA~92~00810~8~00855~32~00860~24~00865~8~00885~8* CTT~1* SE~16~002140001* GE~1~600000214* IEA~1~600000198*

Figure 2-1 Sample EDI Document (unwrapped)

ISA~00~ ~00~ ~12~5557260541 ~12~5556288340 ~090408~2206~U~00401~600000198~0~P~:*GS~PO~15557844480~5557260541~20090408~2206~600000214~X~004010VI CS*ST~850~002140001*BEG~07~RL~5075676~1~20081009*REF~DP~036*CSH~P4*ITD~05~2~0~~0~~30*DTM~037~200 90413*DTM~001~20090418*PO1~~80~EA~5~~UP~999999999999~VA~XXXXXXXXX~CB~9999999~BO~001~IZ~33902* CTP~RS~RES~22*PID~F~08~~~TANK WITH LACE:BLK DOTBQT*PID~F~75~~~BLK DOTBQT*PID~F~91~~~SMALL*SAC~N~~VI~TC09~~~~~~~~~KOH3528AT*SDQ~EA~92~00810~8~00855~32~00860~2 4~00865~8~00885~8*CTT~1*SE~93~002140001*GE~1~600000214*IEA~1~600000198*

Figure 2-2 Sample EDI Document (wrapped)

Identifiers, Separators, and Terminators

The document is arranged into rows of data and in each row are many pieces of data. Each row is called a segment. Each piece of data is called an element. Each row starts with a segment identifier. In the case of the above examples the identifiers tell the translator what kind of
9

segment is being read, which determines what type of data is being read. The translator uses the tilde (~) to know where one piece data ends and the next one begins. This is called an element separator. The asterisk (*) tells the translator where one segment ends and the next one begins. This is called a segment terminator. This is necessary because not all EDI documents are sent wrapped. The translator knows that the first segment will always be ISA and the last will always be IEA (more on this later). The actual symbols used as separators and terminators can be almost any symbol or punctuation character (also known as extended ASCII characters) and will be defined by the trading partners.

Segments
Lets take a closer look at an EDI segment. Figure 2-3 is an example of an EDI segment. This is referred to as the PO1 segment. It contains 15 elements. We know it is the PO1 segment because the first element in this segment reads PO1. In an unwrapped document it is easy to see where the segment begins but in a wrapped document it is not. In either case it is the data immediately following the previous segment terminator, in this case the asterisk (*) on the prior line (see figure 2-1 or 2-2).

Elements
The data between each element separator, in this case the tildes (~), are the elements. The segment identifier (in this case PO1) is not considered an element so you can tell there are 15 elements by counting the data or spaces between element separators. Occasionally you will see two separators together with no data between. This is because there is no data required or available in that spot, but they count. This is not done when the empty elements fall at the end of a segment, so the last element with data will always be the last element in a segment.

PO1~~80~EA~5~~UP~999999999999~VA~XXXXXXXXX~CB~9999999~BO~001~IZ~33902*

Figure 2-3 EDI Segment Every element in a segment is identified by its segment identifier and its position in the segment. For example, the 80 in the segment example in figure 2-3 is called the PO102 element. This is because it is the second element in the segment. You will notice that there are two tildes (~) next to each other right before the 80. The data that would be between those would be the PO101 element. In this case it is not used so it is blank.

Composite Elements
In some cases a data element has several pieces of data associated with it. This is known as a composite, or sub, element. This means it is a single element that contains multiple pieces of data. This requires the element to be broken down into composite elements. These are separated by what is known as a composite element separator. Figure 2-4 is an example of an EDI segment that uses composite element separators. In this case a colon (:) is being used.
10

CLM~XXXX0000~67~~~11::1~Y~A~Y~Y~B*

Figure 2-4 EDI Segment with Composite Element Separators Lets take a closer look at the CLM05 element (~11::1~) in figure 2-4. The rules for identifying composite elements are the same as the rules for indentifying regular elements. The 11 in the element is the CLM0501 composite element. The CLM0502 composite element is empty and the CLM0503 composite element contains a 1. The same as with elements, the last composite element is the last one with data.

Control Envelopes
There are certain segments that are always contained in every EDI document. These are known as control envelopes because they have a beginning and ending segment with other segments in between. If you look back at figure 2-1 you will see that the first segment is identified as ISA and the last segment is identified as IEA. These segments are known as a control envelope because every other segment falls within them. Figure 2-5 shows an example of how the control envelopes work. The other segments have been replaced with two pipe (|) characters to simplify the example. There are 3 control envelopes that occur in an EDI transmission: the Interchange, the Group, and the Transaction. The Interchange Envelope begins with the ISA segment, otherwise called the Interchange Control Header. This is terminated with the IEA segment, appropriately named the Interchange Control Trailer. The Group Envelope commences with the GS segment, otherwise named the Functional Group Header, and terminates with the GE segment, called the Functional Group Trailer. The lowest level envelope is the Transaction Envelope. This starts with the ST segment, called the Transaction Set Header, and ends with the SE, the Transaction Set Trailer.
ISA~00~ ~00~ ~12~5557260541 ~12~5556288340 ~090408~2206~U~00401~600000198~0~P~:* GS~PO~15557844480~5557260541~20090408~2206~600000214~X~004010VICS* ST~850~002140001* | | SE~16~002140001* ST~850~002140002* | | SE~34~002140002* GE~2~600000214* GS~PC~15557844480~5557260541~20090408~2206~600000215~X~004010VICS* ST~860~002140003* | | SE~29~002140003* ST~860~002140004* | | SE~42~002140004* GE~2~600000215* IEA~2~600000198*

Figure 2-5 Sample EDI Control Envelopes

11

Interchange Control Envelope (ISA IEA)

An EDI transmission can contain many EDI documents. The control envelopes are used to group and arrange these documents. The Interchange envelope contains the entire transmission, so the ISA is always the first segment in the transmission and the IEA is always the last segment. There is only one occurrence of each in any EDI transmission. The ISA is a special segment in the sense that is always must contain 106 characters. This is because translators use this segment to figure out how to read the transmission. The very first characters that an EDI translator looks for in an EDI transmission are ISA. If it does not see these first it doesnt see the document as an EDI document. Different translators handle this differently but most advance to the next document (or transmission) and attempt to read it. Directly after the ISA it looks at whatever symbol is in the fourth position and reads this as the element separator. In our example it is a tilde (~) but this is something that is set by the trading partnership and can be almost any extended character. When it gets to the 105th character (:) it sees that as the composite element separator. The 106th character (*) is then the segment separator. In this way it knows how to read the rest of the transmission. These characters are highlighted in figure 2-6. ISA

~00~

~00~

~12~5557260541

~12~5556288340

~090408~2206~U~00401~600000198~0~P~

Figure 2-6 Characters translators use to learn to read the EDI document

:*

The ISA envelope encompasses the entire transaction between the ISA segment and the IEA segment. The ISA segment contains control numbers and trading partner addresses and dates and EDI versions etc. This is explained further in the advanced EDI eBooks. It is important to note that the IEA segment will contain the same control number as the ISA segment so the translator can match them up.

Group Control Envelope (GS GE)

Within the ISA envelope is the group envelope, or the GS envelope. There can be multiple group envelopes within the ISA envelope. Transactions are grouped together by type. All purchase orders, or POs, will be in the same group with no other types of transactions mixed within (refer to figure 2-5). The GS01 element states what type of transactions will exist within the group. The GS segment does not have to be any specific length but must contain all of the data. The GS segment mainly consists of trading partner addresses, dates, versions, document type info and control numbers. The GE segment shows the end of the specific group envelope and is matched by the same control number. After the GE another group may start or, if it is the last group, it will be followed by IEA segment.

12

Transaction Set Control Envelope (ST SE)

Within the group envelope is the transaction set envelope. This envelope contains the actual transaction (810, 850, 856, etc). It starts with the ST segment and is ended by the SE segment. The ST01 will contain the 3 digit EDI transaction code (850 for purchase order, etc). All of the segments between these two segments constitute the actual transaction itself. In figure 2-5 these are represented by pipe characters (|) as this section only deals with the envelopes themselves. There can be multiple transaction set envelopes within each group envelope (refer to figure 2-5). The control numbers in the ST and SE will match up. After the SE segment there can be another ST, beginning a new transaction or if it is the last within the group it will be followed by that groups GE segment.

Summary
An EDI document is broken into segments which are indentified by their segment identifiers, such as PO1, ISA, etc. The segment terminator is used to delineate one segment from another. Each segment is composed of elements which use element separators to separate one element from the next and to position them properly within their segment. Some elements contain multiple pieces of data and these are called composite elements. These use composite element separators (also known as sub element separators) to distinguish between each composite element and place it in its proper position within the element. The entire transmission is wrapped by an Interchange Control Envelope which begins with an ISA segment and ends with and IEA segment. The ISA segment is used to tell the translator how to read the transmission and identifies the sender and the receiver. The IEA segment terminates the transmission. Within the Interchange Control Envelope are the Group Control Envelopes which are used to sort the transactions within the transmission by document type. These start with the GS segment and end with the GE segment. There can be many groups within the interchange. There will be a group for each transaction type contained within the transmission. For example, if there were a purchase order and a ship notice contained within the same interchange there would be two Group Control Envelopes within that Interchange Control Envelope. Within each Group Control Envelope are the Transaction Set Control Envelopes. These start with the ST segment and end with the SE segment. There is one envelope for every transaction. There can be multiple transaction sets within each group, depending on how many of that type of transaction is sent within the interchange. If there were two purchase orders in the above example there would be two Transaction Control Set Envelopes within that Group Control Envelope. In the next chapter we will discuss how to read the actual data using the EDI guidelines to decipher the transactions.
13

Chapter 3: EDI Guidelines

Just knowing how EDI documents and transmissions are formatted doesnt tell us what they are saying. We can see that there is a pattern to how they appear but we still need to be able to define what each piece of data means and what its purpose is. This is what EDI guidelines are for. Sometimes they are referred to as implementation guides, sometimes EDI map guides, sometimes retailer or trading partner guidelines, but they are all the same thing. They define which segments will be in a document, how the segments can loop inside of the document, and which elements will be inside of each segment.

14

EDI Definitions Hierarchy

First, lets take a look at where the guidelines come from. Earlier we went over all of the agencies that define EDI. The top level is ANSI ASC X12. At this level, all of the possible transactions, segments, and elements of data are defined for all industries. It is determined which segments can go in any given transaction and which elements can go into any given segment and which composite elements can go into any given element. This is also where more detailed definitions are made in each area, such as size, data type, etc. Definitions at this level tend to be less restrictive as this is the highest level that all other EDI definitions fall within. There are several industry specific groups that fall under the ANSI ASC X12 group. Lets look at the retail industry. The agency that deals with the retail industry is known as VICS (The Voluntary Interindustry Commerce Solutions Association). VICS has started with the ANSI ASC X12 guidelines and narrowed the definitions down to what is appropriate in the industry they serve. VICS has selected the transactions, segments and elements that will be used within the industry they represent. VICS has created a set of guidelines for each transaction. In any specific industry, such as retail, those agreeing to utilize EDI in their business processes are known as trading partners. A major retailer may decide to purchase products from a certain manufacturer and ask that all of their business is conducted via EDI. The retailer will want to send EDI purchase orders to the manufacturer and want the manufacturer to send EDI ship notices and invoices back when the product is shipped. This is a very simplified example of EDI business flow. In order to accomplish an EDI business relationship, the EDI business rules must first be agreed upon. In the retail industry, normally the retailer (who is the customer) will require the manufacturers and distributers they purchase from to be compliant with the procedures they set up. This includes, but is not limited to, all of the EDI rules. The retailer will supply their own version of the EDI guidelines they want followed. These guidelines will generally fall within those of their industry (in this case VICS) and will always fall within the ANSI ASC X12 standards.

Entity Specific EDI Guidelines

Different retailers may implement their own EDI rules in seemingly vastly different ways, but they will all normally fall within industry standards. Typical retailer guidelines will explain how the transaction is to be used and give you an overview of their entire EDI program. The guideline will also show which segments and elements the retailer wishes used within the transaction.

Transaction Segment Overview

Normally EDI guidelines will start with an overview of the segments used within the transactions. Figure 3-1 shows an example of this. The purpose of this is to show how the transaction will be structured. In this example you see the document is split into a header, a detail and a summary section.
15

The header section contains an ST segment, a BEG segment, a CUR segment, two REF segments, a SAC loop containing a SAC segment, two DTM segments, and finally an N1 loop containing an N1 segment. The detail section contains a PO1 loop, which contains a PO1 segment. Also contained within the PO1 loop is a CTP loop, containing a CTP segment and a CUR segment, and an N9 loop, containing an N9 segment and an MSG segment. The summary section contains a CTT loop with a CTT segment and ends with an SE segment. At this point it is okay not to know what all of the segments mean since the purpose of this is to demonstrate how the EDI guidelines define the transaction structure. We will explore all of these specific segments in the advanced EDI eBooks.

Loops
What are loops? Loops are segments that can be repeated either singularly or in groups. Loops have also been defined at the ANSI ASC X12 level and redefined all the way down through each agency. Loops can exist within loops as well. In figure 3-1 we have a PO1 loop. If you look under Loop Repeat you see it can be repeated 100,000 times. This loop starts with a PO1 segment. This segment can only occur once in each loop. Remember, though, there can be 100,000 loops of this so you may see up to 100,000 PO1 segments in the EDI transaction. Each one will be followed by the other data in the loop, however. In this case there are two other loops within the PO1 loop. There is a CTP loop, which can occur more than once, and there is an N9 loop which can occur up to 1,000 times. Within the CTP loop is a CTP segment (which begins this loop) and a CUR segment. Within the N9 loop is an N9 segment (which begins this loop) followed by an MSG segment. This means that for every one of the possible 100,000 PO1 segments they could be followed by several CTP and CUR segments followed by up to 1,000 N9 and up to 1,000 MSG segments each. There could be up to 100,000 loops like this.

Transaction Overview Column Headings

Lets look at some of the other columns in figure 3-1. Most of the time you will see all of the data included in figure 3-1 in an entitys guidelines, but not always. In fact, each entity will show whatever amount of detail they feel is appropriate. Sometimes you only get a table of contents showing where each segment is defined.

16

Heading:
M M Used Used Used Pos. No. 010 020 040 050 055 Seg. ID ST BEG CUR REF REF Name Transaction Set Header Beginning Segment for Purchase Order Currency Reference Identification Reference Identification LOOP ID - SAC Used Used Used 120 150 155 SAC DTM DTM Service, Promotion, Allowance, or Charge Information Date/Time Reference Date/Time Reference LOOP ID - N1 Used 310 N1 Name O 1 O O O 1 10 10 200 Req. Des. M M O O O Max.Use 1 1 1 >1 >1 25 Loop Repeat Notes and Comments

Detail:
Pos. No. M 010 Seg. ID PO1 Name LOOP ID - PO1 Baseline Item Data LOOP ID - CTP Used Used 040 043 CTP CUR Pricing Information Currency LOOP ID - N9 Used Used 330 340 N9 MSG Reference Identification Message Text O O 1 1000 O O 1 1 1000 Req. Des. M Max.Use 1 >1 Loop Repeat 100000 Notes and Comments n1

Summary:
Pos. No. Used M 010 030 Seg. ID CTT SE Name LOOP ID - CTT Transaction Totals Transaction Set Trailer Req. Des. O M Max.Use 1 1 Loop Repeat 1 n2 Notes and Comments

Transaction Set Notes

1. 2. PO102 is required. The number of line items (CTT01) is the accumulation of the number of PO1 segments. If used, hash total (CTT02) is the sum of the value of quantities ordered (PO102) for each PO1 segment.

Figure 3-1 Sample Segment Usage Guidelines

17

You will notice down the left hand side of the page there is an untitled column containing an M or Used designation. This designates how this particular retailer wishes the segment to be used. M means the segments usage is mandatory and Used indicates that the retailer uses the segments. Next you see the Pos. No. heading. This is a programmers reference and shows the segments relative position within that section of the transaction. The Seg ID heading means segment ID and gives the EDI segment identifier. The Name heading shows the segment name, or loop name as appropriate. The Req. Des. heading tells us the usage requirement for that segment, in this case by VICS standards. M means mandatory and O means optional. The segment definition portion of the guidelines will be more specific on the usage requirement. The Max Use heading tells us how many times each individual segment can be used. A number means this can be used up to this many times. A greater than sign means it can be used that many times or more (>1 means 1 or more times, 1,000 means up to 1,000 times). If a segment is designated as mandatory it must be used at least once. If a segment is within a loop, the designation refers to its usage within that loop.

Transaction Notes
There are also usually general notes that the entity includes in this section to alert you to any special needs or requirements that exist. In figure 3-1 the designation n1 and n2 refer you to note #1 and #2 at the bottom of the page. These notes are generally repeated on the page that contains the segments detailed definition.

Segment Definitions
Generally there is a section for each included segment that defines all of the elements used within that segment and what the data should contain. Figure 3-2 shows an example of this with the PO1 segment. Figure 3-3 shows the actual PO1 segment that is being referred to. We will go between these two figures to explain how the guidelines define the segment.

Segment Definitions Heading

In figure 3-2 lets first look at the heading information. It tells us that this is for the PO1 segment and this is the Baseline Item Data or line item. It also tells us that this is the detail level of the transaction. The loop information sates that this is the PO1 loop, its usage is mandatory and there can be up to 100,000 occurrences of this loop within the transaction.
18

Segment: PO1 Baseline Item Data Level: Detail Loop: PO1 Usage: Mandatory Entitys Usage: Mandatory Max Use: 1 Purpose: To specify basic and most frequently used line item data. ---- Data Element Summary ---Ref. Data Element Des. PO102 330 PO103 355

Max Use: 100000

PO104 PO106

212 235

PO107 PO108 PO109 PO110 PO111 PO112 PO113 PO114 PO115 PO116 PO117 PO118 PO119 PO120 PO121

234 235 234 235 234 235 234 235 234 235 234 235 234 235 234

VICS Attributes Name Quantity Ordered C R 1/15 Unit or Basis for Measurement Code O ID 2/2 EA Each AS Assortment (multi-item pack) Unit Price (Cost) C R 1/17 Product / Service ID Qualifier C ID 2/2 UP UPC Code Universal Product Code EN EAN European Article Number VA Vendors Style Number CB Buyers Catalog Number BO Buyers Color (NRF) IZ Buyers Size (NRF) IN Box ID (for shoe orders only) TP Product Type Code (Gender Classification Code for shoe orders only) Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48 Product / Service ID Qualifier C ID 2/2 Product / Service ID C AN 1/48

Notes:
Entity can send any number of the codes listed for PO106 depending on the information in the Entitys system. These codes can occur in any pairing of Product/Service ID and Qualifier from PO106 through PO121. If the Product/Service ID field contains CB , then the Product/Service ID Qualifier contains Entitys department, major class and sub class. This information should be used in preticketing, example: CB*9998877. PO104 will contain the Pack cost when PO103 has AS. When PO103 is AS then PO106 VA is the pack style. SLN09 loop will then contain the vendor style for the items. Price in the PO104 will be sent with a decimal point when there are cents included in the cost. Example: If $15.95, send as 15.95. If $29.00, send as 29 with no decimal point. An AS in PO103 represents an assortment pack. Component item details will be sent in the PO1/SLN loop. When PO103=AS then PO106 UP is an Entitys assigned prepack UPC and CB is Entitys SKU # (CB*9998877). SLN09 loop will then contain trading partners component item UPCs.

Figure 3-2 Sample Segment Detail Guidelines

19

PO1~~80~EA~5~~UP~999999999999~VA~XXXXXXXXX~CB~9999999~BO~001~IZ~33902*

Figure 3-3 PO1 Segment

Below the loop information you will see where it says Entitys Usage. In our example the name of the actual retailer is replaced by the term entity. This states that our retailer deems this segment within the PO1 loop to be mandatory, you must use it. Note that here it says the max. use is 1. This means that this segment may be only used once within the loop. Since the loop can be used 100,000 times within this transaction there can be 100,000 PO1 segments in the transaction, they each will constitute their own PO1 loop. The Purpose indentifies what this segment is and why it is used.

Data Element Summary

Looking at the section under Data Element Summary in figure 3-2 we see the detailed information for each element within the segment. This section is arranged in columns which describe individual details about each data element. Lets take a look at each column and discuss what they are.

Segment Definitions Column Headings

Looking at figure 3-2, we see the first heading is Ref. Des. which is the reference designation of the segment (i.e. PO102, PO103, etc.). Data Element is the next heading and this refers to an index number that is assigned to this element within the ASC X12 definitions. This defines the element itself in detail but it is usually not necessary to look this up as the definition within the guidelines is sufficient to understand the element. This is placed here for reference purposes only. The next heading we encounter is Name. This gives us the name of the segment. It is also used to give the entitys valid values for this element and what they are (note the writing in bold under this heading). The last heading we see is called VICS attributes. These describe how the data is formatted. First is the requirement code. O means optional, C means conditional and M means mandatory. These are VICS attributes and may differ from the entitys requirement. Conditional refers to an element that is only used under certain conditions. The terms optional and mandatory are self descriptive. The next attribute is the data type. R means the data is some form or number. AN means the data is a text type. ID means the data is some type of identifier. DT means the data is a date. There are many more types of data that can be defined. The last attribute is the data size. It is normally formatted minimum size/maximum size. 1/15 means it can be 1 to 15 characters long. 2/2 means it must be two characters in length.
20

Segment Notes
The last part of the segment definition is the notes. The notes are used to more clearly define any aspect of the segment data that the entity feels may require further explanation. The notes are very important to understanding the data in the segment. As an example, in figure 3-2, the fifth note about how the price will be formatted helps you understand when to use a decimal point and when not to.

Reading the EDI Segment

Now lets look at figure 3-3 and compare it with figure 3-2 to understand what the data means. In figure 3-3 the first element, PO101 is blank. As you can see in figure 3-2 there is no definition for PO101 so that means this element is not used. Some guidelines may define it and then say NOT USED to signify that it is not used. Some entities may use this element, which is why you must obtain the guidelines for the entity you are doing business with. In figure 3-3, PO102 has a value of 80. Looking at the guidelines in figure 3-2 we see that this element is Quantity ordered. We see it is conditional and that it is a number and that it can be between 1 to 15 characters long. Therefore, the quantity of this line item is 80. Figure 3-2 shows PO103 as the unit of measure and it goes on to state that valid values are either EA for each or AS for assortment. Figure 3-3 has EA as the value so we know that there are 80 eaches, or individual units. We also see that this is an ID field that is optional and must be 2 characters long if used. This field indentifies the value in PO102 as to what kind of quantity it is referring to. By VICS and ASC X12 standards it may be optional to use this element but since the entity states that you can either have EA or AS as a value to this field we know that there MUST be data here, so it is effectively mandatory by the entitys standard. Looking back at figure 3-3 we see the next element, PO104, has a value of 5. In figure 3-2 we see that this element is defined as the unit price and it is numeric and can be from 1 to 17 characters long. Therefore, 80 items have been ordered that are $5.00 each, as per the fifth note. Figure 3-2 shows that PO105 is not used and figure 3-3 has it blank, so lets look at the next two elements together. Figure 3-2 reveals that PO106 is a 2 digit Product/Service ID qualifier. Normally, a qualifier describes what the data in its following element represents. Looking at the entities acceptable values for this field describes what the data in PO107 is. For example, if PO106 has a value of UP then the value in PO107 is the UPC code. In the case of figure 3-3, PO106 is UP so the 999999999999 in PO107 is a UPC code. Looking at figure 3-2 we see that PO108 to PO121 are further instances of the same pairing as PO106 and PO107. The first note states that these elements can be used as much as necessary to describe the product. In the case of figure 3-3, we see that PO108 and PO109 describes a vendors style number as XXXXXXXX. PO110 and PO111 describe a buyers catalog number of
21

9999999. PO112 and PO113 describe a buyers color (NRF) of 001. Finally, PO114 and PO115 describe a buyers size (NRF) of 33902. All of these pairs are conditional because one is only required to be there if the other exists. Therefore the segment reads: 80 items that are UPC 999999999999 which is also vendors style XXXXXXXX and is also buyers catalog number 9999999 and is NRF color 001 and NRF size 33902 and cost $5.00 each.

EDI Mapping
Once you know how to read the EDI documents, you can then map them into your production systems. EDI mapping is the process of taking the data from your EDI documents and putting them into a format that your production accounting and shipping programs can read. It is also the process of taking data from your applications and creating EDI documents with them. This is mainly a higher level function that your EDI expert or programmer will perform. This is how your translator talks to your systems.

Summary
The guidelines define the entire EDI transaction. They also describe how to implement the transaction within the business process. An EDI programmer or analyst uses the guidelines to create a map that will take the data from the EDI transaction and puts it into some usable format that can be processed. The EDI programmer or analyst will also use the guidelines to map data from an application to create an EDI document that goes out to the trading partner. This is called EDI mapping. If you were to use the example data from this chapter, the PO would be mapped to some application and when the PO is filled and shipped the data can be used to create a ship notice, an invoice, and maybe even shipping labels. In the next chapter we will review several models of how EDI is used in different industries and show simple examples of their transaction flows and what they represent.

22

Chapter 4: EDI Business Models

In this section we will look at three different business models in which EDI is used. This will give us a better understanding of how EDI is used in a real business environment and will help us understand how to best implement the process. We will look at a simple manufacturer to retailer trading partnership. We will also look at a small medical office billing insurance companies. Finally we will look at a third party logistics company doing inventory maintenance and shipping for a manufacturer. All of these examples are very simplified. The scope of this beginners eBook is just to give examples of EDI usage in a real world environment. The more advanced eBooks look in detail at EDI usage in each specific industry.

23

Retail Model
First lets look at a manufacturer retailer trading partnership. Figure 4-1 shows us ABC Mfg. doing business as the manufacturer with XYZCO, as the retailer. XYZCO has mandated the use of EDI. This means ABC Mfg. must be able to accept various documents and must also maintain a UPC catalog online with TUV Inc, who is an online UPC catalog provider.

TUV Inc. Online UPC Catalog provider

832 UPC

Proprietary
ABC Mfg. Manufacturer

850 PO 856 ASN 810 INV

XYZCO Retailer

Figure 4-1 Manufacturer/Retailer EDI Business Model

In figure 4-1 we see that the first part of this simplified model is ABC Mfg. sending an 832 EDI document to TUV Inc. The 832 is known as a Price Sales Catalog. This is the document used in EDI to maintain ones UPC catalog. This document specifies UPC codes for each product. It is also used to maintain color, size, price, physical descriptions and other product information for each UPC. Pictures can also be uploaded to most catalogs, but not through the 832 document. There are many providers who maintain online UPC catalogs and generally the retailer will specify which catalog a manufacturers UPC catalog must be kept on.
24

You will notice that there is a connection, in our model, between TUV Inc (the online UPC catalog provider) and XYZCO (the retailer) labeled as proprietary. A retailers buyers normally use a program that allows them to view their manufacturers UPC catalog and to create orders based on their selections. Different retailers and catalog providers use different programs and this connectivity is not usually done via EDI documents, but it is used to create the EDI Purchase Order.

In figure 4-1 we see XYZCO next sends an 850 Purchase Order (PO) to ABC Mfg., based on their selections from the UPC catalog. This document normally tells the manufacturer what the retailer wishes to purchase, the quantity of each item, which stores to pack each item/quantity for, which distribution centers (DC) to ship goods for each store to, and when they must be shipped. Once ABC Mfg. receives the 850 PO, they use this data to manufacture and pack their goods for shipment. In most cases manufacturers will be required to place a carton packing label on each carton or pallet or bag they are shipping. This label will contain a serialized, unique carton number. Most retailers have their own requirements on how this label must be formatted and they provide the manufacturers with this information along with the EDI guidelines. We will go into more detail about these labels in the advanced EDI eBooks for the retail industry. The only reason we are mentioning it here is because the next document, the 856 advanced ship notice (ASN), is normally integrated with this label through the carton number. Immediately upon shipping, the manufacturer sends the 856 ASN to the retailer. The manufacturer will pack everything by store and ship everything by DC. Usually there is one ASN per distribution center required. The ASN is routed to the DC and contain information for all the stores within the shipment. Under each store there are the containers listed which are packed for that store, indexed by the carton numbers on the carton labels. Under each container is listed exactly what is packed within that container. ASN data is fed into the retailers systems. When the containers reach the DC, the carton label is scanned and the carton number is used to identify which store the container should be routed to and exactly what has been received. This automates the routing and inventory systems at the retailers DC. For this reason, it is normally required that the ASN reach the retailers system prior to the goods arriving at the DC. At this point, the manufacturer also sends the 810 Invoice (INV). In fact, the invoice and the ASN are usually created and sent together. Invoices can be split into one invoice per store or one consolidated invoice per shipment (or DC). The invoice is the bill to the retailer. The retailer will pay the manufacturer based on the agreed upon terms once they have received the 810 into their system.
25

The manufacturer/retailer EDI model displayed in figure 4-1 is a greatly simplified version and only includes the basic elements. Normally, other supplementary documents are used in conjunction with these main documents. This will be covered more completely in the advanced editions of the EDI eBooks.

Medical Billing Model

Another good example of an EDI business model is within the medical industry. Generally the medical industry is split into three main categories: patients, providers, and payers. The patient is the party receiving the medical treatment; the provider is the party providing the medical treatment; the payer is the party who pays for the medical treatment. The patient and the payer can be the same party, but generally the payer is one or more insurance companies who pay for the patients medical expenses. The provider typically bills the payer for services rendered to the patient. Figure 4-2 shows a basic EDI flow for this business model. The main EDI documents used in this process are the 837 Health Care Claim and the 835 Health Care Claim Payment/Advice. There is a professional version of the 837 and an institutional version. There are also 837 versions for dental providers and for medical equipment and devices (such as prosthetics or oxygen machines). The professional version is typically used by private providers and groups. The institutional version is used by hospitals and other institutions. The 837 is a very complex document and can contain billing for multiple patients and multiple providers for a single payer. Typically, a providers office includes several medical providers that see multiple patients in any given period. They will usually do their billing on a daily or weekly basis, creating bills for each payer containing all the procedures performed by all the providers on all the patients for that payer in that time period. 837s are normally sent one to each payer from each office for each billing period. The 837 is arranged in loops. These loops are referred to by number when referencing the EDI document. The loops are hierarchal in nature. There is the header loop which contains the billing provider information and the payer information; there is the provider loop which contains the provider information; there is the detail loop which contains the procedure and diagnosis information; and finally there is the subscriber/patient loop which contains the insurance subscriber and patient information. The payer will normally send each provider an 835 outlining what they will be paying and how much they will pay for each procedure. Each payer has their own payment cycle and sends the 835 based on this cycle. This is an ongoing process based on the providers and payers billing and payment cycles. Each provider normally deals with multiple payers. Figure 4-2 shows this model from the perspective of a provider billing multiple payers on a weekly billing cycle.
26

Weekly Billing
ABC Medical Group 837 CLAIM 835 ADVICE Payer 1

837 CLAIM 835 ADVICE

Payer 2

837 CLAIM 835 ADVICE

Payer 3

837 CLAIM 835 ADVICE

Payer 4

Figure 4-2 Professional Health Care Claim EDI Business Model

As in the previous example, this is a simplified version of the health care claim business model and there are other supplementary documents that can be used as well as these main documents, such as claim status and insurance verification documents.

Third Party Logistics (3PL) Model

Finally lets look at a typical Third Party Logistics Company (3PL) inventory management model. In this model ABC Mfg. hires DEF Logistics to hold and manage their inventory. This includes shipping to their retailers, which includes all of the labeling, packing, and reporting requirements. This also requires the 3PL to manage the inventory levels for ABC Mfg. Figure 4-3 shows an example of how this business model works with its EDI flow. The 3PL model can be said to be a 3 phase process. First, there is the receiving phase in which the 3PL receives goods from their customer. Next, there is a shipping phase where the 3PL will ship goods for their customer. Finally, there is an inventory management phase where the 3PL manages the inventory for their customer. ABC Mfg. works the same way as in figure 4-1 when dealing with their retailer. On the other side, however, they have DEF Logistics holding and shipping their inventory. ABC Mfg needs to ensure that DEF Logistics has the necessary goods in stock to fulfill their orders, so
27

they always need to be aware of the inventory. When ABC is expecting an order from XYZCO or one of their other retailers and they determine that DEF Logistics isnt holding enough inventory, they need to make sure that this is shipped to DEF Logistics in enough time to fulfill the order. Typically, ABC Mfg. will send a 943 Warehouse Stock Transfer Shipment Advice or an 856 Advanced Shipment Notice (ASN) to DEF Logistics itemizing what is being sent to them. Either document can be used. The only difference is that the 943 is more of a shipment summary, showing only how many of each item was shipped and an 856 gives packing level detail. When DEF Logistics receives the goods itemized in the ASN they send a 944 Warehouse Stock Transfer Receipt Advice (or just receipt for short). This is a very straightforward document but the 3PL uses it to update their inventory and ABC Mfg. uses it to update their inventory as well. When ABC Mfg. receives an 850 Purchase Order (PO) from their retailer they send a 940 Warehouse Shipping Order (or just order for short) to the 3PL. The 940 tells the 3PL what and when they should ship and to which retailer store and DC, much like a PO. The 3PL then prepares the shipment based on the 940.

DEF Logistics 3PL

856 ASN or 943 Ship Advice

ABC Mfg.

3PL Receiving
940 Order 850 PO 856 ASN 945 Ship Advice 810 INV

XYZCO Retailer

3PL Shipping
944 Shipping Receipt 947 Inventory Adjustment 846 Inventory Advice

3PL Inventory
Figure 4-3 3PL Inventory Management EDI Business Model Once the shipment is packed and ready to ship, the 3PL ships the goods to the retailer and sends a 945 Warehouse Shipping Advice (or just ship advice for short) to ABC Mfg. This document advises ABC Mfg. on exactly what was sent to the retailer. This is very similar to an ASN in that it lists all carton numbers and itemizes the packing. This is necessary because the
28

manufacturer will use this document to create its own 856 ASN and 810 INV to send to the retailer. It is very important for the manufacturer to always be aware of the inventory levels at the 3PL. Although the 3PL sends the 944 whenever they are in receipt of goods, and this should update the inventory in both places, and the 3PL sends a 945 when they ship goods, which also updates inventory in both places, there is always the possibility of error. For this reason two more documents are used. The 846 Inventory Advice is used either in a predetermined cycle (i.e. monthly or weekly), or when the manufacturer requests one. This document is simply an inventory report that reflects the entire inventory held by the 3PL for the manufacturer. The other document is a 947 Inventory Adjustment. This document is used when it is determined that the inventory held by the 3PL does not match what the manufacturer thinks they should have. There are many ways this could happen. The manufacturer could ship the wrong thing to the 3PL or items could be damaged and therefore unsellable. The 3PL could make a mistake on a 944 or ship something incorrectly. In any event, the 947 is designed to send corrections with reasons from the 3PL to the manufacturer. Of course, as with all of the models we have discussed here, this is a simplified view of the 3PL inventory management model and there are many additional transactions that could be used here.

Functional Acknowledgement (997)

The 997 Functional Acknowledgement (FA or ACK for short) is one subject we havent mentioned that you will see in every EDI scenario from the beginning. Anytime any EDI document is sent a 997 is generated and sent back. Usually this is a feature that is automated within a translator. The 997 will reference the envelope control numbers of the document it is acknowledging. When you receive a 997 it means that your document was received. When you receive a document your translator should send a 997. Translators normally check for proper EDI syntax of a document so a 997 could say that a document was received but it was either rejected, in error, or accepted. At this level only the EDI syntax has been checked so you could have a 997 say a document was accepted but the document could still be rejected as being in error by your trading partner. For example, if you have the wrong prices on an invoice, as long as the EDI is correct the 997 will accept it. The accounting department of your trading partner will probably reject the invoice. In this case you could receive another type of EDI document or even a call from your trading partner. Sometimes the 864 Message Transaction Set is used. This is a general document used in almost
29

every industry to send general messages out. The 864 could be used to announce store openings or closings, errors in EDI documents, business closed dates, service interruptions, address changes, and the like.

Summary
We just reviewed only three types of EDI business models: retail, medical billing, and third party logistics. There are more EDI business models than what we have described here. EDI is also used heavily in the automotive industry, the marine industry, and the construction industry, just to name a few. The purpose of this eBook is just to give you a basic understanding of how to apply EDI in a business environment.

30

Chapter 5: EDI Implementation

Now that we have a good understanding of what EDI is, how it is defined, and how it is used we need to understand how to implement our own EDI system. There are many ways to implement EDI into your business. The range of possible implementations goes from simple third party providers to completely customized in-house systems. The cost and capabilities vary greatly as well.

31

Cost Considerations
There are many things to consider when determining how to implement a system. Of course, the most important thing to consider is the bottom line - how much your system will cost to implement and maintain versus how much increase in revenue you will generate with your system. If you do a large amount of EDI transactions on a daily basis with many of your customers, then you will want to invest in a system that has a high level of automation. You will want to set up your system as an in-house system and create programs, scripts and procedures that will automatically pull data into your account and shipping systems and eliminate data entry. The more data entry you have in your system the more chance there is of human error and the higher your operating costs will be. Of course, if you do not have many customers that require you to use EDI you may be able to get by with using an online service. Online services are more generic. You can get data files but it usually requires human intervention to download them and enter them into your accounting systems. This adds an extra possibility of creating errors and your operating costs are higher to pay the employee to do this for you, or in time to do it yourself. Also you will usually have to pay some sort of subscription charge for the online service.

Technical Considerations
In deciding how to proceed with implementing your EDI system, you also need to consider the technical requirements you will need to fulfill. The first thing you should look at is how documents are actually delivered between trading partners. In Chapter 4 we looked at how various documents flow between trading partners from a business perspective. Figure 5-1 gives you examples of the various ways trading partners actually connect to deliver documents back and forth.

In-house Systems and VANs

Figure 5-1 displays ABC Companys trading partnerships. ABC Company has four trading partners. Each trading partner communicates with ABC using different methods. ABC also has two VANs, or Value Added Networks. A VAN is sort of like an EDI mailbox provider. Most retailers, insurance companies, transportation carriers, or anyone who is requiring you to do EDI with them has a VAN they subscribe to. If you need to pick up documents from your trading partners VAN you will probably need to subscribe to that VAN. If you already have a VAN chances are you will be able to interconnect with the other VAN through yours. In figure 5-1 lets look at the connection between ABC Company and Trading Partner 1. Trading Partner 1 has its own VAN that is not one of ABC Companys VANs. For this reason ABC Company has setup an interconnect between their VAN 1 and Trading Partner 1s VAN. All

32

ABC Company EDI Implementation

ABC Company VAN 1

Trading Partner 1 VAN

Trading Partner 1

ABC Company VAN 2

Trading Partner 2

Trading Partner 3

Trading Partner 4

Figure 5-1 In-house EDI Document Flow Overview documents sent from Trading Partner 1 go through their VAN (Trading Partner 1 Van) to ABC Companys VAN 1 to ABC Company. Documents from ABC Company follow the same path back. The connection between the two VANs is known as an interconnect. Looking at the connection between ABC Company and Trading Partner 2 we see that both sides use the same VAN. This is a normal VAN connection and no interconnect is necessary. Most trading partners connect through VANs so the interconnect and the straight VAN connections are the most common. Lets take a look at the relationship between ABC Company and Trading Partner 4 now (dont worry; well look at Trading Partner 3 last). This is a direct connection between the two companies also known as a B2B, or business to business, connection. There is no VAN in between the two companies. This type of setup is becoming more common as the cost of doing
33

business increases and profit margins decrease. Of course the disadvantage of not using a VAN is the necessity to provide your own security and accountability. Also, it requires you to store all of the transactions on your systems as there is no backup from a VAN mailbox. Looking at the relationship with Trading Partner 3 we see that when ABC Company sends a document to Trading Partner 3 they send it through their VAN and Trading Partner 3 picks it up from the ABC Companys VAN 2. When Trading Partner 3 sends to ABC Company they use a B2B connection. This is a mixed connection. This is pretty rare and there is usually some specific reason for doing this. This is just an example of a mixed connection and it could be configured with an interconnect or the send and receive could be reversed. ABC Company EDI Provider EDI Provider VAN 1 EDI Provider VAN 2 Trading Partner 3 Trading Partner 1 VAN Trading Partner 2 Trading Partner 1

Trading Partner 4

Figure 5-2 EDI Provider Document Flow Overview

34

EDI Providers
Another way to go is to contract with an online provider or EDI service bureau. This usually only recommended if you have a minimal amount of trading partnerships and a small volume of EDI transactions. The upside of an online provider or a service bureau is the cost of maintaining the system is usually limited to the subscription fee. Figure 5-2 shows the connectivity using an EDI provider. The providers connections already exist and you connect directly to the provider. The difference between the provider and the VAN is the provider eliminates the need for you to have your own EDI translator and in-house setup. The provider maintains all of that for you. The downside to an EDI provider is that the human readable reports (printouts of the EDI documents) and the data files provided are usually very generic. The reports tend to be hard to read and the data files require human intervention to enter them into your system. Since the data files are so generic you usually must manipulate your system to be able to load them and sometimes this isnt possible at all so data must be manually data entered. Also it becomes very difficult to integrate your labeling with your EDI document using this method, which can cause many headaches and a lot of lost time in production.

Communication Protocols
Each one of the connections in figure 5-1 could use any type of communication protocol. They could use FTP or bisynchronous modem (yes there still are a few out there) or AS2 or AS3 or any other type. You dont need to know what these are if you hire an EDI expert. You just need to know that this is a consideration that affects the type of hardware and communications software that you will require.

Timing Considerations
Timing is a major consideration when planning your EDI implementation. Usually when you are requested by one of your customers to implement an EDI process they need it to be done as soon as possible. Generally, the process is related to payment. In retail, the buyers will require you to be EDI enabled before they can order from you. Medical payers require you to be able to bill them via EDI. The longer you have to wait to be EDI enabled the longer you may have to wait to be paid. You will want to give yourself as much lead time as possible to get your EDI system into production. It takes a significant amount of time to acquire and set up your translator. You will need ample time to properly implement and thoroughly test any programming or mapping you may require. Once you have your system ready to go your trading partner will typically require a testing phase that could also take a significant amount of time to complete. The whole process could take several months so do not delay beginning the process or it could have financial repercussions to your company.

35

Hire an EDI Expert

It is very important to make the right decisions for your company from the beginning. If you implement a system that does not grow with your company, you may have to scrap that system and start over when you begin doing business with more customers requiring the use of EDI. For this reason it is recommended that you hire EDI experts, such as DBM Consulting Services. You need to have an expert analyze your needs and your budgetary restrictions and to recommend a system that will meet your needs within your budget.

Summary
Implementing a successful EDI system requires a high level of needs analysis and forecasting in order to make your system productive and cost effective. It is important to give your company enough time to implement the system that is right for you. Hiring an EDI expert is something you should consider at this stage of the game. Your expert will analyze your trading partner requirements and your production and accounting processes and recommend the system that is right for you. Initial investments in EDI are usually a little costly and it is not unusual to experience sticker shock when looking at the costs. Remember though, this system will carry you into the future and can have the ability to increase your business volume, and your profits, ten-fold or more. EDI and other electronic commerce technologies will just continue to grow in all industries due to their ability to significantly shorten supply chain, production, and billing cycles and allow companies to respond even more flexibly to their customers needs. This eBook was designed to introduce you to the world of EDI and to explain what it is and how it is used. Though we only show examples of EDI in three industries, this is a beginners guide for all industries. The goal of this eBook is to familiarize you with the world of EDI so that you can effectively implement your own system. Please look for our more advanced eBooks to extend your EDI knowledge.

36