Critical Description
The issue generally
In the cases, when
- an account balance gets negative
- backdated transaction gets inserted
- and other, not tested cases that can be seen in the code
the transaction order of the already existing and new transactions gets mixed.
Steps to reproduce
- Deposit 100 - no issues so far, balance should be: +100
- Withdraw 100 - no issues so far, balance should be: 0
- holdAmount 50 -> available balance is negative - no issues so far, balance should be: -50
- releaseAmount 50 - no issues so far, balance should be: 0
- Deposit 100 - this should have been failed, but did not, balance should be: +100
So I repeated the steps: - Withdraw 100 - balance should be: 0
- holdAmount 50 -> balance should be: -50
- releaseAmount 50 - balance should be: 0
- Deposit 100 - balance should be: +100
was desperately bad.
Attached the screenshot of the transaction table.
Although the Saving account balance was correct at the end (+100), for the transactions neither the running balance nor the overdraft amount were correct. The number of transactions not reversed was ok, but in wrong order.
Additionally, several transactions (including the deposit and withdrawal transactions) were reverted and recreated. This we can not allow, because it means that the datatable references were lost.
It seems to me that unfortunately I really need to dig deep into the core code and change it. For this I need to understand all the possible use-cases, including past-dated transactions, because of which all these complicated revert steps happen.
Actual result
Expected result
The transactions must be ordered by value date (transactionDate).
Attachments
Attachments
Issue Links
- is a child of
-
FINERACT-1874 Release Apache Fineract 1.9.0
-
- In Progress
-
- links to