Nicely put, Pete!
________________________________ From: Pete Austin <[email protected]> To: Michael Mattias/LS <[email protected]> Cc: [email protected] Sent: Wednesday, May 22, 2013 1:27 PM Subject: Re: [EDI-L] Thoughts on format validation. As you are alluding to, you are referring to two distinct issues *Format validation* - This validation of EDI data ensures that it meets X12 standards compliance (and potentially industry compliance if you use VICS, WINS, UCS or the like). This is the job of the translator. Data that fails here should be flagged by the translator and sent it back to the submitter, if you wish for it to do so. (There are some cases where you would keep even bad data. Think high dollar Purchase Orders - I'm not ever sending them back no matter how crappy - I like money.) Setting aside a few rare niche eccentricities, you want the translator to ONLY validate to the standard and perform data translation of your EDI into a format that a downstream system can read. *Data Validation* - This is your downstream system, whether it is your core system, or an intermediate application that was custom-built for this purpose. This system should perform all of the business level validation needed to move the data cleanly into your core system. It should have business rules for data cleansing, data lookups, data consolidation, data routing, workflows for managing documents that fail the business rules, and the ability calling for help if stuck. Typically, this system can take feeds from multiple sources; your translator, your web, sometimes even from your CSRs that might manually enter orders. You do not want to mix the two. Placing business rules inside your translator is bad. Because: - A translator is a technical tool, not a business tool - Storing business rules within a translator creates another repository of business rules that needs to be managed and updated as your business changes - You need business people to understand and implement business rules. These folks will have no idea how your translator works - Translator folks frequently have no real understanding of how your business works - Writing code in a translator is convoluted, complicated, and requires skills that can be difficult to find and retain - If you change your translator, you have a nasty mess of business logic that you will need to rebuild. <Sarcasm> On the other hand, if you are a consultant, it does nearly guarantee a lifetime contract. </Sarcasm> Pete On Wed, May 22, 2013 at 12:08 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. > > > > > > ------------------------------------ > > ... > 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] [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/
