I always think of the old adage about “stopping and smelling the roses” when I think of that old song (BTW, it’s “FEELING GROOVY”)…  Which then leads to thinking about “tunnel vision”…  And all of this came up today because of a comment made to a previous post that fairly SCREAMS “sales pitch!” and … well, I’ve never been a fan of the heavy-hitting sales pitch.

Years ago, I actually was in sales - I was selling new (and used) Chrysler and Plymouths for a dealer in the San Francisco Bay Area.  This was in the late 80s and I only did it for a few months.  I had to get out of there because, while I love cars - I’m a certifiable car nut - I couldn’t deal with all of the high-pressure tactics that so many sales people used.  It actually kind of shocks me to think about how many of the same sales tactics and ploys are still being used in 2009 - over 20 years later!

It’s these “hard sell” tactics that got under my skin today.  Somebody read a blog and thought it would be a great opportunity to use a comment back on the blog to push their product - which is a service, really - as an outsourced EDI program.  Software As A Service (SaaS) has been buzzing around for the past few years and is really taking hold in any MIS/IT environment you can think of…  And it’s also always being pushed in the EDI world, for sure.  So many companies have been making many dollars on offering outsourced EDI processes….

And please don’t misunderstand me with this blog - I certainly know the value of SaaS - especially when it pertains to EDI - but what got to me was more of how some people don’t seem to think of how EDI is being used (or has been used) by a company when they “sales pitch” their solutions.

As I said, there are a great many companies out there that offer “outsourced” EDI solutions.  Some may be known to you, others may not.  There’s companies like SPS Commerce, DI Central, Red Tail Solutions, EDI Direct, Direct EDI, ACT, and more and more and more.  Even many of the “big VANs” offer some kind of SaaS EDI solution…  Inovis has their webforms product which, in a minor way, can compete with their own VAN services AND their software (TrustedLink)…

Outsourced EDI (aka SaaS) can be highly beneficial to many a company when it comes to EDI processes.  You could be a small supplier of (dare I use it again?) Widgets to a bunch of retailers - big and small.  By having a way to process EDI documents, you can sell to the big retailers (WalMart, Target, and so on) and also to the smaller and medium sized retailers (local chains and single outlets) that also are EDI capable.  Having an outsourced EDI program (SaaS) can elevate you up to play with the big boys, but still keep your overhead low and complexity down at your “small boy” level.

Take a look at normal  VAN services, for example.  Depending on your volume of data being transmitted, you can pay (easily) thousands of dollars a month for your VAN connection - to be able to send and receive your data.  Costs can range from just a few cents per KC (Kilo-Character) to maybe as high as 25 cents per KC…

Then there are the costs of buying and implementing an application.  A simple and yet exceedingly effective product like Inovis’ TrustedLink can cost you thousands of dollars - tens of thousands - to purchase and put into place.  Then there’s the aspect of yearly maintenance and licensing agreements and support - again, thousands to tens of thousands of dollars…  So, for a small business, that can be a BIG chunk of change… 

Based on just these two costs alone, SaaS EDI is making a lot of sense.

But here’s where the sales pitch can rub the wrong way.  Let’s say that, instead of being a small fry, you’re a really big fish in the world.  You don’t just make widgets, but you also make all sorts of other products and have multiple locations and divisions around the country … or even around the world.  THIS is where SaaS EDI can be less of a benefit for you.

To a major retailer - like a WalMart or Target - or to a major manufacturer/supplier - like Mattel or Nike - these costs are very small potatoes.  They already have good sized MIS/IT departments and can easily afford that big outlay for the EDI platform AND the monthly VAN costs AND whatever other costs come along.  Oh, and they can easily manage it all “in-house” and have it all easily integrated into their ordering and accounting and warehousing (and whatever other) applications they use.  It’s more direct-connect EDI - retailer to supplier - with just the VAN service in between. 

This is not to say that SaaS can’t be used in the same way.  But it can surely slow down the process just a bit and it also takes a lot of control away from you - as a big guy.  As a big guy, you’ve got more at stake and more reasons to keep it in-house and not oursource your EDI.

A few years ago, a good pal of mine that works for Disney, related to me how Disney decided to “outsource” their internal help desk/tech support functions.  Now, for those not in-tune with “the House of Mouse”, Disney will generally make a lot of changes to their applications - including naming them after Disney characters - and train their people how to use “their” systems, their way.  So instead of using, say TrustedLink, the EDI person knows it as “Minnie” … or “Daisy” … And their version of Oracle or SAP may be called “Goofy” and “Pluto”.  Imagine the trouble when tech support guy Bob at “TechSupport R Us” gets a call from Walt at Disney, telling Bob that he’s got a problem with “Mickey” or “Donald”…

Oops!

