[ 
https://issues.apache.org/jira/browse/FINERACT-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839575#comment-17839575
 ] 

Kigenyi Wilfred commented on FINERACT-1957:
-------------------------------------------

You are right, currently the SavingsTransactionComparator first compares the 
transaction_date, then the created_date and lastly the Id if it is available. 
The problem is that transaction_date will always be the same for the two 
transactions (so it is not helpful in this case) and the created_date is null 
(that is what I have seen in the m_savings_account_transaction table) so it is 
also not helpful. So this leaves us with the Id which is not reliable in this 
case since the order cannot be dictated. Instead of using the created_date I am 
trying compare using created_on_utc since it has milliseconds and is not null

> Unpredicatable assignment of running balances to withdrawal transactions that 
> are happening on the same involving withdrawal charges
> ------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: FINERACT-1957
>                 URL: https://issues.apache.org/jira/browse/FINERACT-1957
>             Project: Apache Fineract
>          Issue Type: Improvement
>          Components: Savings
>    Affects Versions: 1.7.3, 1.7.2, 1.8.3, 1.8.2
>            Reporter: Kigenyi Wilfred
>            Assignee: Francis Guchie
>            Priority: Major
>             Fix For: 1.10.0
>
>         Attachments: WithdrawalTransactions1.png, WithdrawalTransactions2.png
>
>
> Consider a savings a account that has automatic withdraw charges of 1%. When 
> a withdraw transaction of happens it will automatically cause a withdrawal 
> charge transaction to happen at the same time. Both these transactions will 
> be listed on the account but running balances on the two transactions are 
> some times interchanged.
> Attached is a screenshot of case.
> In the ScreenShot1, the latest transaction (with ID = 71890) is not assigned 
> the correct account balance and that balance is instead assigned to the 
> second last transaction (id = 718889)
> In the ScreenShot2, the latest transaction is assigned the correct account 
> balance which is correct. However this behavior is unpredictable in other 
> words one one cannot reliably tell the account balance by looking at the 
> running balance of the latest transaction. There should be consistence, that 
> is, the latest transaction on account should reliably be assigned the current 
> account balance. 
> This inconsistency can lead errors when when determining the opening and 
> closing balance when making  a report about an account considering an opening 
> date and a closing date.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to