Aman-Mittal opened a new issue, #186:
URL: https://github.com/apache/fineract-backoffice-ui/issues/186
## Summary
Fineract supports two loan schedule engines — `CUMULATIVE` (the classic
schedule engine) and
`PROGRESSIVE` (advanced payment allocation). They are not variations on one
product: each has
fields, transaction types and servicing actions the other does not support,
and several are
mutually exclusive.
The loan **product** screens model this well today. The loan **account**
screens do not: they
treat every loan the same regardless of which engine it runs on.
## Business value
**A back-office user cannot tell which engine a loan runs on, and the screen
offers them things
that engine does not support.**
- **Two permanently empty tabs on every cumulative loan.** *Buy Down Fees*
and *Capitalized
Income* render for every loan account. Both are capabilities of the
progressive engine, so on a
cumulative loan they can never contain anything. A user who opens them
sees an empty table with
no explanation and cannot tell whether the loan genuinely has no buy-down
fees or the feature
does not apply. That is a support call, and it teaches users to distrust
empty states elsewhere.
- **Two wasted API calls per loan view.** Both tabs fetch unconditionally
for any loan with an
external id, and both discard their errors silently. On a cumulative loan
these are guaranteed
to return nothing useful, on every single loan open.
- **A correctness risk when creating a loan.** The loan application form
copies the repayment
strategy from the selected product, but falls back to the standard
strategy if the product
detail request has not resolved. A progressive product *must* carry the
advanced payment
allocation strategy — the standard strategy is precisely the value it can
never have. The
fallback is not guarded by schedule type, so a slow or failed product
fetch can submit a loan
whose strategy contradicts its product.
- **The schedule type is decorative.** The loan view computes
`isProgressiveLoan()` and uses it
for exactly one thing: the colour of a chip. Nothing else on the screen
changes.
Fixing this means an officer sees only the actions and tabs that apply to
the loan in front of
them, and the application form cannot submit a strategy the product forbids.
## Comprehensibility for non-specialists
Schedule type is the single most consequential choice on a loan product, and
the vocabulary
around it — payment allocation order, capitalized income, buy-down fee, down
payment — is not
self-explanatory to someone new to lending operations. Where these controls
appear, they should
carry plain-language help explaining what the setting does in business
terms, and a disabled
control should say *why* it is disabled rather than simply being greyed out.
The application already has the mechanism for this (`HelpIconComponent` and
the `HELP.*` keys);
it is simply not applied to the schedule-type-specific fields.
## Scope
- Gate the *Buy Down Fees* and *Capitalized Income* tabs, and their
requests, on the loan's own
`enableBuyDownFee` / `enableIncomeCapitalization` capability flags, which
`GET /loans/{id}` already returns.
- Guard the repayment-strategy fallback in the loan application form so a
progressive product can
never be submitted with the standard strategy.
- Reset the active tab if the selected tab is not available for the loan.
- Add plain-language help text to the schedule-type-specific fields, and
explain disabled states.
## Test coverage
There are currently **no unit tests anywhere that touch loan schedule type**
— all existing
coverage is real-backend end-to-end, which does not run in the fast feedback
loop, and only
exercises the progressive direction. Two branches with real defect risk have
never been tested:
1. **Mutual exclusion** — that a cumulative product *excludes* the advanced
payment allocation
strategy, and that switching progressive → cumulative clears the
processing type and the
payment/credit allocations.
2. **Type-gated availability** — the inverse assertion, that
progressive-only tabs and actions are
*absent* on a cumulative loan.
This issue adds unit tests for both, a mocked Playwright spec (so it runs in
the fast CI project,
not only against a live backend), and a step in the recorded feature demo.
## Acceptance criteria
- [ ] Buy Down Fees and Capitalized Income appear only when the loan reports
the capability, and
their requests are not issued otherwise.
- [ ] A progressive product cannot submit the standard repayment strategy
from the loan form.
- [ ] Unit tests cover both the mutual-exclusion and the
type-gated-availability branches.
- [ ] A mocked Playwright spec asserts a cumulative loan does not show the
progressive-only tabs.
- [ ] The recorded demo shows the difference between the two engines.
- [ ] Schedule-type-specific fields carry help text that reads sensibly to a
non-specialist.
--
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]
