[
https://issues.apache.org/jira/browse/FINERACT-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krishna Mewara updated FINERACT-2532:
-------------------------------------
Description:
*Bug Description:*
When a loan reschedule request contains both a DUE_DATE shift and an EMI_AMOUNT
change, the generated repayment schedule fails to apply the new EMI amount
correctly to the shifted installments. The new EMI amount is either applied to
the wrong installments or skipped entirely.
*Root Cause:*
The issue originates in how the {{AbstractCumulativeLoanScheduleGenerator}}
processes {{EMI_AMOUNT}} term variations alongside a {{DUE_DATE}} term
variation.
The {{EMI_AMOUNT}} variations (which are {{isSpecificToInstallment=true}} and
created at the original installment dates) are being incorrectly consumed
during schedule generation because the iterator-based {{hasVariation()}}
matching logic ({{!DateUtils.isAfter(applicableDate, scheduledDueDate)}})
evaluates multiple pre-shift variation dates as matching the early post-shift
installment dates. This causes the EMI overrides to be exhausted before they
reach the correct periods.
*Steps to Reproduce (via Integration Test):*
This bug is currently causing
{{testCreateLoanRescheduleRequestForInterestAppropriationAndFixedEMI}} to fail
on upstream {{develop}} (commit {{46abf58ee}}).
# Create a loan with 12 monthly installments.
# Submit a combined reschedule request that shifts the {{adjustedDueDate}}
forward by several months AND applies a new fixed {{emi}}.
# Approve the request.
# Observe that the generated schedule does not correctly apply the fixed EMI to
the shifted periods (the test expects a reverted EMI of 15417 for period 8, but
receives the overridden 5000 instead).
was:
*Bug Description:*
When a loan reschedule request contains both a DUE_DATE shift and an EMI_AMOUNT
change, the `approve` phase fails to remap the dates of the new EMI variations
to align with the shifted schedule. This results in the new EMI being applied
to the wrong installments (or being skipped entirely) during schedule
generation.
*Root Cause:*
In `LoanRescheduleRequestWritePlatformServiceImpl.java`, during the `approve()`
method, there is a date-remapping loop designed to shift active term variations
forward when a DUE_DATE variation shifts the schedule.
However, the term variations belonging to the current request are only
activated (`updateIsActive(true)`) after this remapping loop has executed.
Because they are `isActive=false` during the loop, the new EMI variations keep
their original, pre-shift dates. When the `ScheduledDateGenerator` later runs,
it mismatches these old variation dates against the newly shifted installment
dates.
*Steps to Reproduce (via Integration Test):*
This bug is currently causing
`testCreateLoanRescheduleRequestForInterestAppropriationAndFixedEMI` to fail on
upstream `develop` (commit 46abf58ee).
1. Create a loan with 12 monthly installments.
2. Submit a combined reschedule request that shifts the `adjustedDueDate`
forward by several months AND applies a new fixed `emi`.
3. Approve the request.
4. Observe that the generated schedule does not correctly apply the fixed EMI
to the shifted periods.
*Proposed Fix:*
In `LoanRescheduleRequestWritePlatformServiceImpl.approve()`, move the
activation block (`mapping.getLoanTermVariations().updateIsActive(true)`) to
execute before the date-remapping loop. This ensures the newly approved EMI
variations are included in the `activeLoanTermVariations` list and correctly
shifted alongside the rest of the schedule.
> Combined DUE_DATE and EMI_AMOUNT reschedule requests fail to remap EMI
> variation dates upon approval
> ----------------------------------------------------------------------------------------------------
>
> Key: FINERACT-2532
> URL: https://issues.apache.org/jira/browse/FINERACT-2532
> Project: Apache Fineract
> Issue Type: Bug
> Components: Loan
> Environment: Upstream develop branch (commit 46abf58ee)
> Reporter: Krishna Mewara
> Priority: Major
>
> *Bug Description:*
> When a loan reschedule request contains both a DUE_DATE shift and an
> EMI_AMOUNT change, the generated repayment schedule fails to apply the new
> EMI amount correctly to the shifted installments. The new EMI amount is
> either applied to the wrong installments or skipped entirely.
> *Root Cause:*
> The issue originates in how the {{AbstractCumulativeLoanScheduleGenerator}}
> processes {{EMI_AMOUNT}} term variations alongside a {{DUE_DATE}} term
> variation.
> The {{EMI_AMOUNT}} variations (which are {{isSpecificToInstallment=true}} and
> created at the original installment dates) are being incorrectly consumed
> during schedule generation because the iterator-based {{hasVariation()}}
> matching logic ({{!DateUtils.isAfter(applicableDate, scheduledDueDate)}})
> evaluates multiple pre-shift variation dates as matching the early post-shift
> installment dates. This causes the EMI overrides to be exhausted before they
> reach the correct periods.
> *Steps to Reproduce (via Integration Test):*
> This bug is currently causing
> {{testCreateLoanRescheduleRequestForInterestAppropriationAndFixedEMI}} to
> fail on upstream {{develop}} (commit {{46abf58ee}}).
> # Create a loan with 12 monthly installments.
> # Submit a combined reschedule request that shifts the {{adjustedDueDate}}
> forward by several months AND applies a new fixed {{emi}}.
> # Approve the request.
> # Observe that the generated schedule does not correctly apply the fixed EMI
> to the shifted periods (the test expects a reverted EMI of 15417 for period
> 8, but receives the overridden 5000 instead).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
