ID? We don’t need no stinkin’ ID!

Over on the EDI-L Yahoo group, a poster was talking (ranting?) about some issues they were having with possibly having to change their client’s EDI ISA/GS IDs and all the “trouble”(?) that would cause.  It was a long and convoluted tale about Company A selling a division (that did orders via EDI) to Company B and maintaining that EDI connectivity and activity – using the same ISA/GS qualifier and ID – and something about another division of Company B now going EDI and what ID and . . . well, it was very confusing to read and is still a bit muddled in My head, so maybe go and read it for yourself, here.  Oh, BTW, the ID in question was the DUNS+ ID – where you use your DUNS number and add some number to it.  I don’t know about that, as we use a phone number for our EDI ID.

Company B has also purchased other “divisions” over the years – some EDI, and I guess, some not.  And now some of these divisions may be trading with a whole new set of clients – and maybe even some of the same? – as the original division acquired oh-so-long-ago from Company A.

But I had replied to the original post with the concept that, “way back when” (the poster mentioned that this has been going on for over 10 years!), Company B should have created a NEW ISA/GS qualifier and ID set up for Company B and not continued to use Company A’s ID for so long, even if Company A was not doing any EDI.  It even becomes more of a situation because the ID being used IS, in fact, the DUNS number of Company A being used by Company B, which, presumably, has their OWN DUNS number.  Do you follow?

Anyway, all those years ago, Company B should have changed all of their IDs and alerted ALL of their trading partners to the fact that the ID was changing.  If they had done this, then our poster would have not had any issues right now with their trading partners – new, existing, old, future.  It would be SO much easier now.

The poster also questioned about the “meaning” or the “use” of the ISA/GS qualifier and ID and how it should only be (is?) used to signify a mailbox being used for EDI.

One of the other things that truly captured My attention was when the poster mentioned that “acquisitions and mergers happen every day” and questioned “Do companies really change their EDI ISA and GS IDs every time something about their company changes?”.  And this is something I see on a semi-regular basis.

Going back to the original concept – Company A sells out (a division or a product line or the entire company!) to Company B.  Both are EDI capable.  What does Company B do with Company A’s IDs..?  How do they “merge” the two (or more?) EDI systems and mailboxes together..?  How do they reconcile all of this data being pushed and pulled..?

And the answer goes back to the concepts of “what is a trading partner relationship” – in that they need to work with their existing trading partners to find the best answer.  But even that will rely upon how Company B plans on merging and integrating the Company A products and EDI systems into their own existing product line and EDI systems.  Does Company B want to keep Company A “semi-autonomous” and keep them segregated?  or does Company B want to completely absorb Company A’s products and systems?

If they want to keep it separate, then all they need to do is – well – nothing.  Just alert the trading partners to the new ownership and how the EDI set-up and communications will not change.  Or how they will change (maybe Company B uses Inovis and Company A was a GXS customer), so that the trading partners can make the necessary changes and take the necessary steps to implement those changes.  But they need to communicate with those trading partners the changes that are to come.

If, however, Company B is going to absorb all aspects of Company A and merge them all together, then they will need to alert all of their Trading Partners of that, so that the TPs can make those set-up changes in their systems – pointing this vendor number to this other vendor number’s ISA/GS address and set-up in their own EDI system and with their networks/VANs.

I see this a lot in My daily EDI life.  I work for a major retailer and it is common for bigger companies to acquire smaller companies.  I’ve got one of those situations happening right now.  It’s also common for a big company – which we buy from directly – to also have other companies producing “their” product through licensing of their names and/or logos.  Not every item you buy with the Nike or Adidas or Reebok logo actually COMES from Nike, Adidas or Reebok.  And then there is also the “overstock” production and items that the big companies sell off to other vendors (close-outs) that I may also buy from.  But the point is, that ISA/GS qualifiers and IDs change frequently for some vendors and suppliers.

