FINERACT-1152: Use projected schedule to validate EMI end date in loan reschedule

[San-43]

Description

This PR fixes FINERACT-1152; loan reschedule validation and term-variation generation for EMI changes with endDate when other reschedule changes (for example extraTerms) are submitted together.

Previously, EMI/end-date validation effectively depended on the current installment schedule, which could reject valid requests where the end date only exists in the projected post-reschedule schedule.

Changes

• Updates EMI/end-date validation to enforce:
  • both fields are required together
  • emi must be positive
  • endDate must not be before rescheduleFromDate
• Builds projected installment due dates using pending reschedule variations, then creates EMI term variations using those projected dates up to endDate
• Returns a validation error when endDate is before the next projected installment date
• Adds/updates tests:
  • unit tests for validator behavior
  • integration test covering EMI + extra terms using projected future schedule
• Updates Swagger request model with endDate and emi fields for create-reschedule request payload examples

I would like to mention #5619 since it helped me to have a better overall view of the problem and the potential fix. Hope this goes well. Pls let me know if anything should be changed.

Checklist

• Write the commit message as per our guidelines
• Acknowledge that we will not review PRs that are not passing the build ("green") - it is your responsibility to get a proposed PR to pass the build, not primarily the project's maintainers.
• Create/update unit or integration tests for verifying the changes made.
• Follow our coding conventions.
• Add required Swagger annotation and update API documentation at fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with details of any API changes
• This PR must not be a "code dump". Large changes can be made in a branch, with assistance. Ask for help on the developer mailing list.

[San-43]

Hello @adamsaghy, sorry to bother you. After carefully reviewing everything, running tests in my local environment, and double-checking the failure causes, I’m convinced this was baseline/pipeline drift, as I suggested in a comment on FINERACT-1152. Could you please approve the workflows again? And if you have time, could you also review my changes?
I’m also posting evidence of the corresponding e2e checks passing locally:

EMICalculation-Part2

LoanChargeOff-part4

Please let me know if there is anything wrong.

WorkflowLink

[San-43]

Another baseline/pipeline drift?

  Then Loan is closed with zero outstanding balance and it's all installments have obligations met                                                                                            # org.apache.fineract.test.stepdef.loan.LoanStepDef.loanClosedAndInstallmentsObligationsMet()

Failed scenarios:
file:///home/runner/work/fineract/fineract/fineract-e2e-tests-runner/src/test/resources/features/LoanCapitalizedIncome-Part2.feature:53 # Verify Capitalized income and Caplitalized income adjustment - Accounting and repayment schedule handling in case of loan is overpaid (Capitalized Income Scenarios - UC9)

32 Scenarios (1 failed, 31 passed)
723 Steps (1 failed, 1 skipped, 721 passed)
4m11.799s


org.opentest4j.AssertionFailedError: 
expected: 600L
 but was: 700L
	at org.apache.fineract.test.messaging.event.EventCheckHelper.lambda$loanAccountDataV1Check$6(EventCheckHelper.java:208)
	at org.apache.fineract.test.messaging.EventAssertion$EventAssertionBuilder.extractingData(EventAssertion.java:145)
	at org.apache.fineract.test.messaging.event.EventCheckHelper.loanAccountDataV1Check(EventCheckHelper.java:173)
	at org.apache.fineract.test.messaging.event.EventCheckHelper.loanBalanceChangedEventCheck(EventCheckHelper.java:160)
	at org.apache.fineract.test.stepdef.loan.LoanStepDef.createCBR(LoanStepDef.java:629)
	at ✽.Admin makes Credit Balance Refund transaction on "15 April 2024" with 15 EUR transaction amount(file:///home/runner/work/fineract/fineract/fineract-e2e-tests-runner/src/test/resources/features/LoanCapitalizedIncome-Part2.feature:720)

[San-43]

I believe this is ready for review/merge.

[San-43]

Another baseline/pipeline drift?

  Then Loan is closed with zero outstanding balance and it's all installments have obligations met                                                                                            # org.apache.fineract.test.stepdef.loan.LoanStepDef.loanClosedAndInstallmentsObligationsMet()

Failed scenarios:
file:///home/runner/work/fineract/fineract/fineract-e2e-tests-runner/src/test/resources/features/LoanCapitalizedIncome-Part2.feature:53 # Verify Capitalized income and Caplitalized income adjustment - Accounting and repayment schedule handling in case of loan is overpaid (Capitalized Income Scenarios - UC9)

32 Scenarios (1 failed, 31 passed)
723 Steps (1 failed, 1 skipped, 721 passed)
4m11.799s


org.opentest4j.AssertionFailedError: 
expected: 600L
 but was: 700L
	at org.apache.fineract.test.messaging.event.EventCheckHelper.lambda$loanAccountDataV1Check$6(EventCheckHelper.java:208)
	at org.apache.fineract.test.messaging.EventAssertion$EventAssertionBuilder.extractingData(EventAssertion.java:145)
	at org.apache.fineract.test.messaging.event.EventCheckHelper.loanAccountDataV1Check(EventCheckHelper.java:173)
	at org.apache.fineract.test.messaging.event.EventCheckHelper.loanBalanceChangedEventCheck(EventCheckHelper.java:160)
	at org.apache.fineract.test.stepdef.loan.LoanStepDef.createCBR(LoanStepDef.java:629)
	at ✽.Admin makes Credit Balance Refund transaction on "15 April 2024" with 15 EUR transaction amount(file:///home/runner/work/fineract/fineract/fineract-e2e-tests-runner/src/test/resources/features/LoanCapitalizedIncome-Part2.feature:720)

Same error

[DeathGun44]

Other than that I like this approach ,LGTM

[San-43]

Other than that I like this approach ,LGTM

Thank you very much @DeathGun44! I really appreciate your review.