rikrdo/mercadodevida
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(F-188): completed feature

Browse Source
This commit is contained in:
chattie
2026-08-22 22:44:37 +02:00
parent c5e5b4c48c
commit 0e3c488c85
21 changed files with 1081 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
work/current.md
View File

@@ -1,31 +1,30 @@
# F-187 — Admin can deactivate and delete POS cashiers
# F-188 — POS pending payment orders and completion states
Allow administrators to safely remove cashier access without breaking historical POS attribution.
Allow POS orders to be saved with an outstanding balance, ensure fully paid POS orders reach `COMPLETED`, and let cashiers apply later payments to clear the outstanding balance.
## Scope
- Add an explicit active/deactivated/deleted lifecycle for backoffice POS cashier accounts.
- Show POS cashiers and their status in the TPV administration page.
- Let admins create cashiers, deactivate/reactivate them, and delete them with explicit confirmation.
- Treat delete as an irreversible soft deletion: preserve the backoffice user row and its ID so sessions, sales, receipts, reporting and audit history keep their cashier attribution.
- Revoke every live backoffice session when a cashier is deactivated or deleted.
- Reject login and existing-session authentication for inactive or deleted accounts.
- Reject deactivation/deletion while the cashier owns an open cash session; require the cash session to be closed first.
- Keep all lifecycle mutations admin-only and cashier-role-only.
- Backend `validatePaymentAllocations` accepts partial allocations (sum < total) without throwing `POS_PAYMENT_TOTAL_MISMATCH`. Overpayment remains rejected.
- `POST /pos/sales` persists orders with `state='PENDING'` when allocated total < order total, and `state='COMPLETED'` when allocations cover the order total.
- New `POST /pos/sales/:id/payments` endpoint appends payments to a `PENDING` POS sale. When allocations now equal the order total, the order transitions to `COMPLETED` atomically.
- Stock, reporting lines, payment lines and expected cash balance are updated by every payment, including rest-payment installments.
- Sale list exposes `state`, `paidCents` and `outstandingCents`. Cashier can fetch `PENDING` POS sales for the current session.
- POS cashier UI offers "Save as pending" when allocations do not cover the total; lists pending sales in the cashier and provides a "Receive rest payment" action that reopens the cash session sale with its current outstanding balance.
- Audit log records partial creation and pending fulfillment transitions.
- `bounded shipments` and refunds remain out of scope (F-189).
## Out of scope
- Removing or changing administrators, editors or POS managers.
- Reassigning historical sales or cash sessions to another cashier.
- Forcing or automating cash-session closure.
- Bulk cashier operations.
- Refunds, partial refunds and return tickets (F-189).
- Daily close reconciliation on top of pending balances (F-191).
- Customer credit, deposit or deposit-paper workflows.
## Acceptance
1. Admin TPV lists POS cashiers with active, inactive or deleted status.
2. Admin can create a cashier and the account is active by default.
3. Admin can deactivate an active cashier and reactivate an inactive non-deleted cashier.
4. Deactivation immediately revokes existing sessions and blocks future login/authentication.
5. Admin can delete a cashier only after explicit confirmation; deleted cashiers cannot be reactivated or authenticate.
6. Deactivation or deletion is rejected while the cashier has an open cash session.
7. Deletion preserves the cashier row/ID and all historical session, sale, receipt and reporting attribution.
8. Non-admin users cannot list or mutate cashier lifecycle, and non-cashier roles cannot be targeted.
9. Migration is reversible and existing backoffice accounts remain active.
10. Tests, typecheck, affected builds and `verify.sh` are green.
1. Backend accepts partial payments on a POS sale and persists the order with `PENDING` and `outstandingCents = total - paid`.
2. Backend still marks fully paid POS orders as `COMPLETED` and rejects overpayment.
3. Pending POS sales appear in the cashier's session list with the outstanding balance.
4. Cashier can apply a follow-up payment to a `PENDING` sale; reaching the total transitions it to `COMPLETED` atomically.
5. Stock is reserved on POS sale creation (not on full payment) and reporting captures every partial payment.
6. Replaying the same idempotency key keeps the original order, its state and its payments intact.
7. Non-admin/non-POS users cannot create or modify pending POS sales.
8. Migration is reversible (or no migration is needed) and existing fully paid sales stay `COMPLETED`.
9. Tests, typecheck, affected builds and `verify.sh` are green.