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:

say what you mean, mean what you say…

That’s a pretty simple and straightforward kind of thing to say, isn’t it?  I mean, it … says … what it means…   and if we follow the concept, life would be so much easier for all of us…  No more lying politicians or smarmy sales-pitches…  No more “hey, this product was supposed to do this, but it doesn’t” kind of problems.  No more hurt feelings because you answer “does this (dress, shirt, tie, bathing suit, whatever) make me look (old, fat, ugly, whatever)” kind of questions truly – yes, your butt looks like a Buick in that silver sequin thing.  Sorry – a digression.

But you get My meaning, right?  I mean it would be so much easier if we said what we mean and meant what we said and we weren’t mean about it, either.

For example – I’ve been away from the office for about a week, helping My mom – My dear, 73 year old mom – move.  She semi-retired from being a programmer/analyst last year.  I say semi-retired because now she works for the same company – but as a consultant instead of as a salaried employee.  But she also works remotely, with a nice little wifi/broadband modem card stuck out of the side of her laptop.  We’re moving her from Las Vegas, Nevada to the Palm Springs, California area (Rancho Mirage, to be exact).  Now, My mom is a bit of a … collector … OK, pack rat.  Anyway, she’s got about 1800 square foot of furniture – plus 2 car garage, back yard and closet storage of stuff – to move into another 1800 square foot property, but on a smaller lot and partially furnished…  UGH.  I’m also the youngest of 5 kids.  The point?  You’ll see in a second.

My oldest brother also offered to help with the move.  But in the weeks leading up to the actual move, his level of involvement seemed to shift and change and morph from his original “I’ll help you move” to “I’ll come down for a few days and help unload” to…  And of course, he griped and whined and complained and yakked about how much stuff mom has and how she needs to get rid of stuff and blah, blah, blah.

The point is that he didn’t say what he meant and didn’t mean what he said – “I’ll help you move” – and he was mean about what he said, too – “oh, what is all this … stuff?!?”. 

In another yahoo! group I belong to – one related to HTML and website topics – a post appeared about a ‘free giveaway’ of software that was only good for a day.  And the poster was then called a spammer and a hack and told how worthless the post was, blah, blah, blah.  And the poster got a little … miffed … over the responses he received.  But the problem, you see, is that he then bristled – got more miffed – and ranted on how people should just ignore it if they didn’t want it and shouldn’t slam him for posting and all of that…

On another website, I was chatting with a friend and we veered into how often times humor and sarcasm and irony are lost in the written word and how – many times – in a face to face conversation, we can use expressions and voice tones and gestures to imply a meaning – adding a smile or a chuckle to show that something is funny or having a wide-eyed look of fear to imply that meaning of being scared or rolling your eyes to show annoyance or bother or how tired of all of it you are.

Luckily, in EDI, we have a set of standards or a governing body (whether X12, ANSI, VICS, UCC, Tradacom, and more) that tells us what we can say and how we are to say it and what it all means.  We have a document and a set of hierarchy levels and segments and elements and sub-elements that allow us to say “I’m ABC Inc., and I’m ordering from you, XYZ Company, this widget A-12 in size small and in color blue and I want them all to ship to this address and will pay you this money”.  Or whatever information we’re trying to convey.  The meaning and the “tone” of the document is all there – in neat black and white (or rainbow colors if you’re using a color printer).  It’s giving us the “Ws” of the world – the WHO, WHAT, WHERE, WHEN and WHY.  It gives us all the information and the data we need to do what we need to do.

In the written word – we don’t have those standards.  And we don’t have the help of the voice tone, facial expressions and other “standards” that we can use to decipher the words and – yes – the data being conveyed.

The written word is … flat …  There are no real peaks and valleys.  It’s a monotone.  It’s the same level all over.  It takes a talented writer – and there are many of them out there – to convey a feeling via the written word.  Stephen King, Dean Koontz, Anne Rice – all are masterful at conveying fear and horror in their written word.  Barbara Taylor Bradford, Sydney Sheldon, Jackie Collins – they were all good at conveying lust and longing in their romance novels and steamy stories.  But it is still up to us – as readers – to decipher what they’re trying to say and what information they’re trying to impart and what they’re meaning with those words.

And again, we have EDI standards to tell us what that information means.  We don’t have to decipher what it means, because we have a guide – those standards – to tell us what each piece of information – what each bit and byte of data – means.  The document, through translation, says what it means and means what it says.

Imagine how much simpler one of the most well known bits of data in the world – used by thousands and millions of people around the world – The Bible – just imagine how much easier it would be to comprehend it if there was some kind of standard or guide telling us what it all meant.  We’d know exactly what it meant when it says “Love thy neighbor” or “honor thy father and mother” or whatever.  We’d know – without any doubt – what it was all about, Alfie.

Think about how many times that book has been translated over the centuries – from Aramaic to Greek to Latin to German to French to English to … And each time it’s translated, it COULD change a bit.  Think about how in English alone there are three words that all sound the same and have vastly different meanings and spellings – they’re – there – their.  Or wear – where – were (as in wolf).  I can say any one of those words – and without some kind of guidance – or a translation – a standard, if you will – you don’t know what I mean.  Without some inflection or tone of voice, what do I mean to say..?

Those very standards that can be so difficult to understand and implement – and have, let’s face it, a wide degree of variation – still simplify the entire process for us and for EDI and all that we do.  It doesn’t limit us to a single way of thinking and a single line of thought, but it does allow us to say what we mean and mean what we say with a very moderate amount of confusion down the line.

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

Are you EDI?

Over on the Inovis blog – which I read as an Inovis customer – they posed an interesting question today – wondering why it would be that all of your transactions are not done via EDI. Obviously, we’re talking about EDI-able transactions to begin with… But it then brought to mind a question posted on another group (over on Yahoo!) about specs and the value of X12 specs (vs. the banking standard of ACH) and somebody mentioned being penny-wise and pound-foolish when discussing the costs involved and another post referenced the bureaucracies and internal politics involved.

In My case, it’s not really any of these 2 reasons, but rather a process that is rooted in history… and another old saying:

“If it ain’t broke, don’t fix it!”

And this truly is the reason I find that we’re not doing MORE EDI transactions and we’re still pushing around little bits of paper here and there.

Chances are – especially if you’re reading this – you’re somehow involved in the processes of EDI. You’re connected to it…. You are not EDI-Challenged…. So, to you, the benefits of EDI are a no-brainer…. You grasp the savings in dollars and cents, you get the man-hour savings involved, the error reduction and the whole thing…. You understand how EDI works and what it can and can’t do… You’re an EDI king….

But now, explain it to that supervisor or manager over in accounting…. or to that VP of buying…. maybe to the guy receiving carton after carton after carton, truckload after truckload, of the product you order for your business…. Explain how EDI can save them money…. can cut down on errors…. can give them more free-time…. Chances are, you’ll get a blank look – think deer in headlights.

Then you get the questions…. or THE question – WHY? What will EDI do for us?

You’ll also encounter that “ain’t broke, don’t fix” thinking…. “Well, we’ve always done it this way” and “why mess with what works?” The “what’s in it for me?”

They’ll have concerns about having to learn a new way to do things… a new way to think. Now they’ll have to be trained on what to do and how to handle this new information in the new format they’re getting it.

That’s more of a problem than the cost issues… it’s the ingrained resistance to change. You can show and prove – until the cow jumps over the moon, the spoon runs away with the fork and the 3 little pigs live in peace and harmony with the big, bad wolf – how well EDI will fulfill their needs. But, until they can even understand that need even exists, nothing will matter and you’ll be facing that uphill battle.

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