On another one of My readling places - the EDI-L group on Yahoo - and the topic came up about "who pays" for what...  The topic-starter was looking for some kind of "best practices" in the EDI world when it comes to new implementations.  I think a lot of the people are viewing this from the "dating" point of view - that the person who asks for the date is the one that pays for the date...  Basically, if I was to call you up and ask you to go out with Me to dinner and a movie - or drinks and dancing - or supper and se...  wait, keep that one quiet... anyway, if I'm doing the asking, I should be doing the paying... 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 ...

I've got a bad case of ... EDI VIRUS BLUES? The other day - on, yes, the EDI-L Yahoo Group - I read a post about how an Information Security department of a company was worried about the concepts of viruses and hackers gaining access through the EDI system and the documents we trade via EDI.  Most of the replies were, as you would suspect, "is your infosec group smoking crack..?!?" or something to the same thought.. But it does beg the question - how susceptible to a virus attack, a trojan horse, a hack or some other kind of attack are we through our EDI processes?  There are no virus scanners and other system tools to scan the data as it's coming into the system via our AS2 or bisync communications sessions.  There's not much to stop the virus or hack or trojan from getting into the system, now is there...? Sure, you may have a firewall set-up and the data must pass through the firewall, but you've basically given it permission to travel through that wall, anyway, simply by virtue of the fact that you've given permission to the connection that the data (virus laden or otherwise!) is traveling along. But that's about the place when their concept of the attack falls flat... Look at the way the ...

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

That's a pretty simple and straightforward kind of thing to say, isn't it?  I mean, it ... says ... what it means...   and if we follow the concept, life would be so much easier for all of us...  No more lying politicians or smarmy sales-pitches...  No more "hey, this product was supposed to do this, but it doesn't" kind of problems.  No more hurt feelings because you answer "does this (dress, shirt, tie, bathing suit, whatever) make me look (old, fat, ugly, whatever)" kind of questions truly - yes, your butt looks like a Buick in that silver sequin thing.  Sorry - a digression. But you get My meaning, right?  I mean it would be so much easier if we said what we mean and meant what we said and we weren't mean about it, either. For example - I've been away from the office for about a week, helping My mom - My dear, 73 year old mom - move.  She semi-retired from being a programmer/analyst last year.  I say semi-retired because now she works for the same company - but as a consultant instead of as a salaried employee.  But she also works remotely, with a nice little wifi/broadband modem card stuck out of the side of her laptop.  We're moving her from Las Vegas, Nevada ...

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