I can't believe it's been almost a WHOLE MONTH since I last posted a blog and My thoughts...  geez.  But, anyway, I was reading - gee, shocker! - another website (actually, My daily mailing of questions posed on the EDI-L group over on Yahoo!) - and the following question was posed: "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 ...

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 ...

WHOA!!!  In My readings, I just came across this article over at EC-BP.org!  Looks like we all get to start paying for our EDI transmissions!!  Author: Craig Dunham - EDI CoordinatorRead more about Craig here: http://editalk.com/contributors/

Over on the Inovis blog, Bill Chessman ponders about the human readability of XML vs. EDI.  A different take on an old debate.  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".  ...