Aman-Mittal opened a new issue, #239:
URL: https://github.com/apache/fineract-backoffice-ui/issues/239
## Summary
Teller cash management stops at appointing a cashier. A user can create a
teller and allocate a cashier to it, but there is no way to give that cashier
cash, take it back, or see what they hold. The module therefore lets an
operator create cashiers who can never hold or return money, which is the
entire purpose of the role.
Four operations on the generated client have no caller:
| Operation | Missing capability |
|---|---|
| `postTellersTellerIdCashiersCashierIdAllocate` | Allocate cash from the
vault to a cashier |
| `postTellersTellerIdCashiersCashierIdSettle` | Settle cash from a cashier
back to the vault |
| `getTellersTellerIdCashiersCashierIdTransactionsTemplate` | Currencies the
cashier may transact in |
| `getTellersTellerIdCashiersCashierIdSummaryandtransactions` | Running
position and transaction history |
## Defects found while implementing this
Three of these are only visible against a running platform, and two are
silent — they produce a confidently wrong screen rather than an error.
### 1. The cashiers list is always empty
`CashiersListComponent` reads the top-level `/cashiers` collection. That
endpoint answers **`204 No Content`** for every combination of `officeId` and
`tellerId`, so the list renders empty however many cashiers have been allocated.
This survived because an empty list is indistinguishable from a teller that
genuinely has no cashiers. The correct source is `GET
/tellers/{tellerId}/cashiers`, which returns an object describing the teller
with a `cashiers` array inside it rather than a bare array.
Related to #223 in symptom — an empty-looking list that is not empty — but a
different root cause: this is the wrong endpoint rather than an unreported load
failure.
### 2. The cashier summary silently reports zeros without a currency
`GET /tellers/{id}/cashiers/{id}/summaryandtransactions` accepts the request
without a `currencyCode` and answers `200` with every total set to `0` and an
empty transaction list. A cashier holding cash is indistinguishable from one
that never transacted. The currency has to come from the transactions template,
which scopes it to the teller's office.
### 3. Allocation requires accounting configuration that the error does not
name
Allocation fails with `404` — *"Financial Activity account with for the
financial Activity with Id 101 does not exist"* — until **Cash at Main Vault
(101)** and **Cash at Teller (102)** are both mapped to GL accounts. The
message names an activity id and never mentions tellers or cashiers, so the
prerequisite reads as a bug in the allocation itself.
## Platform behaviour worth reporting upstream
`summaryandtransactions` reports a settlement **inconsistently**. The same
sequence — allocate then settle, same cashier, same amounts — sometimes returns
`sumCashSettlement: 1200` with both rows and sometimes `0` with the allocation
alone. It is not the transaction date, the cashier's date range, or the
balance: the settlement is created either way and `POST .../settle` answers
`200` with a `subResourceId` every time.
The same endpoint also returns data for a cashier id paired with the
**wrong** teller id in the path, which suggests it keys on the cashier alone
and ignores the teller.
Any test should assert the settlement on its response rather than on the
rendered total, or it will fail intermittently for behaviour the UI does not
control.
## Constraints discovered by testing against a real backend
- A staff member cannot be a cashier in overlapping date ranges **on any
teller**, not just the one being edited. Any repeatable test must create its
own staff member per run.
- A cashier's date range must fall inside the teller's date range.
- Dates must be zero-padded to match the declared `dd MMMM yyyy`. An
unpadded day fails to parse and returns `500` rather than a validation message.
## Business Value
Cash management is the control that makes a branch's physical cash
auditable. Without allocation and settlement, a cashier's drawer is tracked
nowhere in the system: there is no record of what was issued from the vault,
what came back, or what remains outstanding at close of day. Branches running
on this application must reconcile cash outside it — on paper or in a
spreadsheet — which removes the audit trail the platform exists to provide and
leaves shortfalls undetectable until a manual count finds them.
The empty cashiers list compounds it. An operator who allocates a cashier
sees no confirmation that it worked, so the natural response is to allocate
again, producing duplicates that the platform then rejects for overlapping date
ranges — an error that gives no hint the first allocation succeeded.
Making the cashier's position visible also closes the loop for supervisors:
net cash held per cashier is what a branch manager checks before authorising a
further allocation.
## Scope
Self-contained. Touches only `src/app/features/tellers/cashiers/` plus its
routes and translation keys, so it does not block or conflict with work in
other features.
## Suggested approach
- A shared allocate/settle form addressed as `.../transactions/allocate` and
`.../transactions/settle`, so each command keeps its own URL.
- A transactions view showing total allocated, total settled and net cash
above the entries that produced them, reading the transactions template first
so the summary can be requested for a currency the cashier can actually hold.
- End-to-end coverage against a real Fineract that drives the accounting
setup through the UI as well, since that setup is part of what an operator must
do for the feature to work at all.
--
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]
