Personally, I think the potential scenarios described by Jonathan below are
an excellent example of what could be done with a bit of ingenuity. Being
able to apply business rules during the syntax analysis step is much more
efficient than passing incomplete or inaccurate transactions back to the
application system, which now has to apply these business rules, or worse
yet, having to write a pre-application (or post-translation) processor to do
the same thing.
It makes wonderful sense to me and this capability is long overdue in my
mind.
Rachel
Jim,
> I agree a lot of users do what I call syntax checking based on an IG and
> report back in a 997. By this I mean checking structure: Are the expected
> segments and fields present?; code validation: Are the codes used
> acceptable? If this is what you mean by reporting against an IG then I
> would agree that many EDI users do this.
Good - we have some common ground :-)
> Unfortunately many IGs include pages of business rules and many notes
> throughout the segment details that are not and cannot be handled by a
997.
At this point we start to differ. I am only too well aware that many IGs
contain reams of business stuff, but a lot of it could be handled by the
enhanced 997 (now the enhanced 824) if properly presented.
For example, you often find notes against one of the segments in an N1
loop, that says something like:
If a Buyer (N1.01 = 'XXX') then use codes A1, B1, C1; if Seller
(N1.01 == 'YYY') then use codes A1, C1, D1 or E1; otherwise use
codes D1 or F1.
There must be at least one instance of the Buyer, Seller and Shipping
N1 loops.
In my mind, all that is static syntax and can be checked by a translator,
although it does take a little care to arrange it in processible form.
Of course, there are bound to be many other dependencies within the N1
loop, but these should all be grouped together so that the translator
switches context into the dependency group that the initial qualifier
specifies. IMPDEF, for example, has a constraint mechanism for describing
exactly this in a neat tree structure.
Once there, checking code lists and reporting against (A1, B1, C1) or
(A1, C1, D1, E1) or (D1, F1) is the normal checking process and can
be reported using a 997 in the usual way - it would just be more helpful
to be able to express the context as to exactly *why* a code value was
incorrect in that specific context.
All sorts of similar business rules: checking case sizes, discount
levels against quantity can similarly be encoded in the IG so that it
can be processed by the translator.
Jonathan
----------------------------------------------------------------------------
--
Jonathan Allen | [EMAIL PROTECTED] | Voice:
01404-823670
Barum Computer Consultants | | Fax:
01404-823671
----------------------------------------------------------------------------
--
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