When I first started with the retailer I was working for, I started off in the tech support office, helping users do what they  needed to do - use the system.  And it would often amaze and bewilder me how many of those users didn’t actually KNOW what they were using.  They’d submit a job or run a process with some variables.  But, when they were trained to use the process, they were told “oh, don’t worry about those questions, just hit enter” and they’d page through a number of variables and parameters that were defaulting to the proper response for the job.

But, just like Walt at Disney having issues with Mickey, the users didn’t know how to answer the questions that Bob may have asked.  Because Walt didn’t know the answers.  And Bob didn’t know how Walt used the program.

This can also happen when you start working with SaaS and outsourced EDI - and other applications.  You can save some money and maybe even some hassle, but you then may get into a situation where the company you’re getting that Software as a Service from doesn’t really know or understand how you’re using it.  And you may not understand exactly what that software is doing.

With that retailer I was working with expanded the EDI program to include the 810 invoice, there were a number of vendors and suppliers that used “outsourced EDI” to receive the PO and send back the ASN.  And now they’ve got a new document to send - the invoice.

Where the trouble came from, however, was in how that SaaS solution was packaged and maybe - just maybe - some of the users didn’t understand about what they needed to put into a certain field so that the retailer would be able to process the inbound 810 properly.  Maybe in the field marked “description” - they’d put a description of the product they were shipping instead of realizing that they were on a page devoted to “terms” and should have (instead) put a description of the terms of payment of the invoice.  So you saw “widgets” instead of “Net 60″….

This is where SaaS solutions can fall apart and not be right for everybody.

And that’s really what my problem with the sales pitch was about - that here’s an offer being pushed and yet the pusher doesn’t even know what the problem really is.

When I was selling Chryslers all those years ago - I made it a priority to know what the customer was looking for - an economical commuter - and steer them towards a Plymouth Colt or Sundance, rather than trying to push them into a fully loaded (and quite the gas guzzling) Chrysler 5th Avenue. 

It’s also kind of like what I do here - when I’m writing and blogging - in that I kind of know the target audience - people that are in the EDI world - and I talk about EDI issues and problems and concerns, rather than trying to talk to you about how to grow perfect Peonies or resplendant roses or telling you how to bait that hook to catch the biggest mackeral or trout in the lake.

It’s all about knowing your audience and not making some wild pitch and moving way too fast for your intended…

Has the silence been golden?

Of have you been secretly pining away for more wit and wisdom from the one and only; is it writings from this one that you have been yearning for…?  Or do you really just not care one way or the other and you’re just about to go read something else…?  I guess I’d better get to the topic, huh?

I know its ground I’ve covered before, but it’s still a fertile field to … darn, what’s a good word for plow that starts with an “F”…?  How about farm…?  It’s still a fertile field to farm…  There.  I got some alliteration in.

But I’m rambling on (again?) about changes and not doing things the “new” way because it’s too difficult.  Or it requires us to think of a different way of doing things that maybe – just maybe – we don’t want to think about.  It’s about adapting to change and dealing with the change that comes along as newer (and better?) ways of doing things come along.

OK… since the last time we talked, the economy has tanked and slid way down the scale… Retail sales are way off from just a few years ago and some retailers have gone the way of the Eagle and the Plymouth – they’re gone and not forgotten, a lingering memory of their products still firmly entrenched in the minds of many.

By the way – the retailer I work for is not doing horribly bad in this economy sink… Mind you, our sales aren’t growing – much – but we were only down about 4% from last year…  Some days we’re up, some days we’re down, but we’re certainly not out of the game…  Truly, if we can last out this recession, we’ll be doing pretty well.

There’s this one vendor of ours that we buy a LOT of stuff from.  And I’m not just talking about the quantities we buy from them, but even across the product lines.  We have thousands of SKUs that we buy from this vendor.  And they’re shipped directly to the stores.  We use a module within our merchandising system that can track sales and generate POs based upon last year’s sales trends.  From that data, we can create POs – one for every store – that are pretty accurate.

“How does this pertain to EDI?” you’re probably asking.  And I’ll tell you.

Each of those orders we’d generate for each of the stores was sent via EDI to the vendor, who would then fill each and every of those orders and ship the products (generating an ASN for each) and then even (now) invoice us for each of those orders.  On a monthly basis, that could save the “manual” creation of about 400 Purchase Orders.

Good stuff, eh?

But now, it seems, we’re no longer doing that.  Instead, that vendor is going into each and every one of our stores and seeing what’s needed on the shelf and stocking those shelves and then sending us a list of the items they put on the shelves and we then generate the PO (after the fact) and send the vendor the PO number (but not the actual PO) so that they could update their system (manually) with the PO number so that they could then process the invoice.

All the wonders of our working system – with minimal manual intervention – are now buried and – poof, they’re gone.

