[
https://issues.apache.org/jira/browse/FINERACT-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133958#comment-18133958
]
Jose Alberto Hernandez commented on FINERACT-3016:
--------------------------------------------------
Fineract PR created https://github.com/apache/fineract/pull/6776
> Re-age after maturity leaves re-aged installments without interest on
> recalculation loans
> -----------------------------------------------------------------------------------------
>
> Key: FINERACT-3016
> URL: https://issues.apache.org/jira/browse/FINERACT-3016
> Project: Apache Fineract
> Issue Type: Bug
> Components: Loan
> Affects Versions: 1.16.0
> Reporter: Jose Alberto Hernandez
> Assignee: Jose Alberto Hernandez
> Priority: Major
> Labels: bug, interest-recalculation, progressive-loan, re-age
> Fix For: 1.17.0
>
> Attachments: migration-report-20261028-155112.html
>
>
> h2. Background
> On a progressive loan with interest recalculation enabled, a re-age with the
> default interest handling re-prices the re-aged periods with the EMI
> calculator
> (\{{AdvancedPaymentScheduleTransactionProcessor#handleReAgeWithInterestRecalculationEnabled}}
> -> \{{ProgressiveEMICalculator#updateModelRepaymentPeriodsDuringReAge}}).
> This works while the re-age date falls inside the schedule. When the loan has
> already reached its original maturity date, the re-aged installments come out
> with no interest and the outstanding balance drops to zero after the first
> re-aged installment, so the borrower is charged no interest for the new term.
> The behaviour does not depend on the repayment frequency: a plain monthly
> loan shows it as well. It was found while testing the semi-monthly frequency
> (FINERACT-1322, PR #6546) and is reported separately because it is
> pre-existing.
> h2. Steps to reproduce
> # Create a progressive loan product (advanced payment allocation) with
> interest recalculation enabled, declining balance, daily interest, 30/360,
> rest frequency daily, 24% a year, 4 monthly installments.
> # Disburse 1000 on 15 September 2022; make no repayments. Maturity is 15
> January 2023.
> # On 20 March 2023 (after maturity) re-age the loan: \{{POST
> /v1/loans/{loanId}/transactions?command=reAge}} with
> \{{frequencyType=MONTHS}}, \{{frequencyNumber=1}}, \{{startDate=15 April
> 2023}}, \{{numberOfInstallments=3}}, default interest handling.
> # Read the repayment schedule.
> The same can be reproduced at engine level with \{{ProgressiveEMICalculator}}
> alone: build the model, call \{{recalculateModelOverdueAmountsTillDate(model,
> 20 March 2023, false)}} and then
> \{{updateModelRepaymentPeriodsDuringReAge(model, 15 March 2023, 15 April
> 2023, 20 March 2023, terms, mc)}} with the same \{{LoanApplicationTerms}} the
> processor builds.
> h2. Expected behaviour
> Each re-aged installment is charged the interest of its own period on the
> balance it starts with, and the loan amortises to zero on the last
> installment. Re-aging the same loan on 20 March 2023 *before* maturity (4
> installments disbursed on 15 January 2023) gives, for the three re-aged
> installments, interest 60.00 / 13.99 / 7.07 and principal that amortises to
> zero. The same is expected after maturity, with the first installment
> carrying the longer period.
> h2. Actual behaviour
> After maturity the re-aged installments get interest 96.33 / 0.43 / 0.00, the
> outstanding balance after the second re-aged installment is 21.72 and the
> third is pure principal. On a semi-monthly loan (due on the 15th and the last
> day, disbursed 15 January 2023, matured 15 March 2023, re-aged on 20 March
> 2023 from 15 April 2023) the second and third re-aged installments carry 0.00
> interest and the balance is already 0 after the first one, with both daily
> interest and "same as repayment period" with partial periods.
> h2. Analysis
> With interest recalculation the overdue principal is carried forward through
> balance corrections on the interest periods (\{{adjustOverduePrincipal}}).
> While the re-age date falls inside a period, \{{accelerateMaturityDateTo}}
> turns that period into the early-repayment holder, the negative aggregated
> correction sits on the transaction date and
> \{{moveOutstandingAmountsFromPeriodsBeforeTransactionDate}} reverses it, so
> the re-aged periods start from the full outstanding balance. After maturity
> no period contains the transaction date: \{{accelerateMaturityDateTo}} does
> nothing, the negative aggregated correction was never placed, and moving the
> outstanding amounts of every earlier period subtracts each period's own
> principal, so the last period enters the re-aged part of the schedule with
> only its own principal (261.16 of 1000 in the semi-monthly case, 272.14 in
> the monthly one) and the re-aged periods run out of balance after the first
> installment.
> Simply extending the last period up to the transaction date (so it plays the
> holder role) is not enough: the balance entering the extended period is still
> the reduced one, so the fix has to address how the balance corrections of
> periods past maturity are moved during the re-age.
> h2. Affected modules
> * \{{fineract-progressive-loan}} —
> \{{ProgressiveEMICalculator#updateModelRepaymentPeriodsDuringReAge}},
> \{{moveOutstandingAmountsFromPeriodsBeforeTransactionDate}},
> \{{accelerateMaturityDateTo}}, \{{adjustOverduePrincipal}}
> h2. Acceptance criteria
> * A re-age with default interest handling after the original maturity date of
> a recalculation loan charges each re-aged installment the interest of its
> period on its opening balance and amortises to zero, for monthly and for
> semi-monthly loans.
> * Re-age before maturity is unchanged.
> * Unit test on \{{ProgressiveEMICalculatorTest}} covering the after-maturity
> case, and an integration test on \{{LoanReAgingIntegrationTest}}.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
