EDI 101-B – Standards and Syntax

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:

Your Mama Don’t Dance and Your Daddy Don’t Rock-N-Roll…

Your mama don’t dance and your daddy don’t rock n roll”… 

Loggins and Messina (Kenny and Jim, respectively) wrote (and sang?) a bunch of years ago.  It was the year of the Bicentennial, no less.  30 years ago…  Wow.  I remember yesterday.

But I digress – like that’s anything new…?

But they sang that so many years ago about somebody that was kind of un-cool, un-hip, not-with-it and behind the times.  Or, rather, their parents were.

But this can also be used today – right now – when talking about EDI.  We all know that EDI has been around for a number of years now – since the 80s.  A few years later than we heard about non-dancing mamas and daddies not into rock n roll…  Many of the standards we use today – ANSI/X12, UN-EDIFACT and TRADACOMS (to name a few) – all started out in the early to mid eighties.  And, in reality, none of them have changed drastically in the intervening years.

Sure, they’ve updated and changed some, but, again, not drastically so.  The basic concepts still exist.  There have been some new documents, some new segments and elements; and there have been some documents, segments and elements that have left, for sure, but they’re still pretty much the same.  For example, ANSI/X12 is updated almost every year, with changes, deletions and alterations made.   Chances are pretty good that TRADACOMS and UN-EDIFACT have changed some, too, since their introduction, but all of these changes have been “evolutionary” rather than “revolutionary” for all of the standards.

But EDI still isn’t the only way to trade documents back and forth.  We’ve still got retailers and suppliers that will continue to send paper documents – POs, Ship Notices, Invoices, and more – back and forth via the fax, using e-mail, snail-mail and other ways of getting the data from source to destination; from A to B, a side trip to H and then back again.

A lot of times, though, we’re dealing with smaller companies – those mom-n-pop establishments that don’t see or feel the need for EDI in their world.  It works just fine for them to call up ABC Company and tell them “send us 100 widgets, please, PO number 12345” and get those 100 widgets in a few days, weeks or whenever they’ve asked for them to be delivered.  And then ABC Company will send them a paper invoice after that and mom-n-pop will send them a check.

Mom-n-pop certainly are not dancing and rock-n-rolling.  Instead, they’re waltzing; or doing the Charleston.  They’re still going “old school” and processing things the way they know how.  But what if we COULD get mom-n-pop to dance and rock-n-roll?  What if they could move forward into the 21st century and start doing that new-fangled “e-commerce thing”…?  Are there ways…?

You bet.

There are a number of EDI “service providers” out there – from big to small – SPS, DI Central, Softshare, Red Tail, and even the big networks and VANs offer some kind of small-scale EDI program – via the web or a desktop application.  It allows mom to get her boogie on and dad can let his hair down and rock out!  They’re living “Life In The Fast Lane” (The Eagles).

Who’s Zooming Who?” (Aretha Franklin).  And that’s just it, too.  Who IS zooming who?  Who is it that decided that mom-n-pop should be doing EDI – should be rocking, rolling and dancing to a new tune…?  Was it their own decision or the decision of “somebody else”..?

Mom-n-pop – instead of being a retailer – are they a small supplier of some great product?  Do they offer up some excellent product – that they – and only they – make to such exacting standards and at such an excellent price-point that the Wal*Marts and Targets and Big Lots of the world are snatching up those widgets at such a great price and rate?  Was it that 800 to 8000 lb gorilla in the room that “forced” mom-n-pop to zoom along that EDI Highway?

The great thing is that EDI can and will help mom-n-pop to become more productive and better equipped to handle business here in 2008 – and beyond – by giving them the tools they need to get the job done, get their widgets out there and stay afloat in this – often times – unsettlingly sinking economy.

When you think about it, though, a lot of those mom-n-pop businesses and stores have grown – whether with EDI or not – by using new tools and features that become available.  They’ve moved from being on “The Flintstones” to being more with “The Jetsons”.  They’ve embraced the new technologies – as they’ve come to market – to better themselves and their businesses.  But now mom-n-pop have many stores across a region – or they’ve begun production of their newest product – the Widgette – and opened up an overseas factory to help out with production.  They’re now an 80 lb gorilla in the world.

But then they hit upon another stumbling block and they lose that step and the rhythm.  Mom-n-pop now have to deal with the realities of ASNs and carton labels (aka UCC-128 labels).  Since the order is not being sent directly to the factory – or, even if it is – the factory can’t print out those carton labels or maybe they make those widgets for more than just mom-n-pop.  So now they – mom-n-pop – have to get those labels generated and somehow they have to get attached to the cartons!

Enter some world-wide document and package delivery service and the printed labels are stuck in an envelope and mailed (basically!) to MNP Factory, LLC.  And now somebody in the factory needs to know just what to do with those labels – and it ain’t put them in the round file! – and match them to the cartons of product that mom-n-pop have ordered!  And get them all correct and perfect!  AND they have to figure out how to create that ASN for you, too.

But, still.  Mama can dance and dad is out there rocking.  And EDI is what helped them.

Author: Craig Dunham – EDI Coordinator
Read more about Craig here: http://editalk.com/contributors/