We’ve gone from that super economical, safe and efficiently powerful car of the current decade and we’re driving some 50’s era heap without even the comforts of a radio or air conditioning, let alone all those safety advances of the last 50 years…

And why?

That’s what I’m spending a lot of time today trying to figure out…  Why did we abandon this system that was working well for a number of years and go back in time to a manual process that lends itself too well to errors, mistakes and “oops” events?

Isn’t that one of the key benefits we’ve all used to push EDI into our companies and grow our EDI programs by adding new documents and vendors to the system…?  One of the key goals of processing orders via EDI has been that it helps to eliminate much of the possibility of wrongly keyed data…  If there’s an error, we know it’s probably going to be before the document was sent via EDI.  It was keyed in the beginning and then was never caught and flowed through the process from start to finish.

*sigh.  It’s just so … negative … and so disheartening to the way I’ve been thinking and working over the past few years.  To see all those positive changes being swept away and all of these negatives taking their place.  It’s like watching the past 8 years of the Bush Presidency all over again, but on a smaller scale.

OK, that was a cheap shot across political lines – but it can be viewed as a valid analogy.  But I’ll let it slide and not really give you the details of the way I’m thinking.

But, again, here we are, creating orders and getting errors in return.  Wrong PO numbers, wrong store number entries, wrong items sent and other errors.  And who’s to blame; is it our fault or the fault of the vendor?  Probably a bit of both; but I’m the retailer, so I’ll blame them.

I’m still trying to figure out from the buying department why they’ve changed their processes…  But I don’t want to sound like some whiner…  So I’m taking “other” routes – using different people in different departments – to do that dirty work.  I’d like the guy that’s now taken over that automatic process we were doing before to “suggest” the orders and create the POs from; I’m asking him to find out why they’ve stopped with the process.

And I want to know why we’re not sending those orders via EDI anymore.  I mean, if it’s because the vendor would end up “doubling” the order, since they’d already supplied it to the store, then it’s really on the vendor to make the changes in their system – to get the list of EDI POs and find that they already exist in their system and change those existing orders to use the POs we’ve sent over via EDI.

I mean, somebody is already taking those existing orders and modifying them to add the PO number in their system so that they can send us the ASN and the Invoice via EDI.  So why would it be difficult for them to take the EDI generated orders and NOT ship them and populate some table or file in their system, generate a report from that data and then manually process those changes…?  Or even handle it through a program that would go and search that file that they populate from our EDI data for a “key” bit of information – such as the store number – and then change their order to add the PO number.

Of course, there’s another way that we could do this, too.  We COULD receive an EDI document – like the 852 – and process it into an order that is then turned around as the 850 back to the vendor.  I mean, that’s what we’re doing manually as it is – we’re taking their suggested stock levels and numbers and creating a PO off of a file (usually an excel spreadsheet) they send us.  What’s the difference if it’s sent as and 852 via EDI or sent as a flat file as an e-mail attachment?

The times, they are a-changing and we’re not going “Back To The Future” – but we’re going back in time, to the land that time forgot.

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

The list of the bad cities includes quite a few cities located in California.  But if you were to look at the list – and if you’re not from California – you’ve probably NEVER heard of many (if ANY) of those cities.  Here’s the list:

1.    El Centro, Calif.       
2.    Yuma, Ariz.               
3.    Flint, Mich.               
4.    Merced, Calif.
5.    Yuba City, Calif.      
6.    Modesto, Calif.      
7.    Visalia, Calif.            
8.    Monroe, Mich.
9.    Palm Coast, Fla.      
10.  Stockton, Calif.         
11.  Fresno, Calif.             
12.  Bakersfield, Calif.
13.  Hanford, Calif.          
14.  Redding, Calif.          
15.  Muskegon, Mich.    
16.  Jackson, Mich.
17.  Rocky Mount, N.C.
18.  Saginaw, Mich.         
19.  Madera, Calif.           
20.  Detroit
21.  Elkhart, Ind.               
22.  Sebastian, Fla.          
23.  Kokomo, Ind.            
24.  Rockford, Ill.
25.  Niles, Mich.

11 of them are from California.  But, of those 11 – only one is NOT located in the Central Valley area of California.  And the biggest (and almost only!) jobs in most of those cities are related to farming and agriculture.  And some of them are downright tiny cities.  And they’re surrounded by miles and miles and miles of … well … nothing. 

Most of the cities listed that are in the mid-western areas of the US – like Indiana, Michigan, Illinois – are areas that have industries tied deeply to automotive industries and – an even more beleaguered segment – RV manufacturing.

Let’s face it - political statements aside - the economy sucks all over…!

Now the 25 “good cities” many tend to be … well, mid-west centered, too.