One last thing that the poster questioned was if a company that uses, say, their telephone number as their EDI ISA/GS ID, should they change their ID every time their Area Code changes..?  And the answer to that, in My opinion, is NO.  Because they’ve been using an established ID – one that has VERIFIABLE TIES to their history – for years.  And it’s still their “property”.  True, it could be possible that another company may suddenly get that “old” phone number as their own with the change of an area code, but the ISA/GS ID still is “owned” by the original company.  It’s all about ownership.

Tying this back to the original question about the use of the DUNS+4 ID, what if Company A – all the way back up there ^^^ – was still doing EDI with other divisions AND still using their DUNS+4 ID?  Well then, Copmany B would NEVER have been able to continue using that ID for the division they acquired.  They would have had to have created a NEW ISA/GS ID right then and there.  Think of the confusion that would occur if Company A and Company B were both sending orders (or supplying product!) to the same vendors..!  Suddenly, I’m sending an order for Widgets from Company A, but it’s going to Company B – just because they have the same ISA/GS ID..!

In a way, think about your ISA/GS as an e-mail address.  I’ve had one of My e-mail addresses for – oh, well over 20 years now.  Now, if I was to deactivate that e-mail address, and in, say, 6 months, somebody ELSE was to acquire it, think of all the e-mails that they MAY get that were originally intended for Me..?  Same thing could go for a telephone number or even a PO Box or other mailing address..!  Think of when you buy or move into an existing house (condo, apartment, whatever!) and you get mail that is addressed to the previous recipient.  Well, you look at the address, see that it’s not for you, and you cross out the address, write “MOVED!” across the front and stick it back in the mailbox.  The post office then will do whatever they need to do with it.

The trouble with that in the EDI world, however, is that you never “look” at that printed address.  You don’t really see the order that is coming in to your system.  EDI is not an “eyes on” or “hands on” kind of business practice.  It’s system automated.  And the system is looking at values.  And the system will only kick out a value if it doesn’t match.  So, in My example above of Company A and Company B using the same ISA/GS qualifier and ID and sending orders to the same vendor/supplier, the EDI system is going to look at that ID and process the order – and isn’t truly going to know whether that order is for A or B – unless you have it doing a match on other data – such as a sold to, ship to, bill to or other such TP specific information – and the error will not get caught until the order is being picked and packed and shipped.  Or, worse yet, it may not even get caught until the order HAS shipped and Company A calls you up and asks “why did you send this stuff to us?  We didn’t order it!” or Company B calls you up and asks “hey!  where’s our order?”..!

The point to ALL of this is that the ID in question should remain with the company that originated that ID!  If I set-up an ID of ZZ/CEDEDITEST, then I should keep that ID with Me until such time that I’m no longer using it and cancel that ID and get rid of it.  It is MY qualifer and ID set-up and should remain MY qualifier and ID set-up for as long as I want it.  And if the ID is definitely company specific – as a DUNS number is – then you bet your sweet aunt’s patootie that I’m not going to get rid of that ID becuase it still relates back to and points to Me and My company!

I may be sounding greedy here, but that ID is MINE!

Author: Craig Dunham – EDI Coordinator
Read more about Craig here:

Microsoft BizTalk / eBridge Webcast – Empower Your Business Process: Transact and Integrate with EDI

A member of the site emailed this into us today, its an upcoming Webcast on eBridge and BizTalk.

Empower Your Business Process: Transact and Integrate with EDI

eBRIDGE has partnered with Microsoft® to bring you an informative webcast on how eBridge integration can streamline your business process and increase the value of your Microsoft Dynamics™ ERP by eliminating timely and costly manual data entry.

This presentation will demonstrate how a complete EDI document exchange and integration system is achieved with the ePortal Software-as-a-Service (SaaS) platform from eBRIDGE Software.

Through the power of BizTalk® Server, the ePortal handles all data routing, communication, translator and mapping services. Document transactions can be viewed from any station that accesses the internet.

Click here to register for the Webcast.


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:

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: