[
https://issues.apache.org/jira/browse/FINERACT-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Santa updated FINERACT-2011:
----------------------------------
Description:
h1. 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.
h1. 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.
h1. Actual result
!savings_transactions.png!
h1. Expected result
The transactions must be ordered by value date (transactionDate).
was:
h1. 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.
h1. 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.
h1. Actual result
!savings_transactions.png!
h1. Expected result
The transactions must be ordered by value date (transactionDate).
> Savings Account - transaction order is incorrectly mixed after certain
> activities
> ---------------------------------------------------------------------------------
>
> Key: FINERACT-2011
> URL: https://issues.apache.org/jira/browse/FINERACT-2011
> Project: Apache Fineract
> Issue Type: Bug
> Components: Savings
> Reporter: Peter Santa
> Priority: Critical
> Labels: BeanSalad
> Attachments: savings_transactions.png
>
>
> h1. 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.
> h1. 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.
> h1. Actual result
> !savings_transactions.png!
>
> h1. Expected result
> The transactions must be ordered by value date (transactionDate).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
