Cocoa-Puffs opened a new pull request, #6534:
URL: https://github.com/apache/fineract/pull/6534
## Description
COB optimization for WorkingCapitalLoanRepayment and
WorkingCapitalNearBreachEvaluation feature files. Some additional issues were
noticed during testing and some tests had more modifications then just date
changes.
1. C76648
Original problem. With 9 days / freq 6 the single eval was 01-06, and the
three payments (01-02, 01-04, 01-06) all landed on or before it: 550 paid
against 450 required. After rescaling to 6 days / freq 3 there is no offset
that puts three payments spread over 01-02..01-04 on or before 01-03. The
payment schedule itself had to be re-shaped. Two payments on 02 Jan (200 + 150)
and one on 03 Jan (200). 550 ≥ 450 by the eval date again.
2. C80952
Original problem. With 9 days / freq 3 the evals were 01-03 and 01-06, and
the post-payment COB landed on effective date 01-05 strictly between them. So
eval 1 still governed, its requirement was 29.997, and the backdated 50 would
have cleared it. The comment ("if re-evaluated, 50 ≥ 29.997 would NOT trigger")
was true, and that is what made the scenario a test of immutability.
After rescaling to 6 days / freq 2 the evals became 01-02 and 01-04, and the
same COB (effective 01-05) now sits past both. Eval 2 governs, requiring 2 *
29.997 = 59.994, and the backdated 50 falls short of it. A re-evaluating
implementation would have set true as well, so the scenario could no longer
distinguish immutability from re-evaluation. It asserted true and got true for
the wrong reason.
Why the obvious fix is insufficient. The natural repair is to move the COB
back between the two evals (effective 01-03). That restores the stated
counterfactual, but it still does not make the scenario fail if the
immutability gate is removed. The gate is a read gate, and evaluatePeriod only
ever writes true or false; it never writes back to null. With the gate removed,
a mid-period re-evaluation that passes writes nothing at all and the stored
true survives untouched. The only place a stored true can be overwritten is the
close-out branch at the period end.
Fix. Three coordinated changes:
- trigger earlier — COB on 03 Jan (effective 01-02 = eval 1), no payment,
nearBreach = true;
- raise the backdated repayment from 50 to 60, so the cumulative bar is
cleared at both eval points (29.997 and 59.994);
- run the post-payment COB to 07 Jan, so the effective date reaches toDate
(01-06) and the close-out branch is actually exercised.
A re-evaluating implementation now falls through to close-out and writes
false; the assertion demands true. That is a genuinely failing case for a
broken gate — something neither the old nor the rescaled version had. The
assertion grows a period-2 row and P1's breach becomes true, because the run
now reaches the period end. Cost: +1 COB run.
3. C85322
Original problem. Pre-existing. This one was equally non-discriminating
before the rescale, for exactly the reason described above. The rescheduled
config (threshold 50%, freq 3) gives a single eval at 01-03 requiring 45. The
post-payment COB ran at business date 06 Jan, effective 01-05, which is inside
the period. Whether or not the gate exists, the stored true is what you read
back: with the gate it short-circuits, without it the re-evaluation passes (50
≥ 45), writes nothing, and leaves true in place.
Fix. The payment amount already clears the requirement, so only the timing
needed to change: move the post-payment COB from business date 06 Jan to 07
Jan, so the effective date reaches toDate (01-06) and close-out runs. Without
the gate the flag would be overwritten with false; the assertion demands true.
Same shape as the C80952 fix, same +1 COB run, and the assertion gains the
period-2 row and breach = true for the same reason.
4. C85316
Original problem. Also pre-existing rather than introduced here. The
scenario pays 28, posts a RESCHEDULE raising the threshold to 50% (= 45), and
asserts nearBreach = true. But 28 is below the default bar too (33.33% of 90 =
29.997), so the default config would have triggered as well. The assertion was
satisfied by both configurations, which means it proved nothing about the
rescheduled threshold being the cause.
Fix. Pay 35 instead of 28: above the default bar (29.997) and below the new
one (45).
- default config (freq 2, threshold 33.33): evals 01-02 and 01-04; at
effective 01-03, eval 1 governs and 35 ≥ 29.997 → no trigger, flag stays null;
- rescheduled config (freq 3, threshold 50): single eval at 01-03; 35 < 45 →
true.
Now only the rescheduled threshold can explain the observed true. The
outstanding assertion moves from 62.00 to 55.00. No COB timing change, so no
cost.
## Checklist
Please make sure these boxes are checked before submitting your pull request
- thanks!
- [ ] Write the commit message as per [our
guidelines](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [ ] 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](https://fineract.apache.org/docs/current/#_testing) for verifying the
changes made.
- [ ] Follow our [coding
conventions](https://cwiki.apache.org/confluence/display/FINERACT/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"](https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit).
Large changes can be made in a branch, with assistance. Ask for help on the
[developer mailing list](https://fineract.apache.org/#contribute).
- [ ] If merging this PR resolves a JIRA issue, I will mark that issue as
resolved and set "Fix Version/s" appropriately.
- [ ] I followed the [AI
Policy](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#ai-policy).
Your assigned reviewer(s) will follow our [guidelines for code
reviews](https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide).
--
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]
