Cocoa-Puffs commented on PR #6588:
URL: https://github.com/apache/fineract/pull/6588#issuecomment-6142317006
**Re-aged installments ignoring FIRST_DAY_OF_NEXT_MONTH**
I reproduced it before fixing. With a re-age starting 31 Jan,
equal-amortization re-age produced 31 Jan, 28 Feb, 31 Mar, while the
recalculated-interest path produced 31 Jan, 1 Mar, 31 Mar.
Changes:
Added a strategy-aware overload
ScheduledDateGenerator.getRepaymentPeriodDate(frequency, n, startDate,
strategy). For monthly periods it uses MonthlyDueDateResolver.plusMonths; for
other frequencies it’s unchanged. Both re-age loops now pass the loan’s
strategy.
The due-date shifts after a re-age (the dateShiftOnly branch of
handleDueDateChangeOnRepaymentPeriod and
shiftReAgedInstallmentsAfterReschedule) now step through the same resolver
instead of newDueDate.plus(..., MONTHS). They now match the EMI-calculator
branch beside them, which already used the strategy.
**E2E UC9 changing a shared product**
UC9 now uses its own product, LP2_MONTH_END_DUE_DATE_PRODUCT_CHANGE, through
a new step, "Loan product {string} dedicated to this scenario exists with
monthEndDueDateStrategy {string}". The step creates the product from the LP2
roll template, or resets its strategy if it already exists, so a failed earlier
run can’t leave it in the wrong state. The restore step at the end of UC9 is
gone, and LP2_MONTHLY_END_DUE_DATE_ROLL is no longer modified by any scenario.
--
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]