1.   Sioux Falls, S.D.           
2.   Idaho Falls, Idaho       
3.   Rapid City, S.D.            
4.   Bismarck, N.D.
5.   Houma, La.                    
6.   Morgantown, W.Va. 
7.   Logan, Utah                  
8.   Fargo, N.D.
9.   Casper, Wyo.               
10. Billings, Mont.           
11. Lafayette, La.             
12. Ames, Iowa
13. Midland, Texas 
14. Iowa City, Iowa         
15. Lincoln, Neb.              
16. Great Falls, Mont.
17. Charlestown, W.Va.
18. Des Moines, Iowa   
19. Portsmouth, N.H.    
20. Missoula, Mont.
21. Salt Lake City              
22. Provo, Utah                
23. Sioux City, Iowa        
24. Odessa, Texas
25. Pocatello, Idaho

Sure, there are a few standouts in the North East and the South, but many of them are solidly Mid-West cities.  Of course, they’re also cities that, if you research them more, you’ll find they’re pretty stable cities with no great industrial claims.

Truly, outside of a religion, what does Salt Lake City hold a claim to – industry wise …?  And Casper, Wyoming and Billings, Montana - what’s going on there?  Besides being near major National Recreation areas, what industry calls those cities home?  And, as for Texas, Midland and Odessa are right next to each other (geographically speaking) and so the “gains” in one will be similar to the gains in the other.  But again, what’s their industrial base…?  Where are those job gains…?

But even then, the growth isn’t anything … huge.  Not anything like the high unemployment numbers for the California and Michigan cities.

But, again, the basic study – the reasons behind the articles – is flawed.  It gives a decidedly myopic view of things… And an exceptionally dire one, at that!

Why?  Well, it’s because they’re only looking at one single point of data – the unemployment rate.  That’s it.  Nothing about the industry that supports the area, the number of residents that do not work anyway (i.e. retirees, stay at home parents, whatever).  They don’t look at the kinds of jobs in the area – from flipping burgers at Burger King, Carl’s Jr. or McDonalds to legal secretaries, doctors, nurses and other types of “skilled labor”…

Take a look at St. Louis, for example.  They’ve got a lot of industries there – from auto manufacturing to hospitals to finance…  They’re all over.  But what does Ames, Iowa offer in the way of industry…?  What kind of jobs are even available in Ames…?  Do you think that there is a lot of call in Ames for an EDI manager…?  Or some other kind of IT position…?

That same flaw – the single source of data and the single point of data being used – can also be a major flaw in our EDI system and what we do with those documents.   What good is an EDI system that only processes a single document for a single department for a single trading partner…?  How does that improve your supply chain or your business…?

Opening up your focus – whether by the data you want to trade or by the “who” you want to trade with – can make your EDI world that much better.  That much more … well … impactful and worthwhile… leaving your EDI program just focused on one thing does not make it very useful information.

It’s like the articles I reference above – how valid is that information to you if you want to move to Sioux Falls, South Dakota and – while there is low unemployment and some growth in their job market – there is not a job for you to take…?  If you’ve achieved your MSCSE certificate, but there are no jobs for people with your abilities and qualifications, of what value is the fact that Sioux City has low unemployment..?

Or – on the flip side – you’re moving to Bakersfield or Fresno to take care of an ailing family member – but you’ve already got a job lined up – in your field of expertise – so the high rate of unemployment doesn’t matter to you.

Job futures – and EDI – need to be … far ranging and “big picture” – taking into account a lot of smaller details.  It can’t just be focused on one little fact or figure.

There’s that big retailer – WhoM shall remain nameless  - that is always the Target of the wrath and ire of many an EDI “guy”.  Those that deal with that big retailer (or the other one) know that they seem to be “our way or the highway” kind of mentality.  Do it our way or we’re not doing business with you.  It’s a very limited eye view of EDI.  It doesn’t allow for any deviation or options.  It’s this or nothing.  It’s one sides and just one point of reference.  It’s very limiting.

Now, in some ways, that limited versatility may be good – in that there’s not a lot of “extra stuff” to worry about.  Just like the one point of reference in the jobless rates in those cities – not a lot to worry about.  There aren’t many (any?) jobs, so don’t go there.

But isn’t it better when you have more to work on than just one number; or one point of view or one way of thinking…?  Where’s the value then?

Author: Craig Dunham - EDI Coordinator

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

But that’s not truly the case when you’re talking about EDI.  When it comes to EDI, I’m doing the asking - “Hey!  I’d like to send you our PO and get an ASN and an Invoice back, electronically.  Are you game?” - but you’re doing the paying…  At least in My world - the world of retail trade.  I’m requesting you to change the way that we do business and accept My orders for your products electronically - instead of via fax or mail or carrier pigeon or crazy, downtown bike messenger - which will, in turn, save us both money (money, money, money… it’s a rich man’s world!), because we’ll be able to get rid of some of those leased phone lines (for the fax) and cut down on postage (the mail), nearly eliminate our budgets for bird seed (the pigeons) and harrowing clean-up expenses from those sweaty Lycra clad bikers…  It will also save us money because we won’t have nearly the same kinds of expenses for error resulotion when an order is keyed in wrong by that pretty - but dense - eye-candy and boss’ kid data entry operator over in customer service…   

