Samantha is addressing what I meant when I said industry specific. I know I'll get flack on this from some of you about Walmart/Sears/Penney's, etc. But, a PO is a PO. When you're working in a JIT environment for manufacturing and plant up or down time depends on goods movement, you don't want to accidentally map OEM-f's weekly requirement into a monthly bucket or worse yet, suddenly forget they're ordering in cumulative quantities and not discrete, they won't thank you for shipping 10,000 axles when they wanted 100, or shipping OEM-c 0 when they wanted 10,000. Nor do you want OEM-h's shipment to show up later than they asked for in their 862, which has times to the quarter hour. I have seen a supplier shut down an OEM-g plant with bad EDI data. They lost their contract, the business and were out of business not too long after. That's what you might call "risky".
Try factoring in comments in an IG like "for ship to x the first 2 weeks of the 16 week forecast begin after the current and next week and for ship to y the 16 week forecast begins during the current week, but the 52 week forecast begins the week after the current week, for all other ship to's the 16 week forecast and 52 week forecast begin in the current week" and that's just for one OEM. Oh, and before you start thinking that's not too bad, the FST qualifiers are the same for the 16 week and 52 week forecast buckets. Leah ________________________________ From: Samantha Scott <[email protected]> To: shluft <[email protected]> Cc: [email protected] Sent: Friday, February 8, 2013 11:17 AM Subject: Re: [EDI-L] [TECH] 1 map vs many partner based maps (Best EDI Practice?) I do exactly that - to a point. Inbound docs such as orders use one map (one 850 and one 875, that is) with every segment active and a few from different versions stuffed in there like MSG MTX and N9 in the same map. I have a codelist that stores what qualifiers each customer prefers for parts and dates. That map goes to a standard layout that I use to do validations and integrations into the ERP. What the customer might send to indicate a ship date and cancel date might be different but what I do with those dates once I have them is always the same. Not everyone does this part of the work. Some EDI systems do just the EDI translation but in my opinion SI is overpowered and overpriced if you have it doing just EDI translation. Because that integration work can take some time and throw errors for reasons that should not inconvenience the external customer, I separate it from the EDI translation so that they get their 997 based on the EDI translation and not internal integrations. For outbound invoices and ASN's I have found its not worth having one map. They all use different segments and I have this personal rule that if I have to use the function "empty" then I am doing something wrong upstream and working too hard. If you need to manipulate the data you get from your internal systems in the same way for every customer then make a map that does that for everything and then pass it to the individual partners maps for EDI translation. I do maintain a standard generic outbound map that has all the different things a customer could want and all the segments activated and I use that one as a basis for making my new customer map. In that way, much time is still saved in bringing up new partners. Occasionally I have to update every single outbound map for a transaction if something has changed but that can't be helped. Testing is a matter of grabbing production files and running them with the new map in test to make sure they match the production copies with the exception of the change I wanted to see (if it was something I wanted to see). On Feb 8, 2013, at 10:47 AM, shluft wrote: > Hi. > > In preparation to our SAP migration I've offered my boss to migrate our > numerous customized and mostly simple per-partner maps into centralized map > driven by partner-based parameters configured within the EDI system (Sterling > Integrator). > > My boss was challenging me whether this was within "Best practices of EDI". I > understand this is rather conceptual issue, and question is whether it would > be hard to maintain centralized map (whenever there is a need to change > something for 1 partner, you'd have to retest the data for all of them, I get > that :))) > > Never the less, if EDI is not ran by consulting shop, and the long term goal > is reducing maintenance and cost - would this approach fall within "Best > practices of EDI" and would there be any documentation out there to support > it, other then exchange of opinions of EDI gurus on this mailing list? > > Yeah, and I wana fries with that! > > Happy Friday! > > :)))) > > Thanks! > > Ilia. > > [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 [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: [email protected] [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/
