I don't think we differ. I think we are talking about three different things. I am
not discussing HIPAA nor do I
think we are talking about the same kind of EDI shop.
>>can similarly be encoded in the IG so that it can be processed by the translator.
It sounds like you are talking about IGs in a computer format. That is an all
together different scenario than I am
addressing. I am talking about the scenario of the "800 lb gorilla" mentioned earlier
where you are lucky if the IGs
arrive in any computer format, let alone a computer processable format. Not too long
ago I receive a fax of a very
ugly formatted mainframe printout. Apparently the organization had switched to a UNIX
based translator but was still
diseminating copies of IG printouts from their previous system.
I recently worked with a state level standards committee that took computer
processable IGs from one state and
converted them to MS Word documents even though the IG development tool was available
at no cost. And, of course, the
standards varied by state and continue to change as we speak. Computer processable
IGs would be very helpful in this
real world situation.
Unfortunately, IGs in computer processable format are basically non-existent in most
EDI shops. Obviously, they're a
good idea but so far no standard has been widely adopted.
There are many reasons for not putting business logic in EDI translators. Most are
due to the fact that translators
are not programming tools nor are they meant to be. Deficiencies include:
Robustness of mapping language
Lack of debugging tools
Lack of configuration control
Lack of documentation tools
Lack of a data dictionary
Lack of reusable objects
Admittedly many EDI operations are rogue shops to which none of this matters but if an
organization applies the same
quality standards to EDI as they due to business programming, they will limit EDI
processing to the bare minimum.
The other issue that comes up is that, in addition to identifying business rule errors
such as you describe, you have
create error handling/audit logging that can be used to create an 824. No translator
does this automatically that I'm
aware of. They would just be application map errors that requires a programmer to
handle. I've spent the last year
working with the 824 and producing it from the inbound stream was awkward and
inelegant. Yes, I got it to work but
quite frankly it required effort and expertise that may not be available in all EDI
operations.
>>checking case sizes, discount
> levels against quantity can similarly be encoded in the IG
You are building an application within the translator. You don't want to do this.
Organizations have spent 10s of
millions to implement SAP R/3, Peoplesoft, Oracle, etc. to do this type of processing.
That's a lot of dollars to
justify. I wouldn't want it to get back to the CEO that we could have done it in our
$10,000 EDI translator.
Jim Divoky
----- Original Message -----
From: "Jonathan Allen" <[EMAIL PROTECTED]>
To: "Jim Divoky" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 7:52 AM
Subject: Re: Dual 997's
> 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/