Now I’m not saying that all (or even most) data entry people in customer service are dense - or lack-luster kids of bosses - but you know what I mean…

All it can take is just one key-stroke to completely alter an order.  I’m ordering, for example, 1000 Widget A (style W-A1) in blue (color 001) and it gets keyed as 10000 Widget 1 (style W-1A) in black (color 010).  You can see how easy it is to muck up an order with just an extra ZERO (10,000 instead of 1,000) or transposed data (style A1 vs 1A - or color 001 vs 010)…  We NEVER sell your black Widget 1, as nobody orders that from us.  And even if we sold a few - just because they’re new and novel - we still have over 9000 of ‘em in stock and what-the-hell-are-we-gonna-do-with-’em…?  So we submit an RTV request and you pay for shipment of the goods back and you credit us the difference and so on and so forth….  It’s all on your side of things.

If the order had been sent via EDI, the order goes in as we sent it - 1000 qty W-A1 in 001 - no muss, no fuss, no errors… unless they’re on OUR end.

But I’ve gotten a bit far afield in the details again.  Back to “who pays” for EDI….

In the retail world, I’m a HUB.  I’m the guy sending the orders and receiving the product and selling the Widgets on to the wide and wildly waiting world of Widget wovers…  LOVERS…  I’m the guy in the driver’s seat.  I’m telling you (via My 850 PO spec) that I’m going to send you an order and it’s going to contain this information and this other information and, oh-yeah, that other information over there.  And I’m going to request - no, REQUIRE - that you send Me an 856 ASN when the order is ready to be shipped.  AND I’ll accept your 810 Invoice electronically - again, all in the name of ease and cost reductions and error management.

Basically, it’s a cost of doing business… for YOU.  My costs of doing business are having a chain or stores (ok, maybe just 1 - Wally’s World of Widgets for Widget Lovers - hey!  got it right!) and hiring employees and buying cash registers and store fixtures and paying for ads in the local paper and rent on a location and all the other things that go along with it…  Sure, you could justify that it’s a cost of doing business for Me, too, but you need to think of it differently… You need to put yourself into My shoes…

So you’re Willy’s Wacky Widgets - and you make and sell a wonderful array of widgets… different colors, sizes and shapes… and you sell those widgets to your customer base - Widget retailers.  You sell them to Wally, Wayne, Wanda, Wu, Wendy, Weaver and Bill…  That’s William.  Then it’s the job of Wayne, Wally, Wanda, Wendy, Wu, Weaver and William (Bill) to sell the widgets to the final customer - Wilma, the world’s most well known and renowned Widget owner, who lives in Walla-Walla, Washington. 

Now, in this, you’ll notice something - we’re both selling a product (widgets) to a consumer (you to Me and Me to Wilma).  Of course, you’re a wholesaler of widgets and I’m a retailer.   The only difference is the price.  But, see, I’m your customer.  Without Me, who would you sell your widgets to?  You don’t sell them directly to Wilma (although, of course, you could!), but without Me - you’ve got no customer base.  So you sell to Me - your CUSTOMER.

And the fact that I’m your customer means a lot.  In the retail trade, there’s an old axiom:

1 - the customer is always right.

2 - when in doubt, see rule #1 (above).

Basically, it means that the customer - Wilma to Me and Me to you - is the one that is truly driving the transaction.  Wilma has the cash to buy the widgets from Me and I’ve got the cash to buy them from you.  You, on the other hand, have the knowledge, equipment and supplies to create and provide those widgets to Me so that I, in turn, can provide them to Wilma in Walla-Walla and make her wonderfully happy.

The cost of the EDI - the testing, compliance, implementation - are yours.  At least for your side of things.  I wouldn’t expect you to pay for My set-up fees and implementation costs - as they’re a cost of doing business for Me.

Let’s spin this off in a slightly different direction - you package the widgets 50 to a carton.  That carton is a cost of doing business for you.  Are you going to charge Me for that carton?  Don’t think so.  Instead, you’ve figured a way to build that cost of the carton into your overhead - into your manufacturing costs - so that you’re covered for those costs. 

But you say “Hey!  Hold on now!  Wait a minute!” and you tell Me how I’m still paying for those cartons - in that I pay 1/10th of a cent for each widget to cover your costs of the cardboard cartons.  And, sure, you have a point - but it’s not truly a cost of doing business for Me.  It’s just part of the cost of the goods I’m buying - just like My overhead for the chain of widget stores is figured into the price I’m selling that widget to Wilma for in Walla-Walla.

