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:

It’s all for nothing if you don’t have freedom.

One of the things you may have noticed about Me when I blog, is that I tend to find a quote or a saying or a song lyric or a … something … that makes sense and drives My thinking.  The title of this blog comes from the 1995 film by (and starring) Mel Gibson called “BRAVEHEART“.  For those that don’t know, it’s the story about fighting for freedom in Scotland in the … 1500s?  One of the more “famous” quotes is when Mel Gibson yells out something about how they may kill them (the Scots) but they’ll never take their freedom!

Freedom, however, in something as strict and regimented as EDI may seem like a far fetched notion, but it’s there.  Sure, we’ve got those lovely guides – those HUGE books – of standards and “rules” for the data we’re sending – depending on the document – that tell us what we can send and how it should be formatted and all the rest.  Those standards tell us we should send this information in this loop in this segment in this element and it should be between 2 and 30 characters in length.

But in that rigidity – in that structure – there’s still some freedom.  Just look at the last sentence in the above paragraph – we’re given some freedom in the data – that it can be between 2 and 30 characters.  So there’s some freedom right there.  Then there’s is such a plethora of data and information we can include – information and data that just may not seem like it belongs in the document we’re using.  But we can include it.

We can even have some freedom in what we use to separate our data – whether an element seperator, a segment terminator or whatever.  We have a choice of characters we can use and put into the data flow to show where this piece of data ends and the next begins.

Then, of course, we have a wonderful MSG segment – in which we can include all sorts of “free form” data that can be anything we want to include.  Again, more freedom.  More abilities and places to put information that doesn’t “fit” any one of the stricter and defined elements and segments of the document.  We can send anything – and I mean ANYTHING – in an MSG segment that may be of use to us (as the sender) or to them (our trading partner – the receiver)…  It could be a “please pack in pretty pink boxes” or “have a happy Friday” or “this information is solely for the use of the receiver” or … well, you get the idea. 

And that freedom is an important part of EDI.  Just as freedom is an important part of nearly every aspect of our lives – from where we live, what we do for a living, who we love, what we drive, what we wear and so on.  However, there are times that those freedoms can be curtailed.

Maybe your employer enforces a dress code – you can only wear dark colored slacks, white shirts and simple, mono-chromatic ties.  You can’t have facial hair.  You have to wear black shoes.  You can’t have any personal stuff on your desktop.  Shades of “9 To 5” – an 80’s-era gem of a movie with Jane Fonda, Lily Tomlin and Dolly Parton…  Where the workers rebel against their boss and take control of the division and suddenly life is good and it’s a better place to work!  Ties back into that freedom that William Wallace (Gibson’s character in “Braveheart“) wanted so desperately for his fellow Scots.

These attempts at conformity can truly alter – and not always for the best – the way that the job can function.  If, for example, that MSG segment wasn’t allowed in EDI – and if it was confining and restrictive – we wouldn’t be able to send some of the information to our trading partners that ARE important.  For example – we request that many of our vendors apply pricing stickers to our products.  And we request a certain format and that they include certain information – such as our internal CLASS of the item – on that price tag.  And we use a MSG segment to get that information across to them.  We send, in the PO Item loop a MSG segment with that class number as the data – and we even use another MSG segment to let them (our trading partners) what that MSG segment contains – the data needed for “TICKET ID”.

Sure, I could probably find something in the PO1 line item that I could use to get that data transmitted from My side to theirs, but it’s just … easier … to use the MSG segments, instead.  Maybe there’s not a perfect fit in the existing standards that will “match” up to our CLASS code.  There may be similar things – but maybe I’d rather have the freedom to use that element or data code later on.  Maybe I’ll suddenly have to start sending some other piece of data that the “similar” element was originally intended for.  Where’s the freedom in that?

By putting forward too many restrictions – too many rules – too many standards – you limit what you’re able to do.  You limit what can be done with the data or what you’re sending.  You limit your ability to effectively communicate – and to effectively work – and to effectively get your ideas and points across.  What if I wasn’t able to use movie quotes and song lyrics in My thought process?  You’d not be reading this blog – or – worse yet – it would be boring, dry and as exciting as a textbook on “Analyzing Algorithms about Data Trends in Modern Day Accounting” or something just as … exciting.

Some people have claimed that XML is the “NEW FUTURE” for EDI and that we don’t need standards and we don’t need rules and governing … committees … to tell us what we can and can’t send and how to format it.  They see EDI standards as … constricting … and they can’t see the freedom that is allowed them.

There is freedom all around us in EDI.  The trick is to find it and take it.

“It’s all for nothing if you don’t have freedom!”

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

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/


