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

A member of the site emailed this into us today, its an upcoming Webcast on eBridge and BizTalk. Empower Your Business Process: Transact and Integrate with EDI eBRIDGE has partnered with Microsoft® to bring you an informative webcast on how eBridge integration can streamline your business process and increase the value of your Microsoft Dynamics™ ERP by eliminating timely and costly manual data entry. This presentation will demonstrate how a complete EDI document exchange and integration system is achieved with the ePortal Software-as-a-Service (SaaS) platform from eBRIDGE Software. Through the power of BizTalk® Server, the ePortal handles all data routing, communication, translator and mapping services. Document transactions can be viewed from any station that accesses the internet. Click here to register for the Webcast.

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