FINERACT-2790: Fix NoSuchElementException on Merchant Issued Refund for re-aged progressive loans - #6344
Conversation
…or re-aged progressive loans AdvancedPaymentScheduleTransactionProcessor.updateRepaymentPeriodBalances() did not exclude isAdditional() installments before calling ProgressiveEMICalculator.getDueAmounts(), which throws NoSuchElementException because additional installments (inserted by a prior re-age) are filtered out of the EMI model's repaymentPeriods at build time. This surfaced when a Merchant Issued Refund with MERCHANT_ISSUED_REFUND payment allocation and futureInstallmentAllocationRule = LAST_INSTALLMENT selected an additional installment as the in-advance target. The fix excludes isAdditional() installments the same way isDownPayment() installments are already excluded, consistent with the existing convention used elsewhere in this module (both are treated as 'special installments' excluded from EMI-model-based lookups).
|
Hey @adamsaghy , failure unrelated to my code. Please retrigger whenever possible. |
|
hey @adamsaghy , please let me know your thoughts on this one, thanks! |
|
@AshharAhmadKhan Thank you for your interest in this, but one of my DEV is already working on this, i would like to see what the diff between the two PRs |
Hey @adamsaghy, checked PR #6347. The main fix is identical to mine, same guard clause. The difference is #6347 also adds a second layer of protection in ProgressiveEMICalculator, plus two integration tests that reproduce the actual production scenario. I've only done unit tests on mine. Happy to close this one once #6347 is out of draft and passing, or you can decide either way, just let me know. |
2 participants
JIRA
https://issues.apache.org/jira/browse/FINERACT-2790
Problem
A Merchant Issued Refund on a progressive loan schedule crashes with an unwrapped NoSuchElementException when the loan has an "additional" installment in its persisted schedule (inserted by a prior re-age), the product has down payments enabled, and the payment allocation rule is MERCHANT_ISSUED_REFUND with futureInstallmentAllocationRule = LAST_INSTALLMENT.
The crash happens because AdvancedPaymentScheduleTransactionProcessor.updateRepaymentPeriodBalances() did not exclude isAdditional() installments before calling ProgressiveEMICalculator.getDueAmounts(). Additional installments are filtered out of the EMI model's repaymentPeriods at build time, so a lookup using an additional installment's dates has nothing to find.
Grepped all call sites of isDownPayment() and isAdditional() in fineract-progressive-loan/src/main/java and found 17 places where both are already excluded together. This is an established convention in the module: down payment and additional installments are both "special installments" excluded from EMI-model-based lookups. The LAST_INSTALLMENT selection logic already excludes isAdditional() from candidacy, so this was a downstream consumer that hadn't caught up to that rule, not a missing design decision.
Fix
Excludes isAdditional() installments in updateRepaymentPeriodBalances() the same way isDownPayment() installments are already excluded.
Verification
Added test coverage to the existing AdvancedPaymentScheduleTransactionProcessorTest and ProgressiveEMICalculatorTest suites (no standalone ticket-numbered test classes, per the module's convention):