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:

Don’t Let One Bad Apple Spoil The Whole Bunch…

Ah, yes, another song, another title, and another blog for your reading pleasure. 

Maybe what the Jackson Five were to sing back in the 70s (but the song was released by The Osmonds, instead) – when they were dominating the charts – much like young Michael would do many years later until he got too … eccentric … and started with skin-lightening, reclusive living, sequined gloves and nose-jobs – doesn’t seem like it would have too much to do with EDI, but stay with Me; you know I can deliver on the goods…

Or, maybe better yet, I could have used Queen’sAnother One Bites the Dust”… There’s another fitting analogy.

What got Me started on this concept was a simple breakdown of a simple part.  Or, rather, the simple part’s interaction with another part…

If you don’t know (or even don’t care), I live in Southern California.  However, I live in the desert regions of Southern California – near the resort areas of Palm Springs.  And, as you might imagine, it can be HOT there.  Like 115 degrees in the shade – if you can find the shade…  OK, maybe it’s not THAT bad, but even in September – on the 15th – just a week shy of the first official day of autumn – we can still be in the 100 to 110 degree range.  But it’s nice, as the humidity is only 12%.  What’s the old adage?  It’s a DRY heat…?

Well, to help combat the heat of the desert, we all tend to have multiple ways of keeping cool – from centralized AC systems, window and portable AC systems to this wonderful device called the Evaporative Cooler.  Or the Swamp Cooler, if you so desire.  I like Evaporative better…  It’s got a bit more … class … and style.  Evaporative coolers are simple enough – they’re a big box that is attached to the side of your house.  Inside, there are few moving parts – a pump, a motor, and a fan.  On the three exposed sides – the fourth side is attached to your house – you have intake vents that are lined with pads.  These pads are made from different materials, but think of them as being big sponges – lots of little crevices and holes for air to pass through.

The concept is simple enough – if you add some moisture to the air, it will “feel” cooler and help to cool the air inside your home.  The mechanicals are pretty simple too.  A motor turns the fan, which sucks air in through the vents and the pads.  The pump in the bottom of the unit takes water and moistens the pads that the air flows through.  The fan then pushes the air into your home through a hole in the wall.

Are they effective?  You bet!  Just ask anybody that lives in a desert climate – or even through the swampy hot and humid Eastern Seaboard!

Evaporative coolers can drop the temp by (usually) at least 10 degrees and even as much as 20!  That’s nice…  And it’s cheaper to run than your central AC, and it’s operating on lower voltage current.  There are some drawbacks, however.  They DO use water – some can use as much as 5 to 10 gallons PER DAY of precious H2O.  And the more humid it is outside, the less effectively the cooler works.  There’s a thing called “DEW POINT” which greatly impacts the ability of the cooler to work properly.  It’s some strange formula that takes the humidity and the temperature and the concept of “moisture in the air” and combines it all together and creates a DEW POINT that’s expressed in degrees.

Now, I rely on My evaporative – OK, that’s just getting TOO long to type over and over…  I rely on My Swamp cooler to keep My house cool and comfy on those hot summer days (and nights!)…  As I said, it’s cheaper to run than A/C and does a great job…

Well, Sunday night, My swamp cooler was having problems – BIG problems.  The fan would bind up and stop, causing the motor to overheat and shut down.  So no motor, no spinning fan, no air flow and cool air…!  YIKES!  Not a good scene, at all.

Woke up early on Monday and started to see if I could figure out what was wrong.  HA!  Everything LOOKED normal.  The fan WOULD turn (at least by hand!) and the motor would kick on.  The pump was working, water was there…  All should be working.  But it wasn’t.  Called in “the professional” – an HVAC company that works with the coolers – to take a look and tell Me what’s wrong…  And he found nothing.  He suggested oiling the bearings some more, and playing with the fan to spin it and get the oil all over the bearing and lubed up.

No luck.  Still it would kick on, work for about 30 seconds and shut down.

Called another guy; he came and took a look – and noticed that the belt – the simple rubber belt that connects the drive motor to the fan – seemed a bit … too tight … and was looking a bit worn.  This is the same kind of rubber fan belt you have under the hood of your car.

Turns out, that the last time somebody serviced the cooler, they noticed the belt was slipping.  Of course, this was because the belt was wearing out and needed replacement.  But instead of spending a few bucks on a new belt, they just pulled the motor back a bit and tightened the belt.  However, the extra “snugness” of the belt would put too much friction on the motor and the fan and the fan would stop and the motor would stop and … well, you know what happens – no air flow.

An hour or so later, a new belt is in place, the fan is spinning, the motor is running and the water is pumping and the air is cooling.  Now, even though it was up to 93 degrees INSIDE My house, the cooler quickly dropped the temp to about 83 and then it continued down to an overnight drop to 68 degrees!  AH, now THAT is nice and cool!

Of course, I was panicked, thinking I would have to replace the whole unit – the entire cooler – because of one bad part.  “Don’t let one bad apple…”…

Now, what does all of this have to do with EDI…?  Stick with Me, the payout is on the way…

