EDI 101 – part II – The Basics of Standards and Syntax
So, you’ve decided to come back for more, eh? Glutton for punishment, I guess.
This time around, we’re going to cover the concepts of the “STANDARDS” and also the SYNTAX and the Content of your EDI Document. Now, again, I’m coming from a background in retail and using the ANSI/ASC-X12 standard. And we use version 4010, which is, arguably, a few versions behind, but that’s not truly important. I know that UN/EDIFACT and TRADACOMS have their own standards and documents, but, again, I’m just dealing with what I know – X12.
For each industry that uses EDI and the standards, there are different forms that can be used. The book on My desk for the X12, v 4010, is the size of a dictionary. And it’s printed on that same super thin paper in tiny little type-face. And it’s almost 1800 pages of that tiny type. But not every document is used in every industry that may use EDI and use the X12 standard. Some are strictly for retailers; some for real estate; some for insurance, for banking, for hospitals. Some of the documents MAY be used across the industrial lines, but some are very specific and specialized.
Within that X12 standard, there are literally HUNDREDS (at least 300 by My count) of documents that can be traded – from the 850 Purchase Order, the 810 Invoice, the 860 PO Change, the 852 Activity Data to the 262 Real Estate Information Report, the 255 Underwriting Information Services and 249 Animal Toxicological Data.
Wow… Who knew?
With TRADACOMS (the Standard used in the United Kingdom for most retailers), there are a couple of dozen. I’m not sure how many documents are in use for the UN/EDIFACT standards, but I’m sure there are a few.
For each document, there are then a series of hierarchy loops – levels, basically – of the information structure. These levels – the hierarchies – lay the data out in a defined pattern, so that you can have similar data “grouped” with similar data. Within those levels, you will have the SEGMENTS and the ELEMENTS we touched on last time. And you can have segments in multiple levels and even repeated within a level, as needs require.
Still there and with Me? Good.
When you come to the hierarchies, they’re going to – GENERALLY – follow a structure or a pattern. Kind of like the e-mail analogy I used last time, where we had a TO, FROM, SUBJECT, BODY and CLOSE, the hierarchies will follow a similar kind of pattern. For example, an 856, the ADVANCED SHIP NOTICE – or ASN – will follow a particular pattern. A very common pattern is called SOPI. SOPI stands for SHIPMENT, ORDER, PACK, and ITEM.
The SHIPMENT hierarchy is all about just what it says – the SHIPMENT information and data. In this hierarchy loop (or level), you’ll find information about the ASN Number, shipment date information, some ship to or ship from information, a bill of lading or tracking number and more. You can specify the kind of container that is being used (corrugated cardboard) and the name of the shipping company, the weight of the shipment, the number of cartons, and so much more information about the SHIPMENT.
Following SHIPMENT, you’ll generally find the ORDER hierarchy loop. This contains information and data, as it pertains to the order information. You’ll find some date references – order date, ship date, arrival/anticipate date, the Purchase Order Number, maybe vendor identification (number, etc.). Again, this hierarchy loop is all about the ORDER information.
Next up, you’ll generally have a PACK loop. Most times, this is a pretty small bit of data. In the ASN spec I use, it’s all about the marks and numbers – the carton label number – for that box. That’s pretty much it. In here, however, there could be any data that refers to the packaging of the products ordered.
Then we’ll see the ITEM hierarchy loop. This is where you’ll find all the data, as you guessed, about the ITEM being shipped in the ASN. Widgets… Shoes… Apples… Whatever… This is all about the goods being ordered and shipped. Everything that’s in that shipment should be listed on the ASN and this is where the item specific detail goes: colors, sizes, quantities, UPCs, SKUs, the works.
Within each hierarchy loop, there are a number of SEGMENTS that contain the elements and the data. Each segment has a name – an identity. Within the ASC X12 standards, it’s generally a 2 or 3 character code that identifies what data should be contained in the SEGMENT. For example, there’s the TD1, TD3, TD4 and TD5 segments. This is where you would – generally – find the information pertaining to the CARRIER DETAIL. Things like who the trucking company is, any routing transit time, special handling, hazardous materials information and more. Or there can be the SN1 segment. This is all about the item detail – the shipment. This segment is where you put in the information – the details – about the item being shipped. Here’s where you can have UPCs, Item Numbers, SKU numbers, Item Descriptions and more – as long as it’s all about the item being shipped.
The SEGMENTS are further split up into DATA ELEMENTS. This is the nitty-gritty detail of the shipment. This is where your content really comes into play. And the STANDARDS also come in here, as the STANDARD lays out what SEGMENTS fall into which hierarchy loops or levels and what elements and data can be included in the segment.
The ELEMENTS are all about the actual detail of the shipment: quantities, PO numbers, costs, UPCs, item numbers, carton sizes, and more, are all displayed in the ELEMENTS in the SEGMENTS. This is the level where you really need to have a keen eye for details, as there may be any one of a dozen possible elements to use to identify the data being sent.
Let’s assume you’re working at the ITEM level and the LIN (Line Item Detail) segment. And you’re trying to get across a VENDORS STYLE NUMBER or designation. There are a number of choices – looks like 4 in the copy of the X12 Standard I use. You can use VA (Vendor’s Style Number) or you can use VC (Vendor’s Catalog Number); or how about VP (Vendor’s Part Number), VN (Vendor’s Item Number) or even VU (Vendor’s Basic Unit Number). Hey! That’s five! Of course, then I also see XA (Preferred Part Number), the MG (Manufacturer’s Part Number) and more and more and more.
In this same SEGMENT, you can also have all the information related to OTHER numbers and information related to the item being shipped – the UPC, the SKU, and so forth. Truly, however, this qualifier (known as the Product/Service ID Qualifier) could be for use in many documents and many segments. It could be used for financial records, medical records, educational records…
This can be where many people who create EDI translation documents have to be really careful. Since there are a lot of codes and qualifiers that could be used to relay the data and information you’re trying to get across, you need to be sure of what you and your trading partners will recognize.
In a previous blog, I talked about the concepts of EDI being replaced by XML; how there’s the DTD/Schema that tells you want the data being transmitted is. Well, that DTD/Schema basically functions as the formal “STANDARD” of the document, even though there isn’t any formal STANDARD with XML… The only “RULE” in XML is that you have a set of tags around each bit of data you’re sending. The DTD/Schema then tells the receiver what it is that this TAG means. Think of the TAG as the ELEMENT QUALIFIER in the SEGMENT of an X12 document.
Even with all of the potential for confusion that can be found in any of the standards, having that standard and set of rules makes EDI something that’s not exceptionally difficult. It can be easy to master, as long as you pay attention to the details and work with your trading partners on the documents you’re trading – from syntax to content – to be sure that the data you’re trading – sending back and forth – is clean, reliable and usable.
Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/