So in the “who pays for what” equation, YOU pay for the costs of implementing and doing EDI with Me - just as I pay My side of those same costs of doing EDI with all of My suppliers and vendors.  I’m the 800lb gorilla in the room - I’m the one that has the control- or at least more of it - in this deal.  I’m the hub, I call the shots, I’m the driver.

At least that’s how it is in the world of widget retail.  But, as I’d posted over on the EDI-L group, it’s probably more of an “industry specific” kind of thing - that healthcare has different practices (best or not!) than retail has and they’re different from banking/finance which is different from universities and eduction which is different from … well, you get the idea, right?

So, on to your side - who pays for what…?  And where are we going to dinner…?

“I’m working through a client situation where multiple internal SKUs correspond to a single customer item number. Before I get on my high horse and insist that they always ship a complete customer item in a single shipment I thought that I’d ask if it is possible to send a valid ASN or Invoice in this case.

To be specific:

Client offers internal item numbers P0001a, P0001b and P0001c for sale as A0001. It is murphy inevitable that the shipping department will eventually ship P0001a, P0001b and P0001c in separate shipments (on separate days). Is it even possible to:

send an ASN that 1/3 of unit A0001 shipped on June 16, 2008

or

send an Invoice that 1/2 of the cost of unit A0001 is now due for that 1/3 A0001″

Now, here’s the thing to consider - how was it ordered…?  If the trading partner sent a PO for 100 of P0001a, 100 of P0001b and 100 of P0001c, then you need to ship 100 of each item.  If the trading partner wants all of them to ship together - then you need to follow the partner’s shipping instructions or requirements. 

And the same can be said for invoicing, as well.  Don’t invoice a partial shipment of a partial product.  Chances are quite good that you won’t be paid until the full shipment of the entire order (especially if it’s a COMPONENT set - more on that below!).  There are some fine lines here that can and may be crossed, but BOTH sides of this TRADING PARTNER RELATIONSHIP need to communicate about what is going on and what is expected.

One of the answers given over on the EDI-L group was about the possibility of ASSORTMENTS and CASE PACKING issues that are relatively common in the apparel industry.  In some cases, it may be called a “MUSICAL PACK” in which you have a single style of something - a shirt, a shoe, shorts, underwear, whatever - in assorted sizes in a single case.  For example, you’d have a case-pack of 24 and that 24 would be broken down by size, all the same style and color:

• 5 Small
• 7 Medium
• 7 Large
• 5 X-Large

That musical pack (or here’s the concept of assortment) could be broken down by color, instead of size - so that you’re ordering t-shirts, and they’re also packed in cases of 24, but all of a single size, but multiple colors - either pre-set selections or not:

• 3 Black
• 3 White
• 5 Blue
• 5 Red
• 4 Green
• 4 Yellow

Of course, that case could just be “here’s 24 shirts in colors” and whatever the order picker pulls from the shelf is what’s in the box - and it could be ANY quantity of colors - from 23 black and 1 yellow to 12 of a color and … well, you get the idea.

But it all comes back to shipping and invoicing what the trading partner has ordered or requested.  It still all goes back to the relationship (there’s that word again!) you have with the trading partner and what solutions have been worked out to take care of situations like this - either before they happen or on the fly as they occur.

One of the things I mentioned above was the concept of a COMPONENT set.  This CAN happen a LOT in retail - depending on the product line.  For example, in the sporting goods world, it’s quite common to have a weight set - barbells, dumbells, weight plates and so on - be packaged in 3 or 4 boxes.  But it’s a single COMPONENT that the sporting goods retailer sells.  In apparel, you could have a warm-up set (jogging pants & sweatshirt) or even a 3 piece men’s suit (slacks, vest, jacket) and when you order them up from the factory in ________, you order 100 slacks, 100 vests and 100 jackets and you combine them into 100 complete suits.  When you sell these to your trading partner, you sell them as a complete suit.  But someplace along the line (in your own systems, probably) you’ve converted those 3 seperate and unique - although related - items into a single item - a single SKU or UPC or Item Number.

That’s what we do when we’re ordering those previously mentioned weight sets.

Let’s assume that ACME Weights and Bars is selling a 100 pound weight set.  There are 4 five pound plates, 4 ten pound plates and 2 twenty pound plates.  Plus then you have the long and short bars that you hang the weights from and then you have the locking ring or collar that holds them on the bars.  And you package all of this in 4 boxes - 1 box for the collars, 1 for the long bar, 1 for the two short bars and 1 more box for the 10 plates.  Chances are, however, that the collars and the bars are probably universal and you would use them for nearly all of your weight sets - whether 100 lbs, 150 lbs, 200 lbs or whatever.  So you probably don’t limit the item name/number to just be with the 100 lbs set.