Ch-ch-changes… Turn and face the strange…” – David Bowie belted out back in 1972.  Well, 1971, actually, but the song wasn’t released until 1972.  And, as usual, I digress in the details.  But still, some of the lyrics are quite appropriate today.  And especially in the world of EDI.  Good ol’ Ziggy Stardust (aka Bowie) sang out:

                                   “Still don’t know what I was waiting for..

That’s something we hear a lot in the EDI world – once somebody finds out how well EDI can help them.  They don’t know what they waited for – or balked against – when given the option of EDI.  Once they’ve seen-the-light, it suddenly becomes a no-brainer.  But at the time, it was strange and unknown and a change.  And we all know what people can be like when it comes to change.. Don’t we?

  • Change is hard!
  • What’s wrong with the way we’ve always done it?
  • Oh, great!  Now what do I have to learn?

Right now, I’m working with our Accounting group in getting them to embrace and accept the 810 EDI Invoice.  And, for the most part, I’m lucky that they’re open and willing to “face the strange” and go with it..  However, where it’s making My life a living hell is that they expect everything to be done.  Now.  2 Minutes ago.  Yesterday.   ASAP.  Jump!  Jump!  JUMP!!!

Think about the time that you first began to become a part of the EDI world  You probably came from some kind of MIS position – either an operator or a programmer or an analyst or .. Or, you came from another group that your EDI program touches – either the accounting group or the buying group or the warehouse group  or .. Well, you get the picture.

                                        Embrace the change..

And think about the changes (Ch-ch-changes) that you encountered along the way.  Think of how you had to ch-ch-change the concepts that you held and others kept of the way things were and how they were going to be.  Think of how you and others in your organization had to ch-ch-change the way you did things – things that had been done “that-way” for years (or even longer?)..

Some of the pods of flesh on this planet are pretty adept at change.  Others – well, not so much.  No, they’re like the stubborn mule in the old Western-Comedy, leaning back, digging in their heels and not budging.  It takes a lot of force to get that immovable object to take that step forward and “embrace the change”..

Then you sometimes have to try and keep up with those changes..  In recent articles, we’ve touched on many of the changes coming to and infecting EDI as a concept.  Things like AS2, XML, E-Catalogs..  Ch-ch-changes, indeed. 

But are any or all of these changes going to help or hurt you..?

And how good are you at accepting and going with change..?  How good are you at accepting change and working with it and finding the solution to the newest ch-ch-change coming at you..?  Think about your daily commute to and from work.  There’s an accident at this highway and that street.. or the road is closed because of “police activity”..  Or there’s some guy protesting ________ (the war in Iraq, China’s hosting of the Olympic Games, gays in the military, our government’s failed policies, the new Wal*Mart coming to town, whatever – fill in the blank) from that bridge, hanging a sign over the highway..  How quick are you to think – “hmmm.. I can detour here at Main Street, go down 3 blocks to Fifth Avenue, hang a left and be back on the freeway beyond that problem”..?  Or do you just sit there with a bunch of other commuters, waiting for your turn to squeeze through the half open lane to pass by the wreck, not willing to deviate from the norm?

How well you handle change means a lot – both professionally and personally.  Change is an integral part of life.  It’s something that creeps up on us on little tiny quiet feet or comes barrelling into the china shop and disrupting lives all around.  But change is inevitable – just like death and taxes.

And change is big in EDI – no matter how static and stable the platform and concept may be.  There are – and will always be – changes to the way we do things.  Standards are often being updated.  Segments are added or deleted from the document specs.  Suppliers and buyers are often requesting new information to be sent or received.  New applications are added to your back-end systems and now you have to map this segment/element to this other file and record over there.   The PO box you use to receive payments or invoices has been altered, and the data in your documents (POs, Invoices) must reflect that new alteration.  You’ve adjusted your factor or payment “lock-box” location or service provider.  You’ve signed up with a new VAN/Network and have a new qualifier and ID..  All of these are ch-ch-changes.

               “I watch the ripples change their size But never leave the stream..

These are just a few examples of the ch-ch-changes you may face.  And there will be many more, too.  I’ve had our EDI program up and running – well – WE’VE had our EDI program up and running since the very late 90s.  About 5 years ago, we changed our translator (upgrade) and then added a new document (the ASN) and added and expanded our trading partner count by .. well .. multitudes.  Then we added some information to our PO (requested by some of our suppliers) and changed a terms code and .. well, you get the idea.

Ch-ch-changes are important and everyday.  Expect them, plan for them and implement them.  And do not be afraid of them. 

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

EDI documents & KISS

I was reading The Inovis Blog – yes, I do read other things! – but Meg Suggs (Inovis) talked about how McDonalds (over in Europe!) is “going green” with their fleet of delivery trucks. I commented (of course!) on how it would be great if the US and our automakers could be as forward thinking about the acceptance of alternative fuels and energy sources (such as bio-diesel).

