In some recent readings on other websites - geez, you'd wonder if I actually have a job with all the reading and blogging I do - there have been recent posts, blogs, commends, entries and more, about how it seems like the old adage about the right hand not knowing what the left hand was doing is still alive and well and with us today - no life support needed... Over on the EDI-L board, one of our own forum members, Earl, was discussing - well - venting - about his current client and some issues with testing through one of those 3rd party EDI providers (won't mention any names!)...  But if you read it, you know.  Anyway, part of this goes back to the trading partner of his client - we'll call them ABC COMPANY, INC....  So, in good faith and in following with the concepts of implementation, Earl's been working to complete the testing for his client to trade with ABC Company.  Now it turns out that the division at ABC Company that they've been testing for has been sold off to another company - XYZ, LLC.  And now testing is no longer needed. Forget about the costs that the client has encountered in testing with the EDI provider.  Forget about the costs that have ...

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

One of the things you may have noticed about Me when I blog, is that I tend to find a quote or a saying or a song lyric or a ... something ... that makes sense and drives My thinking.  The title of this blog comes from the 1995 film by (and starring) Mel Gibson called "BRAVEHEART".  For those that don't know, it's the story about fighting for freedom in Scotland in the ... 1500s?  One of the more "famous" quotes is when Mel Gibson yells out something about how they may kill them (the Scots) but they'll never take their freedom! Freedom, however, in something as strict and regimented as EDI may seem like a far fetched notion, but it's there.  Sure, we've got those lovely guides - those HUGE books - of standards and "rules" for the data we're sending - depending on the document - that tell us what we can send and how it should be formatted and all the rest.  Those standards tell us we should send this information in this loop in this segment in this element and it should be between 2 and 30 characters in length. But in that rigidity - in that structure - there's still some freedom.  Just look at the last sentence in the above paragraph - we're ...

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