AshharAhmadKhan opened a new pull request, #6344: URL: https://github.com/apache/fineract/pull/6344
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): - updateRepaymentPeriodBalancesSkipsAdditionalInstallmentAndAppliesPaymentDirectly asserts getDueAmounts() is never called for an additional installment and that the payment is applied directly to its own persisted principal balance instead. - getDueAmountsThrowsNoSuchElementExceptionForAdditionalInstallment reproduces the original crash mechanism directly against ProgressiveEMICalculator. -- 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]
