DUPLICATE A CHARGE TRANSACTION FOR ADDITIONAL BILLING

[john benevento]

Would someone know whether it is possible, using the translation configurator, to duplicate a charge transaction (based on the charge code) so that an additional charge transaction can be sent along with the original charge?  (For example, if a drug is administered to a patient by injection rather than by mouth, an additional charge would be generated for the injection).  Thanks for any suggestions!

Topic

[Jim Kosloskey]

John,

I think that is possible.

However, in my opinion, the Integration Engine is not the correct place to be creating charges.

There is virtually no acceptable audit potential and folks have been known to sue over unsubstantiable charges.

There might even be some violation of various billing rules, etc.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Vince Angulo]

Yes, it’s certainly doable.

[Scott Lee]

Vince Angulo wrote:

The source application’s charge services module should accomodate this.

There are a lot of things the sending and receiving systems should do that they do not.  That is why we have interface engines.  Certainly the first preference is for the sending system to send the charges correctly but since they may not be able to do that…

I think as long as you can document what your engine is doing and have a way to show which charges were created by the engine then there is no reason not use the full capabilities of the engine to get the job done.  It would be a simple matter to write a line to a file every time you add a charge within the engine.  This file could then be used as the audit log on those charges.  

Not as clean as having the sending system do it for you but, IMHO, it’s better than having someone keying a charge manually.

Scott

[john benevento]

Vince,

Based on your suggestion, I created an xlate consisting of a BULKCOPY, a SEND, an IF statement to catch the charge to duplicate (containing a COPY to move in the new charge code, and another SEND), and finally a SUPPRESS.  The problem I’m having is that the new charge transaction messages remain in pending and are not transmitted unless I stop and start the thread.  Is there something I’m missing?  Thanks.

[Vince Angulo]

Hi John,

We’ve done the logic differently here:

BULKCOPY

…

…Table or tcl proc to return whether the message needs to be duped

…

IF @SecondMsg eq =True

    SEND

    COPY in new CDM

–End IF–

The xlate process would send the second message with no other SEND or SUPPRESS needed.  But I don’t see why your messages would stall as pending…maybe someone else can tell us.

[john benevento]

Thanks for your suggested code – I’ll give it a try.  The problem I think has to do with the Message Control ID in MSH:  it is not incremented when the new transaction message is created, so you get two messages with the same ID.  Incrementing it by one in the xlate doesn’t help if you have another message with the same (new) ID.  I am not familiar with TCL so I can’t write a proc to accomplish this.  Is there a simple way to increment the ID in the xlate for all the messages?

[Jim Kosloskey]

John,

The MSH-10 content of an HL/7 message in and of itself will not cause messages to queue Pending in the Engine.

What may be happening is the receiving system is not acknowledging or the duplicate MSH-10 causes the receiving system to NAK the message and you are not handling that properly.

email me and I will email you a Tcl proc to manage the MSH-10 in an Xlate.

Jim Kosloskey

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Michael Hertel]

Quote:

The problem I’m having is that the new charge transaction messages remain in pending and are not transmitted unless I stop and start the thread.

When you say pending, what state are the messages in the recovery database?

-mh

[john benevento]

The problem only occurs when the value of MSH-10 is the same in two transactions sent in the same batch.  When I send out a batch consisting only of the original transaction plus the newly-created one (with MSH-10 incremented by 1 in the xlate), it works fine.  However, if there are additional transactions in the batch, and if one of them duplicates the value of MSH-10 in the new transaction, everything stops flowing and inbound replies (of the new transaction) are generated and placed in pending (state 11) every 60 seconds (the timeout value).  I don’t know Cloverleaf well enough to understand what’s going on, but a TCL that increments MSH-10 for every transaction (and provides an accurate message count in BTS-1) would probably solve the problem.

[Michael Lacriola]

I’ve read all the replies and I think I have a better solution for you. You are sending another charge transaction if it meets some criteria. In a Xlate, you could user CONTINUE when you ave your first outbound side ready to go, then concat an “A” on the end of MSH.#10 to make the value different (instead of a counter) and do whatever else is necessary for the second outbound message. The you can either issue another CONTINUE command followed by a SUPRESS (for clarity) or just let it go from there. Xlate will always send what’s left on the outbound side. In this case it would be the “duplicate.” MSH.#10 is usually used just to send back with the ACK stating that it received the message. If they are specific about that field using numbers only (because thefield on their side is numeric) concatenating the “A” on the end of MSH.#10 will not work.

I also agree with not creating additional charges via the engine. However, sometimes you just have to do what is necessary to get it right because the vendor cannot comply.

[Michael Hertel]

If the receiving system doesn’t care that the number is sequential, just needs to be different, make MSH-10 equal to 12345 for the new transaction and be done with it.

Since you are only spinning off 1 message and following the spin off, a new message with a new MSH-10 will come thru so you won’t have to worry about counters or duplicates.

To add my 2 cents, I agree with the rest of those who think the engine should not create charges.

Hope this helps,

-mh

[Author]

Replies