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.