interesting problem in QTP
Arthur Kogan
akogan@westpac.com.au
Thu, 25 Jun 1998 10:23:49 +1000
Hi all,
I have the following problem in QTP and any suggestions would be welcome.
The QTP is a large and complex one with many requests and ideally I would like
to keep it still as one QTP, rather then breaking it up into several.
The basic purpose of this QTP is to apply financial transactions (contained in
a subfile) to members' accounts. The transactions are either positive or
negative. Before actually applying transactions to the member's account, there
is a request which simulates this, checking at each transaction if the
application of it would push the member balance into negative. If this is the
case, the transaction is flagged as an error and not applied. So far, so good.
The complication occurs with some types of transactions, which have an
accompanying transaction, such as a government tax on the original transaction.
So you may have a "contribution" transaction of $1000 and a "tax" transaction
of -$10. Alternatively you may have a "reverse contribution" transaction of
-$1000 and a "reverse tax" transaction of $10. In either case, either both
transactions should be applied or neither. Because we know which transaction is
a pair to the other one, we can mark the other as also being an error if the
first one is, i.e. this is not the problem.
The problem occurs because due to the required sort order, these transactions
may not come consecutively. So you may have a situation as follows:
Original member balance is $5 and you have the following transactions (this is
a simplified example only):
transaction amount resulting balance
transaction accepted
"reverse tax" $10
$15 Yes
"some other" -$7
$8 Yes
"reverse contribution" -$1000
-$992 No
Now because "reverse contribution" transaction was not accepted, we also reject
its pair "reverse tax" transaction. Which leaves the following situation:
transaction amount resulting balance
transaction accepted
"some other" -$7
-$2 Yes
This results in the member having a negative balance, which must be avoided.
The above is a simplified example and in reality there could be numerous
transactions like that, i.e. removing one pair of transactions, may cause
another pair to become invalid, and removing this pair may invalidate other
transactions and so on...
Ideally, I would like to repeat this request as many times as required until no
more transactions are rejected. This however is not possible with QTP. My
current thought is to split the QTP into 3 parts (i.e. part 1 contains all the
requests before this one, part 2 contains this request, and part 3 contains all
the requests after this one). Then I can run part 1 once, part 2 the required
number of times, and part 3 once. I still have not thought about how I will
determine when to stop repeating part 2.
Any suggestions are welcome.
Arthur Kogan
Westpac Financial Services
Sydney, Australia
Open VMS (ALPHA)
RMS files
Powerhouse 7.10F4
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.