Aman-Mittal opened a new issue, #197:
URL: https://github.com/apache/fineract-backoffice-ui/issues/197
Tracking issue for savings account servicing, which is now the largest
functional gap in the
application.
## The gap
The savings account screen supports three commands — approve, activate and
close. Fineract exposes
roughly twenty. Everything else an officer needs to do to a savings account
has to be done outside
this application:
| Missing | Effect |
|---|---|
| `calculateInterest`, `postInterest` | Interest cannot be calculated or
posted from here at all |
| `block` / `unblock` | An account cannot be frozen, e.g. on a fraud hold |
| `blockDebit` / `unblockDebit` | Withdrawals cannot be stopped while
leaving deposits open |
| `blockCredit` / `unblockCredit` | The reverse — deposits stopped,
withdrawals allowed |
| `applyAnnualFees` | Annual fees cannot be charged |
| `assignSavingsOfficer` | No officer can be assigned or changed |
| `reject`, `withdrawnByApplicant` | A pending application can only be
approved, never declined |
| `holdAmount` / `releaseAmount` | Funds cannot be earmarked against a claim
|
| GSIM (group savings) | Absent entirely — no group savings account can be
managed |
This mirrors the loan servicing gap closed by the loan-servicing work, and
the same approach
applies: probe each contract against a running Fineract, gate each action on
the state that makes
it legal, and cover it at unit, mocked and backend level.
## Verified so far
Probed against a running Fineract on an active account. All of these are
accepted on
`POST /savingsaccounts/{id}?command=`:
`calculateInterest`, `postInterest`, `block`, `unblock`, `blockDebit`,
`unblockDebit`,
`blockCredit`, `unblockCredit`, `applyAnnualFees`, `assignSavingsOfficer`.
Notes that matter for the implementation:
- `block`, `blockDebit` and `blockCredit` require `reasonForBlock`.
- `unblockDebit` fails with *"debits.are.not.blocked"* when debits are not
blocked, so the
reversals must be offered only in the state that permits them.
- `holdAmount` is **not** on the account endpoint — it lives on
`POST /savingsaccounts/{id}/transactions` and rejects a parameter named
`amount`.
- `deposit` and `withdrawal` require `paymentTypeId`; the existing
transaction form already sends
it.
## Sub-issues
Broken out below as each is implemented.
--
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]
