Académique Documents
Professionnel Documents
Culture Documents
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 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.
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.
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.
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*
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*
~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.
12
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
14
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.
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
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: 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
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.
PO1~~80~EA~5~~UP~999999999999~VA~XXXXXXXXX~CB~9999999~BO~001~IZ~33902*
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.
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.
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
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.
832 UPC
Proprietary
ABC Mfg. Manufacturer
XYZCO Retailer
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.
Weekly Billing
ABC Medical Group 837 CLAIM 835 ADVICE Payer 1
Payer 2
Payer 3
Payer 4
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.
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.
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.
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
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.
32
Trading Partner 1
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
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
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