Jim,
Regardless of the form/condition etc. of the 800-lb gorilla's EDI
specification is received in, one still has to create a map (or use an
existing one) in their EDI system in order to process what they receive in a
raw X12 data stream. I too have received so-called specs from trading
partners that were nothing more than a screen print of a raw X12
interchange. So what! I still have to figure it out and get the map into the
EDI system. And I still have to then apply the X12 rules and business rules
against the received data stream.
Any EDI management system worthy of the name will perform all of the
functions you say EDI translators don't do and I would never advise a client
to spend good money on one that didn't offer the array of functionality
described by Jonathan. Today's advanced EDI management systems ARE
programming tools...the best of them even write program code for you behind
the scene and one never has to be a programmer.
Whether you're processing a HIPAA mandated transaction set or a 800-lb
gorilla transaction set, it doesn't make any difference if you can validate
what you receive against what you're supposed to be receiving....EDI
compliance, IG compliance, business rules, warts and all.
The 997 is a relic and appears to have outlived its early usefulness with
the availability of the new enhanced 824.
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/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
