Rachel:
I agree 100% with your "real-world" comments. I have kids to feed too.
However, after many years of frustrating tweaking with translators to enable
some business rule or whatever, I now simply use the translator as a .. wait
for this, translator. EDI data comes in, 997 gets auto-turned-around, and a
nice flat file with different record types that contains all of the data
gets produced for IMMEDIATE post-processing with an industrial-strength
program developed utilizing the latest industrial-strength tools. Beautiful.
Regards,
Paul
-----Original Message-----
From: Electronic Data Interchange Issues [mailto:[EMAIL PROTECTED]]On
Behalf Of Rachel Foerster
Sent: Thursday, May 24, 2001 12:39 PM
To: [EMAIL PROTECTED]
Subject: Re: Dual 997's
Paul,
As I said, I too, used to argue strongly for independence and separation of
function. However, the real world is that one's clients don't always agree
and they want (no demand) a down and dirty solution. Anyone who's been in IT
for a while has most likely been caught between the rock of "good design"
and the hard place of "expediency."
One could starve and see one's home foreclosed by standing on the beach of
"proper design", etc. and not help your clients solve their problems in a
way that works but is also acceptable to them. I could be a purist all the
way to the poorhouse.
Don't worry too much about new/emerging technologies for the health care
claims (administrative processes). In its utter wisdom our Congress decided
to embed in legislative concrete the use of the X12 EDI syntax! Go figure!
Rachel
----------------------------------------------------------------------------
---
Rachel:
I believe that business rules should always be separated, even for
non-volatile, bureaucratic stuff like health-care claims. Because then you
have flexibility to quickly adapt your business to external forces such as
new programming tools (think Java, VB.Net) or to new communications
protocols (think HTTP, XML).
In business application software design, the holy grail is to separate
business logic from any other factor - presentation, data access method, or
protocol. Additionally, this functional separation does not entail any time
delays. What's not to like ?
Cheers,
Paul
|-----Original Message-----
|From: Electronic Data Interchange Issues
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster
|Sent: Wednesday, May 23, 2001 11:48 AM
|To: [EMAIL PROTECTED]
|Subject: Re: Dual 997's
|
|
|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
|
|
|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/
