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

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

"Ch-ch-changes... Turn and face the strange..." - David Bowie belted out back in 1972.  Well, 1971, actually, but the song wasn't released until 1972.  And, as usual, I digress in the details.  But still, some of the lyrics are quite appropriate today.  And especially in the world of EDI.  Good ol' Ziggy Stardust (aka Bowie) sang out:                                    "Still don't know what I was waiting for.." That's something we hear a lot in the EDI world - once somebody finds out how well EDI can help them.  They don't know what they waited for - or balked against - when given the option of EDI.  Once they've seen-the-light, it suddenly becomes a no-brainer.  But at the time, it was strange and unknown and a change.  And we all know what people can be like when it comes to change.. Don't we? Change is hard! What's wrong with the way we've always done it? Oh, great!  Now what do I have to learn? Right now, I'm working with our Accounting group in getting them to embrace and accept the 810 EDI Invoice.  And, for the most part, I'm lucky that they're open and willing to "face the strange" and go with it..  However, where it's making My life a living hell is that they expect everything to be done.  Now.  2 Minutes ago.  ...

My take and thoughts from a post over on the EDI-L Yahoo group about the type of data to provide to a Catalog service. There's a lot of "push" these days - and has been for years? - about Electronic Catalogs.   Many of the bigger networks/VANs have a catalog service (Inovis & SPS Commerce come to mind) and there are probably more offered out there by companies - big and small - EDI network or not - that can house that data and provide it to your customer base. This is where you, as a vendor/supplier/manufacturer, can store your product information data - colors, sizes, UPCs, style numbers, descriptions, and more - that can then be accessed by your buyers - the retailers and resellers - for their systems.  Some of the information is used by the end user and some is not. Then on the flip side - there's Me - the retailer.  I subscribe to the catalog service provider (in My case - Inovis) and look to that data for product information.  In our case, we're pretty much only looking to verify the Style Number and UPC information.  Since we decided LONG AGO to not use the NRF size or color codes, that information is irrelevant to us.  Also, we tend to use our own item ...