I was ignoring this thread as it just didn't make sense, without understanding industry/ERP/EDI system and integration of same, not sure what relevant answer I could give.
However, since it won't seem to go away, I'll add my 2 cents. In my 15 years or so of experience mostly in manufacturing, but also in retail, banking, and health care (shudder). I find that once implementations have been worked out (tricky, as explained in excellent detail by Michael), the majority of issues are what we lovingly refer to as PBCAK or ID-10-T errors. Sometimes these can be addressed systematically or programmatically, however, even training won't cover it all, and we live with it, look at it as job security. PBCAK = Problem Between Chair And Keyboard ID-10-T = well, figure this one out yourself ;) My favorite was a guy who "cut and pasted" data from an excel spreadsheet into a text field in a release, somehow managing to capture formatting from the spreadsheet which converted (on an old mainframe) into a hex "bell" character during translation to an 830, totally bombing the whole system. That was a fun one! Oh, and while I can't claim such a long time since my last drink (good for you Michael), I can honestly say that I average approximately 4 drinks per year, none of them in recent memory. Leah ________________________________ From: Michael Mattias/LS <[email protected]> To: EDI-L <[email protected]> Sent: Monday, December 29, 2008 9:21:22 AM Subject: Re: [EDI-L] the Big 3 - 810, 850, 856 12/29/08 >I am attempting to have a discussion on EDI topics, I am not sure if you >are drunk over the weekends, then go to an AA meeting. Well, I never attended a meeting, but I think I can take some small measure of pride in noting that today marks five thousand five hundred ten days since my last drink. (Yes, I still take it one day at a time). But I digress... >I asked what are the sort of issues that have existed in your experience. Perhaps that is what you meant, but it is not, sir, how I interpreted your post. I read you were concerned about how the '856' document "works" in your environment versus how the '850' does not 'work.' Now either I did not understand your question due to an inferior choice of words on your part, or you do not understand the uses of the 850 and 856, or you made a typo. While I may have been a tad brusque in my own choice of words, it is my considered opinion that other than the possibility of a typing error (unlikely since you have not issued a correction), either of the other causes for confusion here are significant deficiencies for anyone wishing to participate in a discussion of "EDI Topics." You may not agree with me, but there's no need to cast personal invective (which as it turns out was a lucky guess). All that said, in my experience (25+ years) the biggest *techinical* 'issue' which occurs in the exchange of the 'distribution industry documents' (810/850/856) is dealing with turnaround data - the information transmitted by the buyer in in the '850' which must be returned in either/both the 810 and 856. If your ERP system is not set up for this, you will have to develop your own 'tanking' subsystem to capture said information and retrieve it when needed. The biggest *non-technical* issue is poorly-developed implemenatation guides... missing information, fuzzy explanations, etc. (Damn, those 'communications skills' sure have a way of insinuating themselves into many places, huh?) For example, I recently handled a client mapping where a customer-developed '850' IG did not include either a "date wanted" or a "how to ship" ('regular', "overnight', etc) for the purchase order and we had to have a discussion with that customer as to what those values should be. That customer also did not include either his part number or a description of the items ordered anywhere in the PO1 loop.... which makes dealing with invalid, obsolete or superceded vendor part numbers tricky at best. And after we started testing, it turns out the customer never allowed for the possibility of the quantity discounts for which he could qualify. The seller - my client - generated the 810 invoice at the quantity discounted price - which caused a 'mismatch' in the buyer's system causing the invoice to be rejected. (This one we still have not solved). The bottom line for me is, if you want to be an "EDI Expert" - be it as an internal (employee) or outside (e.g moi) resource, you need to have mastered the techincal and non-technical fundamentals and understand the user's business before you can even begin to deal with the finer points. Then again, I'm an old fart who is pretty set in his ways. Michael C. Mattias Tal Systems Inc. Racine WI mmatt...@talsystems .com http://www.talsyste ms.com [Non-text portions of this message have been removed] ------------------------------------ ... Please use the following Message Identifiers as your subject prefix: <SALES>, <JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC> Job postings are welcome, but for job postings or requests for work: <JOBS> IS REQUIRED in the subject line as a prefix.Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/EDI-L/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/EDI-L/join (Yahoo! ID required) <*> To change settings via email: mailto:[email protected] mailto:[email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