Anyway, now Willy’s World of Weights orders ten of your 100 lb sets.  And when they order them, they have to order 10 of item A (100 lb plates), 10 of item B (bars long), 10 of item C (collars) and 10 of item D (bars short).  But when Willy’s World of Weights SELLS those sets, they sell them all under one item number or SKU.  It’s now up to Willy’s World of Weights to convert those 4 different items into 1 item for sale.

That’s what we do when we order weight sets - we order them by four unique SKUs and Item Numbers (which are also 4 unique UPCs).  The vendor ships them - hopefully all at once (more on that below) - and we receive them.  Then we assemble them (virtually) by transferring all of the ordered and received stock of Items A, B, C and D into our single SKU 100 LB Weight set.

Now, one of the other questions or concepts posed by our poster is the concept that it is “inevitable that the shipping department will eventually ship P0001a, P0001b and P0001c in separate shipments (on separate days). “  This, however, falls on the fault of the vendor.  It then becomes the issue of the vendor (supplier) to be sure to quickly and accurately - and with GREAT COMMUNICATIONS - alert the trading partner to this dilemma.

In the retail world, it’s not such a huge issue if you have parts of a component set ship and have back-orders for the other parts; you just hold on to parts A, B and D until part C arrives and then you can sell them. 

Where this can and WILL cause problems, however, is in the manufacturing sector.  Take a look at the coat or jacket you wore today (or just have hanging around your desk, office or cubicle.  There are probably a few different kinds of material involved - there’s the outer shell (say 100% cotton) and then there is the inner shell or lining (nylon or polyester) and then there may be cuffs and collars (50% cotton, 50% Lycra) and then maybe even more in a liner/filling (50% cotton, 50% polyester).  And then there are the plastic buttons or metal zippers and the possible sewn on decorations….  and then there are the labels and the … again, you’re getting the idea? 

Well, let’s say that Cozy Coat Mfg is making that line of jacket.  And they’re ordering all of the supplies to make that jacket from FM Fabrics and Materials Inc.  Of course, common sense suggests that Cozy Coats isn’t ordering the materials in the just-in-time way of thinking - that they’re going to make 1000 jackets an order the materials - just in time - to put those 1000 jackets into production.  No, chances are they’re going to have mounds of the filling, boxes of buttons, bolts of the fabrics and … z … z … what’s a container that starts with z…?  Anyway, they’re going to have much of it around and in stock to produce what they need.

But still, if they’re ordering enough materials and parts to make their finished product, they’re keeping most of it on hand at any given time to not have any production delays that will result in their Summer 2008 line of jackets getting out late and not being in the stores until November of 2008 - thereby missing the concept of seasons…

But back to partial shipments - and the poster’s question - the answer to his question would be an almost absolute NO - but with some qualifications and possibilities of a “yes”.  It all comes back to communicating the problems - beforehand or as they occur - with your tading partner and coming to an agreement or compromise that benefits both parties.

And watch out for those 20 pound weight plates - they’re killers on the toes!

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!

Ah, the old “EDI vs XML” debate rears it’s enormous jumbo head of dissent again…  *sigh…..

XML is simply a language for possibly trading information in a human readable format.  Much like HTML (the language of the Internet), you use “tags” that tell you what the next piece of information is.  So you can have a simple tag of <NAME> and then a person’s name and then the closing tag </NAME>….  You can continue to use these simple kinds of tags for the rest of the information you’re sending (sending maybe an address, a 2nd line of address, a city, a state, a zip and more) and the human eye can read it as

John Smith
123 Main Street
Suite 123
Anytown
ST
92345

In his post at the Inovis blog, however, Bill makes an excellent point - and one I’ve touted before in other comments - in that XML may be easier (in the layout of tags and direct information) to read then EDI formats, but it’s all dependent upon the DTD and the schema.  It’s easier because there is no rigid, solid standard to follow.  “Data A” can be ANYWHERE in the document, as long as it’s labeled as “Data A”.  The DTD and the schema are a lot like the translation specs we use in EDI - in that it tells you what tags will contain what data and what it all means.

But it’s that same lack of a standard that makes XML so much more complicated and so much less a solid answer.  There’s no specific spot for that “Data A” mentioned above.  It can be ANYWHERE… and it’s the job of the DTD or schema to tell you where it is and what it means.

Kay Dietz (of Inovis) offers a great course (through the training roadshow) on XML 101 - giving you the most basics of basics - kind of like a sample when you’re at the store…  “Here, try this cookie.  Isn’t it the best? Aisle 3B, 4.99 a dozen!“  XML is a great thing - offering a lot of possibilities for the transmission of data between partners.  And it’s supposed to be human-eyes readable.

But that’s where the problem comes in….  If (as Bill mentions) you don’t know what this tag is and means, or you don’t know what the abbreviation or code I’m using is, how can you interpret the data.  And sure, the schema or dtd can tell you what that is, but you have to read it and/or format the document to tell you what it means….

XML is, at its most basic, a language.  Just like Cobol and C++ and HTML and Chinese and French and English and…. Well, you get the point.  But let’s take that comparison even deeper….  XML could be very similar to Chinese or English - in that you will have different variations on the same language, all depending upon who is speaking.  There are many different dialects in both languages.  In the Chinese language, if you have two people speaking two different dialects, then there is a lot that they cannot communicate.  In the English language, at least if there are two people and two dialects, most of it can come across.  This isn’t a failing in the Chinese language at all.

XML can be a lot like English or a lot like Chinese.  It can be similar and yet different or it can be different and different.  Let’s say I’m sending you an order.  I can send it with the tag <ORDER> and then the number and the closing tag (don’t forget that closing tag!)…  But what if you use <PURCHASE> in your own system.  Sure, that schema or DTD will let you know that I’m sending you the purchase order number in that <ORDER> tag, but you will have to look at the schema for that meaning.

In EDI, since there is a standard (whether ANSI/X12 or TRADACOM or ________), you know that if I’m sending an order, it will be in the BEG segment at location BEG03.  Always.  If you’re fluent in the “language” of EDI - the standard you’re using - you know exactly what information is in what segment and where to look for it and what format it will be in and all of that.  Just as if you’re fluent in English, you will know that in the Southern Dialect, “y’all” generally means “all of you” in a more formalized version of the language.

In My example above (about the name, address, etc., tags), the same information is carried in the N1, N3 and N4 segments.  And it also gives you a bit more information by the element designator (ST = Ship To, BT = Bill To, etc.) so you can also have the same information - but in a different format:

N1*ST*John Smith~
N3*123 Main street*Suite 123~
N4*Anytown*ST*92345~

And there you have the same information.  Sure, there’s the added symbols of * as an element separator and the ~ as the segment terminator, but it’s still readable, IF YOU KNOW THE LANGUAGE.

One of the things that Bill mentions (in the posting) is that EDI was not really supposed to be “human readable” - as it is/was a way of getting data from a source machine or system to a destination machine or system.  It was transferring data from My systems to yours.  If you want “human readable”, you create a report.  It prints out and has all the “tags” set up as field names (name, address, address, city, state, zip) followed by the appropriate data.

Hmmm… that’s just like the XML format of the data above - in that it’s now suddenly human readable.  But instead of having to have the user (aka the human) try and figure out what they mean - the report tells them exactly what they mean, because the data was transmitted and then translated via the standard spec.

Look at it this way - suppose you’re a maker/seller of … gum…  Just looking at the pack of Trident White on My desk, there are 12 pieces of gum to a pack.  Now, let’s say that you put 12 packs in a box.  Then there are 12 boxes to a carton.  And 12 cartons to a pallet.  That’s a lot of twelves…

Now I send you an order…

XML - <QTY>144</QTY>

EDI - PO1*1*144*EA*UP*445600456729~

In the XML version, I order 144.  But 144 what?  Each? Boxes? Cartons?  Pallets?  In the EDI version I give you My UOM (unit of measurement) in the line item detail.  To get that information to you in the XML format, I’d have to add another set of tags - like <UOM>EACH</UOM> or similar or tell you what that quantity means in the DTD or schema.  As a matter of fact, each element in the EDI segment has to have its OWN SET of tags for EACH piece of information…..  So now I’m sending all of this information to you - think about any kilo-character limits or charges you may have - and that simplicity of XML - that “freedom” now is costing you extra.

The XML for just that simple EDI line would look something like this:

<LINE>1</LINE>
<QTY>144</QTY>
<UOM>EA</UOM>
<UPC>445600456729</UPC>

Each piece of information for the item being ordered has to have a set of tags to designate it.  And for EACH and EVERY order I send you, you’re getting that same set of tags and data over and over and over again.  For each line item (style) I’m ordering, you’re getting all of those characters that make up those tags - over and over and over and over and….  Whereas with EDI, you get - hey, look - a separator (*)….  So, let’s just do a quick character count of the EDI PO1 segment I’ve got up there…. 29.  29 characters…  The same for an XML version of that line…?  Let’s see .. 14 for the qty line .. um .. carry the one .. divide by .. add .. Where’s that damn calculator..?!?  It came to 64 characters, btw.

 And the more “detailed” I make My tags (use QUANTITY instead of QTY, UNIT OF MEASURE instead of UOM) and you can see how it can REALLY start to add up.  Oh, and then you’re also sending that DTD or schema with EACH and EVERY document.  Imagine if you had to send your translation spec with EVERY document you send..

So, yeah, XML has some benefits in the simplicity department.. and in the “human interface” area.  But with no standards to abide by, no rules to play by, that human readability goes right out the window with whatever dialect you want to speak.