Aman-Mittal opened a new pull request, #191:
URL: https://github.com/apache/fineract-backoffice-ui/pull/191
Closes #190.
Adds an **Income Recognition** section covering `enableIncomeCapitalization`
and
`enableBuyDownFee`, each with its income type, calculation type and
amortisation strategy.
### 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 own capability flags — correctly, since a tab that can never hold
anything is worse than no
tab. But nothing in this application could set those flags, so the tabs
could only ever appear for
products created elsewhere. The gating worked and the feature behind it was
unreachable. It isn't
any more.
### Which engine these belong to, and how confident that is
Both are offered for progressive products only, and cleared when the
schedule type moves back to
cumulative. The evidence differs between the two, and I'd rather record that
than smooth it over:
- **Capitalised income** has a direct marker:
`CAPITALIZED_INCOME_ADJUSTMENT` is one of the
advanced payment allocation transaction types, which exist only on
products using that strategy.
- **Buy-down fee** has no equivalent — there is no `BUY_DOWN` entry anywhere
in the allocation
types. It is grouped with capitalised income throughout the API (adjacent
on the product
request, product response and loan response), shares the same
`EQUAL_AMORTIZATION` vocabulary,
and is already treated as a progressive capability by the account screen.
Consistent, but
inferred rather than stated.
### Details worth noting
The detail fields are **seeded on enable** rather than left to a server
default, so the product
records what it was created with. Two of the three enums currently admit a
single value; they are
still rendered as selects driven by one option list each, so a value added
upstream needs a line
rather than a new control.
All eight fields are also carried through `loadProductData`, which rebuilds
the payload field by
field — the same silent data-loss bug fixed for tranches and down payments
in #189, which these
fields still had. The response wraps them as `{ code, value }` while the
request takes the bare
code, and the round-trip test covers that unwrapping.
### Comprehensibility
Each control explains the effect in business terms. For example:
> **Spread income over the life of the loan** — Recognise income gradually
over the loan's term
> instead of all at once when it is charged. The borrower pays the same
either way — this changes
> when the institution books the income.
Labels avoid jargon where plain words work: *Income being spread*, *How the
amount is worked out*,
*How it is spread*, *Allow a third party to buy down the rate*.
### Verification
| Check | Result |
|---|---|
| Unit tests | **720 passing** (715 → 720) |
| Mocked Playwright | **204/204 passing** (200 → 204) |
| `tsc` (app + spec) | 0 errors |
| `npm run build` | passes |
| lint (empty suppressions baseline), format, i18n, icons, license | all
clean |
I drove the form by hand against mocks before committing. One thing that
looked wrong in the
screenshot — the buy-down checkbox appearing unchecked while its detail
fields were showing —
turned out to be the checkbox caught mid-animation; I checked the actual
`checked` property rather
than trusting the pixels, and both read `true`.
### Not in this PR
The demo steps run only in the `backend` project, which needs a live
Fineract, so they are
unverified here; their assertions mirror the mocked spec that does run.
Interest recalculation is still a hardcoded `false` with no control, and
`chargeOffBehaviour`,
`enableAccrualActivityPosting`, `fixedLength` and `repaymentStartDateType`
remain unexposed — the
remaining step of this phase.
The run surfaced pre-existing `NG0100` reports on this form (`ng-untouched`,
and an
`undefined → 10` on the interest rate field). These are the form-state class
described earlier,
not introduced here — the reported value belongs to an existing field, and
the check is advisory
rather than enforced.
--
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]
