[I] Teller cash management: cashiers cannot receive, return or account for cash [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

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: issues-unsubscribe@fineract.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] Teller cash management: cashiers cannot receive, return or account for cash [fineract-backoffice-ui]

["Aman-Mittal (via GitHub)" <gi...@apache.org>]

Aman-Mittal closed issue #239: Teller cash management: cashiers cannot receive, return or account for cash
URL: https://github.com/apache/fineract-backoffice-ui/issues/239


-- 
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: issues-unsubscribe@fineract.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org