Take a look at your EDI system and program.  It’s there, working away, providing comfort to your users and your trading partners.  Everything is cool.  But then somewhere along the line, somebody does something – tweaks a library, changes a communication setting, deletes a record – something – and now you’re “PRODUCTION DOWN” – “Another one bites the dust… and another one gone and another one gone, another one bites the dust… – data is not flowing, documents are not trading and people are not happy.

Things are NOT cool.

Now, it COULD be something easy to see and right there in front of your eyes.  For example, if My cooler’s belt had broken, I’d know – QUICKLY and EASILY – what needed to be done to fix the problem.  Same with EDI – somebody unplugged a modem line or the T1 or whatever you use to communicate over.  Easy fix – plug it back in!

But now, what if somebody did something else – cleared a record, moved a library, changed a comm. setting or port…  Now the broken part isn’t right there – it’s not easy to spot and fix.   It’s the same as My slipping belt being tightened and putting too much pressure and friction on the fan bearings.  Somebody did something minor – and not visible to the naked eye – and now you’ve got nothing…  No data flow and nothing good is happening.

And yet, just a simple fix – a new fan belt – a new comm. port setting – and you’re back in business and things are working.  The point is, that even with a major production down scenario, it could just be a simple fix – a single, simple part – that needs to be looked at and put back into place.

Now you can be singing “I’m Alive” (by ELO or Celine Dion, take your pick!) again and you’re too cool for school!

Author: Craig Dunham – EDI Coordinator

Read more about Craig here: http://editalk.com/contributors/


e-catalogs – how do you use them?

My take and thoughts from a post over on the EDI-L Yahoo group about the type of data to provide to a Catalog service.

There’s a lot of “push” these days – and has been for years? – about Electronic Catalogs.   Many of the bigger networks/VANs have a catalog service (Inovis & SPS Commerce come to mind) and there are probably more offered out there by companies – big and small – EDI network or not – that can house that data and provide it to your customer base.

This is where you, as a vendor/supplier/manufacturer, can store your product information data – colors, sizes, UPCs, style numbers, descriptions, and more – that can then be accessed by your buyers – the retailers and resellers – for their systems.  Some of the information is used by the end user and some is not.

Then on the flip side – there’s Me – the retailer.  I subscribe to the catalog service provider (in My case – Inovis) and look to that data for product information.  In our case, we’re pretty much only looking to verify the Style Number and UPC information.  Since we decided LONG AGO to not use the NRF size or color codes, that information is irrelevant to us.  Also, we tend to use our own item description that, again, makes your description somewhat irrelevant.  While some of your description is included in ours, we add extra information that may be related to a season (say, Spring, 2008) and other things that may not be included in your description and is very specific to our way of doing business.

The only thing that you provide to the catalog service that we use is the UPC and your published style number.  One of the reasons we don’t use the NRF color codes is that – well, think about your favorite sports team.  Now, think of their colors.  If you’re a San Francisco 49ers fan – it’s Red and Gold.  Oakland (LA) Raiders?  Silver and Black.  LA Lakers?  Purple and Gold.  Philadelphia Eagles?  Green and White.  LA Dodgers?  Blue and White.  So, pick one..

OK, I will.

Let’s say I’m a T-Shirt maker.  And I’m making a line of sports team T-shirts, those “raglan” style ones, where the body of the shirt is one color and the sleeves are another color and meet at the collar.  I think that they’re called “raglan”…  Oh, and the cuffs and collar can contrast to the fabric that they’re attached to.  Think of the baseball style T-shirts you see..  Anyway, I’m getting off topic.

So, I’m making team color t-shirts.  And I’m setting up the one for the SF 49ers.  So I make the body of the shirt red – actually, it’s more of a burgandy – and the sleeves are gold.  So I go to the NRF color code list and – hmm – where do I put this shirt..?  Well, it’s red.  No, it’s DARK RED.  Oh, but here’s a number for Burgandy .. and here’s one that is maroon . . . . .

Or we’ll pick the Philly Eagles.  Green and white.  That’s easy.  Oh, wait – maybe not – is it emerald green?  kelly green?  forest green?  moss green? lime green? avacado, string-bean, sage, eucalyptus, clover…?  ARGH!!!!!  What happened to KEEP IT SIMPLE?!?!?!?

Then we get into the NRF codes for size!!!!  ACK!!!  ARGH!!!  Heart stopping.  Hair ripping..  Head exploding..!  While the size doesn’t have as much “wiggle room” as the colors do, there are still some issues to consider.  For example, we sell ammo for firearms.  And we have the caliber of the ammo as the size.  But what if the ammo provider uses the WEIGHT of the round as their size?

One of the things I’d mentioned in a reply to that post – remember the post I mentioned all the way up there at the beginning? – was that I agreed with another reply – in that he needs to follow any hierarchy set up by the catalog provider and to let the buyer – the retailer – to decide what information they were going to use and what information they’re not going to use.  As I said, we don’t pull down the NRF codes nor the description – we look to the STYLE number and UPC information pretty much only.

So, how do you use catalog information?  And do you push or pull the data – i.e. are you the manufacturer or the retailer?

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