Both Harold and Michael are correct. All functions regarding data which is correctly formatted per ANSI/EDIFACT/etc. syntactical rules should be passed to the application "as is". It is then the application which should accept or reject the data based on whatever business logic/criteria are required. Are you not also "integrating" this new division into your ERP? If so, the question is moot.
If you need more support than the opinions of this group, then explain that in both ANSI/EDIFACT there is a document specifically designed for the purpose of reporting data "content errors" (which is what this is) that document is the 824/APERACK. They can feed you back an error message and you can send it back in this document. You are a hero. Just a small 2 cents: building "logic" into a PO number is stupid and lazy. (yes, I'm a bit grumpy today) Leah ________________________________ From: Harold DeWayne <[email protected]> To: Michael Mattias/LS <[email protected]> Cc: [email protected] Sent: Wednesday, May 22, 2013 12:14 PM Subject: Re: [EDI-L] Thoughts on format validation. My thoughts exactly On May 22, 2013 12:09 PM, "Michael Mattias/LS" <[email protected]> wrote: > > > > > I have questions about tight application validation. We are consolidating one of our division into our national translator. It > > turns out the division is performing >validation on the format PO NUMBER within the EDI map. So if the format is not right, it > > will reject the PO, even if it is valid EDI data according to the standards. >On our national translator we allow the valid > > numbers to enter into the application and depend on the application to validate the actual format. > > > > What are the thoughts as to what is the "right" way to handle formatting issues? > > "Right" is subjective, but my thought is that there must be two distinct and separate edits here: one for ANSI X12/EDIFACT syntax > compliance and one for application validity; and any system handling this kind of data must be prepared to deal with either of two > distinct and separate errors. > > Let your 'national translator' "translate"..don't try to make it do applications edits at the same time, a job for which it likely > is singularly unprepared. . > > YMMV. > > [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/
