Aman-Mittal opened a new issue, #198:
URL: https://github.com/apache/fineract-backoffice-ui/issues/198
Part of the savings account servicing work.
## Summary
The savings account screen offers approve, activate and close. None of the
day-to-day servicing
commands Fineract exposes are available, so an officer has to leave this
application to do any of
them.
This slice covers the account-level commands whose contracts are verified:
| Command | What it does |
|---|---|
| `calculateInterest` | Works out interest earned to date without posting it
|
| `postInterest` | Posts the accrued interest to the account |
| `block` / `unblock` | Freezes the account entirely, e.g. on a fraud hold |
| `blockDebit` / `unblockDebit` | Stops withdrawals while deposits continue |
| `blockCredit` / `unblockCredit` | Stops deposits while withdrawals
continue |
| `applyAnnualFees` | Charges the product's annual fee |
## Business value
- **Interest cannot be posted from here.** Interest posting is a routine,
scheduled operation on
every savings book. Not having it means the one screen an officer uses for
an account cannot
perform its most ordinary task.
- **An account cannot be frozen.** When fraud is suspected, or a court order
lands, the immediate
need is to stop movement on the account. Fineract supports three
granularities — all activity,
withdrawals only, deposits only — and none is reachable. The workaround is
a database or
API-level intervention, which leaves no trace in the screens anyone else
looks at.
- **The three block types are genuinely different decisions.** Blocking
credits stops money coming
in while letting the customer draw down; blocking debits does the reverse.
Collapsing them, or
offering only a blunt full block, would misrepresent what the institution
can do.
- **Annual fees cannot be charged**, so a product configured with one cannot
actually collect it.
## Verified contracts
Probed against a running Fineract on an active account, rather than inferred
— the generated
client documents none of it:
- All of the above are accepted on `POST /savingsaccounts/{id}?command=…`.
- `block`, `blockDebit` and `blockCredit` require `reasonForBlock`.
- `unblockDebit` fails with *"debits.are.not.blocked"* when debits are not
blocked, so each
reversal must be offered only in the state that permits it — the same
offer-only-what-is-legal rule applied to the loan servicing commands.
- `holdAmount` is **not** on this endpoint. It lives on
`POST /savingsaccounts/{id}/transactions` and rejects a parameter named
`amount`, so it is not
in this slice.
## Comprehensibility for non-specialists
"Block debit" and "block credit" read as jargon and are easy to get
backwards — the consequence of
picking the wrong one is either a customer who cannot access their money or
one who can drain an
account under investigation. The labels should say what happens in plain
terms, and the help
should name who is affected.
## Acceptance criteria
- [ ] All the commands above are available on an active account, each gated
on the state that
makes it legal.
- [ ] A blocked account shows that it is blocked, and which kind of block is
in force.
- [ ] Reversals are offered only when the corresponding block is actually in
place.
- [ ] Unit tests cover the gating; a mocked spec covers the menu; a
**backend** test exercises the
real commands.
- [ ] Labels and help distinguish the three block types without jargon.
--
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]