My own car is a Chrysler PT Cruiser. Chrysler sells the PT Cruiser over in Europe, and offered (at least at one point) electric versions of the PT, as well as a CRD powered PT Cruiser. CRD is the acronym for COMMON RAIL DIESEL and it actually is a very viable diesel motor – with great performance and low emissions – not anything like the diesels we all may remember from the 80s…. Jeep even offers the CRD engine in their “Liberty” truck-ette in the US. But I digress from My original thought and point.

Reading that post (at Inovis) and My comment on same made Me think of how much better and easier (!) EDI could be if more hubs and suppliers – and even EDI providers – were to be more open and accepting to other ways of thinking.. How much more we could all get done.

As a hub (i.e. a retailer that starts the EDI process), I have great and tremendous power over My suppliers.. Geez, now “He-Man: Master of the Universe” is running around My brain with “by the power of Grayskull… I HAVE THE POWER!!!!” as he turns from meek and mild Prince “what’s-his-name” into He-Man – Master of the Universe.. and yes, I’m digressing again. But still, as the retailer, I do “have the power” to control the way that EDI works. I’m the one that specifies what information is important to Me and what information I’m going to send and how I’m going to send it and you can either accept it or not. But if not, then you’re probably going to be dropped off of our “active vendor” rolls.

But then it makes Me think – even more – about how that power can be used – or abused – depending on how willing I am (as the hub) to force the issues. We’ve all heard the horror stories of this hub or that supplier and how they make EDI painful..

In our product mix, we have some of the big-big heavy hitters and also some small little mom-n-pop kinds of suppliers.. If you read My other blog about “How Do You EDI” – I mention about a supplier that provides us with one product, but it’s the best damn version of that product on the market, you understand what I mean about mon-n-pop suppliers. But still.. I have to be considerate of all of My vendors and suppliers – of all of My trading partners. I have to be flexible in what I will and will not send, and in what I will and will not accept in a return document.

We buy a lot from one of the biggest names in Camping Goods that you can know – they do it all – from coolers to lanterns to sleeping bags to those folding chairs and then even more.. When we first implemented our EDI ASN, I was asked by their EDI mapper if they could send additional information in the ASN – information that our spec didn’t call for; hell it didn’t even mention it. Like the PID segment. The reason? because he sends that segment to other hubs/retailers and was looking to keep as few maps around as possible. This would be a classic example of the KISS philosophy I mentioned previously. And it’s something I’m quite OK with.

It’s the same thing that many of My trading partners have to deal with when they receive My 850 PO – in that I send along information that they may never use in their own system. For example, in the PO1 segment, I send along our SKU (important for the return ASN and for pre-ticketing), but I also send the product UPC, the vendor style number, a generic item description, case pack information, item sizes, etc.. Some of the vendors fill the order completely on the UPC. Others use their style number. Others use the size and the style.. So there are different needs out there.

But the point is – we only use one document map for our outbound PO and for the inbound ASN. And the same will hold true for our inbound 810 Invoice (once completed). As EDI trading partners, we’ve come to an agreement of what will work best and we’re working together and thinking together with a common goal – transmitting information back and forth without major headaches. We’ve both made changes on each side of the EDI equation to help out the other partner to implement the data. We’ve accepted alternatives to our own documents and changed what we needed to change in order to use those alternative documents. Much like we could (as a people and as a country) make changes to accommodate those alternative fuels..

There are, as I said, a couple of the big “heavy hitters” in the supply chain that hold to the credo of “my way or the highway” type of thinking. You – if you want to trade documents with them – must comply to their way of thinking. There is NO deviation. Resistance is futile. You will be assimilated. We are BORG.. oh, wait.. more nonsense.. But still. Many of you may have had to have dealt with these hubs and suppliers – the EDI “trading partners” that will not accept anything but total compliance with their specs. No deviation from their ways of doing business and doing EDI. You cannot mix styles on an order. You cannot send extra data. You must send via AS2. And on and on and on and ..

These heavy hitters are the stumbling blocks and the hurdles to making this all easy and painless. They’re the ones that don’t want to accept an alternative way of thinking. They don’t want to make accommodations to a different way of thinking. They’re the villains of this piece, much like some of the automakers and oil companies are the villains in the alternative energy ways of thinking. They only want what they know and they only want the way they do it and there will be no deviation. There will be no alternatives. It’s Pink Floyd and “The Wall“.. It’s “Us or Them“..

In the cavern of arcane and sometimes useless (and other times useful – like in a great game of Trivial Pursuit!), another thought is bouncing around off of the lobes and valleys and bumps of My brain – “Can’t we all just get along?”

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