DUPLICATE A CHARGE TRANSACTION FOR ADDITIONAL BILLING

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

Yes, it’s certainly doable.

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

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,

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

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

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.

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