Paul,
I too used to argue strongly for not applying any business rules during the
transaction process. However, over time I'm come to realize that there are
benefits to doing so. I'm not saying that ALL application edits are moved
into the EDI system, but rather a subset of them. One of the reasons used in
the past for not trying to apply business rules in the EDI system was that
yesterday's EDI systems were inadequate to the task. Today's systems are
not. The sooner one identifies errors and returns acks back to the
originating system is a better approach. Else, why have pre-order processing
systems that handle dialogue directly with customers prior to passing a
complete and correct order in to the order management system?
But, I'm not at all advocating that everyone take any one approach. Let each
enterprise determine what makes best business sense for itself and its
trading partners. I'm all for flexibility and agility and less rigidity.
Rachel
----------------------------------------------------------------------------
---
Rachel said:
| 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.
Yes and no. You must apply the X12 rules, but you should not apply the
business rules. The business rules validation properly belongs in the
internal application software - as Jim has so eloquently espoused. Why
duplicate all the logic in your EDI system - even if translator companies
are trying to shoe-horn programming functionality into their products.
I believe the heart of this debate lies in the interpretation of an
Implementation Guideline. If one believes that all necessary rules - X12 and
business - can be obtained from the IG, then why not go ahead and do all
validation as soon as possible? Because business rules are far too dynamic
due, in part, to day-by-day market fluctuations. i.e. My company today will
accept this large 850 even though the ship date is unreasonable, but,
tomorrow, we will not. Therefore we do want to acknowledge syntactical
receipt of the document but we may want to refuse agreement to produce said
850.
Cheers,
Paul
|-----Original Message-----
|From: Electronic Data Interchange Issues
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster
|Sent: Tuesday, May 22, 2001 9:56 PM
|To: [EMAIL PROTECTED]
|Subject: Re: Dual 997's
|
|
|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/
=======================================================================
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/
