FINERACT-2455: Updated e2e tests for rework WC loan schedule model to use recurrent calculations

[ruzeynalov]

Description

Describe the changes made and why they were made. (Ignore if these details are present on the associated Apache Fineract JIRA ticket.)

Checklist

Please make sure these boxes are checked before submitting your pull request - thanks!

• 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.
• If merging this PR resolves a JIRA issue, I will mark that issue as resolved and set "Fix Version/s" appropriately.

Your assigned reviewer(s) will follow our guidelines for code reviews.

[galovics]

Confirmed test-only, and I independently re-derived the schedule math against the actual production calculator for every scenario rather than trusting the regenerated numbers - all of it reproduces exactly, including the rate-segment scenarios, so there's no sign of the non-monotonic-balance issue that was found on #6339.

One thing that's actually failing CI though: scenario C102416 ends with And The retrieved amortization schedule has no negative monetary amounts, but that scenario never runs Admin retrieves the projected amortization schedule - it only uses the has N periods step, which doesn't populate the context the assertion step reads from. This is the only scenario in the whole suite that asserts on "the retrieved schedule" without retrieving it first, and it's exactly what's failing shard 10 with a null-response error. Easy fix - either add the retrieve step before that line, or drop it.

Non-blocking: C102414 mostly duplicates the existing C98194 scenario (same product/amounts, same first few rows) with less coverage of the interesting tail - might be worth folding one into the other rather than keeping both.

Recommendation: CHANGES_REQUESTED

[ruzeynalov]

Confirmed test-only, and I independently re-derived the schedule math against the actual production calculator for every scenario rather than trusting the regenerated numbers - all of it reproduces exactly, including the rate-segment scenarios, so there's no sign of the non-monotonic-balance issue that was found on #6339.

One thing that's actually failing CI though: scenario C102416 ends with And The retrieved amortization schedule has no negative monetary amounts, but that scenario never runs Admin retrieves the projected amortization schedule - it only uses the has N periods step, which doesn't populate the context the assertion step reads from. This is the only scenario in the whole suite that asserts on "the retrieved schedule" without retrieving it first, and it's exactly what's failing shard 10 with a null-response error. Easy fix - either add the retrieve step before that line, or drop it.

Non-blocking: C102414 mostly duplicates the existing C98194 scenario (same product/amounts, same first few rows) with less coverage of the interesting tail - might be worth folding one into the other rather than keeping both.

Recommendation: CHANGES_REQUESTED

@galovics Thank you for the feedback

C102416 - agreed, fixed.

C102414 vs C98194 - I would keep both, see my explanation below.

Both tests share the product and rows 1-3 but exercise different things:

• C98194 calls the explicit generate endpoint on a submitted loan, pins the tail (rows 210-212) and then rejects the loan. C102414 disburses and reads back the model persisted at disbursement with no generate call, which is the path a real loan takes.
• C102414 is the only scenario pinning payment 5 (amortization 8.93). That cell is the carry-forward diagnostic from the normalization work in FINERACT-2455: Rework WC loan schedule model to use recurrent calculations #6369: the high-precision value 8.924171922530 rounds to 8.92 on its own, and only the fraction carried over from days 1-4 gives 8.93. C98194 does not assert that cell.

[mariiaKraievska]

LGTM

[adamsaghy]

LGTM

All concerns were addressed