[
https://issues.apache.org/jira/browse/FINERACT-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133756#comment-18133756
]
Mario Lopez commented on FINERACT-3015:
---------------------------------------
cc [~adamsaghy]
> Bullet Progressive Loans Rescheduling with wrong interest
> ---------------------------------------------------------
>
> Key: FINERACT-3015
> URL: https://issues.apache.org/jira/browse/FINERACT-3015
> Project: Apache Fineract
> Issue Type: Bug
> Affects Versions: 1.16.0
> Reporter: Mario Lopez
> Assignee: Mario Lopez
> Priority: Major
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> h2. Progressive reschedule bills capped interest on principal grace
> *Project:* FINERACT
> *Type:* Bug
> *Component:* Loan / Progressive loan
> h3. Summary
> On a progressive loan, a principal-grace repayment can bill less interest
> than the period accrued after an interest-rate reschedule, and the unpaid
> difference is pushed onto a later installment. Separately,
> `changeInterestRate` starts the new rate on the day before the date that was
> submitted.
> h3. Environment
> Progressive loan schedule (`loanScheduleType = PROGRESSIVE`), declining
> balance, daily interest. Reproduced in `ProgressiveEMICalculator` on current
> `develop`.
> h3. Principal-grace rows bill the capped installment
> h4. Steps
> 1. Create a bullet loan: principal 100,000, grace on principal for the first
> 11 of 12 monthly repayments, actual days, 360-day year, 20%.
> 2. Disburse on 1 January 2026.
> 3. Reschedule the interest rate to 15% from 1 May 2026.
> 4. Read the interest due on the repayment for 1 June 2026.
> h4. Actual
> June bills 1,291.49. The missing 0.18 is unrecognized interest and is carried
> forward. Later grace rows do the same whenever that month's accrual is above
> the installment solved for the reschedule, and the balloon collects the
> accumulated difference.
> `100,000 × 15% × 31 ÷ 360 = 1,291.67`
> h4. Expected
> Each principal-grace row bills the interest that period accrued. June bills
> 1,291.67, unrecognized interest on that row is 0, and the balloon bills only
> its own month of interest plus the 100,000 principal.
> An amortizing loan is unchanged: its installment is already principal plus
> interest, so one period of interest fits inside it. A 30-day month (`rate ÷
> 12`) is also unchanged, because the solved installment is already above that
> flat accrual.
> h4. Cause
> `calculateEMIValueAndRateFactorsForDecliningBalanceInterestMethod` solves one
> equal installment and writes it onto every related period, then
> `applyPrincipalMoratoriumIfRequired` copies `getDueInterest()` onto each
> grace row.
> `getDueInterest()` is already `min(calculated interest, installment)`. At
> origination the solved installment is the full annuity, which is larger than
> one month of interest, so the grace row gets the full accrual. After a rate
> change the new installment can be smaller than a 31-day accrual. Grace then
> copies the smaller number.
> The outstanding balance also has to be refreshed while walking the grace
> rows. The solved installment is still charging a little principal on earlier
> rows in the slice, so the next row accrues on a balance slightly under the
> real outstanding and its calculated interest is already short before the cap
> is applied.
> h4. Fix
> For each in-slice grace period, in due-date order:
> 1. Refresh that row's outstanding balance from the previous row.
> 2. Set the installment to `getCalculatedDueInterest()` (the uncapped accrual,
> including any unrecognized interest already carried in).
> 3. Do not lower the installment below principal and interest already paid,
> net of credits.
> The row stays principal-grace, so principal due stays 0. The installment for
> the remaining amortizing period is solved again afterwards. With one period
> left, that is principal plus that period's own accrual.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
