Aman-Mittal opened a new issue, #190:
URL: https://github.com/apache/fineract-backoffice-ui/issues/190
## Summary
The loan product form has no control for capitalised income or buy-down
fees, so neither can be
turned on for a product created in this application. Both are modelled by
the API, on the product
request, the product response and the loan account response.
Missing from the form:
| Field | Allowed values |
|---|---|
| `enableIncomeCapitalization` | boolean |
| `capitalizedIncomeType` | `FEE`, `INTEREST` |
| `capitalizedIncomeCalculationType` | `FLAT` |
| `capitalizedIncomeStrategy` | `EQUAL_AMORTIZATION` |
| `enableBuyDownFee` | boolean |
| `buyDownFeeIncomeType` | `FEE`, `INTEREST` |
| `buyDownFeeCalculationType` | `FLAT` |
| `buyDownFeeStrategy` | `EQUAL_AMORTIZATION` |
## Business value
**This closes a loop the application opened itself.** #187 gated the
*Buy-Down Fees* and
*Capitalised Income* tabs on the loan account screen on the loan's
`enableBuyDownFee` /
`enableIncomeCapitalization` flags — correctly, since a tab that can never
hold anything is worse
than no tab. But nothing in this application can set those flags, so today
those tabs can only
ever appear for products created elsewhere. The gating works and the feature
behind it is
unreachable.
Beyond that:
- **Two revenue-recognition models are unavailable.** Capitalised income
lets fee or interest
income be recognised across the life of the loan rather than at once;
buy-down fees let a third
party pay down the borrower's effective rate, with the cost amortised over
the term. Both are
ordinary in asset and dealer-assisted lending. An institution that wants
either has to configure
its products outside this application.
- **Products configured elsewhere are damaged by editing here.**
`loadProductData` rebuilds the
payload field by field, so settings the form does not name are dropped on
save. This is the same
class of bug fixed for tranches and down payments in #189, and these eight
fields still have it.
## Which engine these belong to
Capitalised income is a progressive-engine capability:
`CAPITALIZED_INCOME_ADJUSTMENT` is one of
the advanced payment allocation transaction types
(`loanProductPaymentAllocationRule.ts`), which
only exist on products using the advanced payment allocation strategy.
Buy-down fee has no equivalent direct marker in the generated client — there
is no `BUY_DOWN`
entry in the allocation transaction types — but it is grouped with
capitalised income throughout
the API (adjacent on the product request, the product response and the loan
response), shares the
same `EQUAL_AMORTIZATION` strategy vocabulary, and is already treated as a
progressive capability
by the account screen. Both should therefore be offered for progressive
products only, and the
weaker evidence for buy-down fee is worth recording rather than glossing
over.
## Constraints
- Both groups belong to progressive products, and must be cleared when the
schedule type moves
back to cumulative — a flag left in the payload describes a product the
cumulative engine cannot
honour.
- The detail fields depend on their parent toggle and should be cleared with
it.
- `capitalizedIncomeCalculationType` and both `*Strategy` fields currently
admit a single value
each. They should still be explicit in the payload rather than left to a
server default, so the
product records what it was created with.
## Comprehensibility for non-specialists
"Capitalised income", "buy-down fee" and "equal amortisation" are specialist
terms. Each control
needs help text explaining the effect in business terms — what the
institution is choosing, and
what changes for the borrower — consistent with the help added in #187 and
#189.
## Acceptance criteria
- [ ] Both groups are settable, and offered for progressive products only.
- [ ] Switching a product to cumulative clears both, and turning a group off
clears its details.
- [ ] Existing values load when editing and survive a save round trip.
- [ ] A product created here with these settings makes the corresponding
account tab appear,
closing the loop from #187.
- [ ] Unit tests cover the gating and clearing; a mocked Playwright spec
asserts the submitted
payload; the recorded demo shows the settings being configured.
- [ ] Every new control carries 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]
