Cocoa-Puffs commented on PR #6469: URL: https://github.com/apache/fineract/pull/6469#issuecomment-5793607306
Both findings are correct. During the retest after the previous round of findings a new scenario was found in which case the closing date turned out to be wrong. This was added as a deliberate test with testrail id: @TestRailId:C106757. The issue was that an overpaid loan with credit balance refund set the maturity and closed on dates as the date of the CBR, which was considered wrong, as a CBR hands back money that the loan never needed, so it is not what settled it. The solution was to take the latest transactions date the paid into any outstanding amount, instead of 100% overpayment. That's what made the closed on date move in @TestRailId:C98268 as well. Unfortunately this introduced a regression, while a Discount Fee Adjustment, while not a repayment removes part of the obligation, therefore can be the transaction that closes or settles the loan. The fix: Two changes in `WorkingCapitalLoanTransactionProcessor.java`. `recalculateMaturityOnOverpaid` now only moves the date later, and the already-settled branch of `recalculateClosure` is floored at the maturity the loan already carries. A floor rather than a direction ban, because the undo case still needs closedOnDate to move earlier — from the undo day back to the settlement it falls onto. The javadoc on both now says why: obligationsMetOn names the last payment the loan needed, which is the day obligations were met only when a payment is what met them, and the stamp is the only record of a settlement completed by something else. I have also added extra validations to @TestRailId:C83084 to pin down this behaviour. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
