Jose Alberto Hernandez created FINERACT-3016:
------------------------------------------------
Summary: 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
Fix For: 1.17.0
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)
