PRD: Multi-employee Shifts
| Module | Sale (CORE-07) | PRD ID | PRD-SHF-001 |
| Status | In-progress | Owner | Việt Võ · Phát Nguyễn |
| Date | 2026-06-11 | Version | v0.1 |
| Packages | @nx/sale · apps/sale-renderer | URD | SHF |
| Epic | BANA-1321 | Window | July 2026 |
TL;DR
A multi-staff store runs shifts properly: open/close on a device, several staff enrolled in one shift, X/Z reports, and the till reconciled at close with the discrepancy recorded. The backend already exists on develop (shift, enrolment, drawer, report - including expected/actual cash); this increment migrates the POS off the old single-user session and verifies the whole loop. This PRD also serves as the reference spec for later testing.
1. Context & Problem
Phase 1 shipped a single-user POS session. The business needs shifts shared by several staff (cashier + waiters on one till) with clean accountability. The multi-employee shift system has been built server-side; the POS front end still speaks the old session model, so none of it reaches users yet - and there was no written spec to verify against. This document closes both gaps.
2. Goals & Non-Goals
Goals - open/close on device (URD-SHF-001) · multi-enrolment (002) · X/Z (003) · cash reconcile with discrepancy (004) · per-staff attribution (005) · drawer movements (006) · revenue by shift/period (007).
Non-Goals - per-member capability flags within a shift (canRefund/canVoid - tracked separately under Permissions) · payroll/timesheets.
3. Success Metrics
| Metric | Target |
|---|---|
| POS runs the new shift system | Old single-user session fully replaced, no regression |
| Z report | expectedCash formula verified against a real day of trading |
4. Personas & Use Cases
Cashier (opens/closes, counts the till) · Waiter (enrols, sells) · Owner (reads X/Z, investigates discrepancies).
5. User Stories
- As a cashier, I open the shift with a float, my colleagues enrol, and at close I count the till and see the discrepancy immediately.
- As an owner, I read Z reports per shift and revenue per period.
6. Functional Requirements
Delivers URD SHF URD-SHF-001…007 (Musts 001-005).
7. Non-Functional Requirements
- Shift state survives app restarts; no sale can occur outside an open shift (policy-controlled).
8. UX & Flows
- Open shift (float entry) → staff enrol → sell (sales attribute to acting staff).
- Mid-shift: X report. Cash movements: pay-in/pay-out/safe-drop.
- Close: count → expected vs counted → discrepancy recorded → Z report (printable).
9. Data & Domain
- Uses the built entities: shift, shift-enrolment, shift-drawer, shift-report (expectedCash/actualCash/cashDiscrepancy). FE migration from the legacy POS session; acting-staff attribution via the existing acting-user mechanism.
10. Dependencies & Assumptions
| Dependency | Why |
|---|---|
| Acting-user middleware (BANA-1140, in flight) | Attribution of sales within a shared shift |
| Finance accounts | Cash movements post to accounts |
11. Risks & Open Questions
- Migration cutover: stores mid-shift during rollout - define upgrade path (close old session first).
- Shift policy variants (shared till vs per-device) - confirm default for v1.
12. Release Plan & Launch Criteria
July (WK27-31): FE migration + e2e verification. Launch: AC-SHF-01 passes on a pilot store; old session retired.
13. FAQ
- Is the backend being rebuilt? No - it's built; this is FE wiring + verification, and this PRD is the test reference.
References
URD SHF · Phase 2 - By Month · Epic BANA-1321