Aman-Mittal opened a new issue, #218:
URL: https://github.com/apache/fineract-backoffice-ui/issues/218
Part of the savings account servicing work.
## Summary
Three more groups of savings commands have no UI. Each contract below was
probed against a running
Fineract, not inferred from the generated client.
| Command | Endpoint | Verified body |
|---|---|---|
| `assignSavingsOfficer` | `POST /savingsaccounts/{id}` |
`toSavingsOfficerId`, `assignmentDate` |
| `unassignSavingsOfficer` | `POST /savingsaccounts/{id}` | `unassignedDate`
|
| `reject` | `POST /savingsaccounts/{id}` | `rejectedOnDate` |
| `withdrawnByApplicant` | `POST /savingsaccounts/{id}` | `withdrawnOnDate` |
| `holdAmount` | `POST /savingsaccounts/{id}/transactions` |
`transactionAmount`, `reasonForBlock` |
| `releaseAmount` | `POST /savingsaccounts/{id}/transactions/{txnId}` |
empty body |
## Business value
**An application can be approved but never declined.** A pending savings
application has exactly
one outcome available in this application: approval. If the applicant fails
KYC, withdraws, or the
institution declines, there is no way to record it — the account sits
pending indefinitely, or
someone resolves it outside the system and the screens stop reflecting
reality. `reject` and
`withdrawnByApplicant` are different outcomes with different reporting
treatment, and neither is
reachable.
**No account can be assigned to an officer.** Field officer assignment is
how savings portfolios
are divided, how collections are routed, and how performance is attributed.
Without it, every
account created here is unassigned, and reassignment when staff change has
to happen elsewhere.
**Funds cannot be held against a claim.** A hold earmarks part of the
balance — against a
court order, a disputed transaction, a pending outward payment — so it
cannot be withdrawn while
the rest of the account keeps working. The alternative available today is
freezing the entire
account, which stops the customer using money that was never in dispute.
That is a materially
worse outcome for the customer and a blunter instrument than the institution
actually has.
## Two contract details that matter
- **`holdAmount` takes `transactionAmount`, not `amount`.** Sending `amount`
is rejected outright
with *"The parameter amount is not supported"*. It also lives on the
transactions endpoint, not
the account endpoint.
- **`releaseAmount` targets the hold's own transaction id** —
`/transactions/{txnId}` — and takes
an empty body. It is not a command on the account.
Both are the kind of thing a mocked test cannot catch, since it asserts what
the UI sends rather
than whether Fineract accepts it.
## Comprehensibility for non-specialists
"Hold amount" and "block account" sound similar and are not: a hold
ring-fences part of the
balance, a block stops the whole account. The labels and help should make
the difference obvious,
because reaching for the wrong one either over-restricts a customer or fails
to secure the funds
actually in dispute.
## Acceptance criteria
- [ ] An officer can be assigned to and unassigned from an account.
- [ ] A pending application can be rejected or recorded as withdrawn by the
applicant.
- [ ] Part of a balance can be held with a reason, and a specific hold
released.
- [ ] Each action appears only in the state that permits it.
- [ ] Held funds are visible on the account, so nobody wonders where the
balance went.
- [ ] Unit tests cover the gating; a mocked spec covers the flows.
--
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]
