PRD: Stock Operations for F&B & Retail
| Module | Inventory (CORE-06) | PRD ID | PRD-IOP-001 |
| Status | Planned | Owner | Phát Nguyễn |
| Date | 2026-06-11 | Version | v0.1 (draft) |
| Packages | @nx/inventory · apps/client · apps/sale-renderer | URD | IOP |
| Epic | BANA-1323 | Window | Jul (foundation) · Aug (by industry) |
TL;DR
Merchants operate stock from the app: receive and issue with vouchers, run purchase orders, count and adjust. Then each industry gets its depth: F&B dishes auto-deduct ingredients per recipe with lot/expiry; retail scans barcodes in/out and the counter sees live stock.
1. Context & Problem
The inventory backend is unusually complete - seven ticket types, a full PO lifecycle that even posts the expense voucher on receipt, lot/expiry fields, low-stock flags (with a widget), and KIT recipes that already deduct on sale. What's missing is almost the entire user surface: no screens to create vouchers, manage POs, count stock, maintain recipes, or capture lots. Merchants own a working engine with no steering wheel.
2. Goals & Non-Goals
Goals - voucher screens for all ticket types (URD-IOP-001) · PO end-to-end from the app (002) · count & adjustment (003) · F&B recipe auto-deduct verified with recipe screens (004) · retail barcode in/out (005) · lot/expiry at receipt + expiring-soon (006) · live counter stock (007).
Non-Goals - production orders (batch cooking, batch costing) → Phase 3 · multi-level BOM · stock valuation reports (Reports, Aug).
3. Success Metrics
| Metric | Target |
|---|---|
| Purchase → receive → stock → sell | Runs end-to-end from the app on a pilot merchant |
| F&B recipe deduction | Selling a dish visibly reduces ingredient stock |
4. Personas & Use Cases
Owner/manager (runs stock weekly) · Warehouse staff (receives, counts) · Cashier (sees availability).
5. User Stories
- As an owner, I create a PO to my vendor, receive it, and stock + an expense voucher appear without me typing twice.
- As an F&B owner, I define a recipe once; every sale deducts ingredients.
- As a retail clerk, I scan items in and out of stock.
6. Functional Requirements
Delivers URD IOP URD-IOP-001…008 (Musts 001-005). Existing areas TKT/VEN/PO/REC provide the backend.
7. Non-Functional Requirements
- Counter stock view must not slow the sale flow; screens reuse the shared low-stock/attention fragments (DRY rule).
8. UX & Flows
- Vouchers (Jul): create/list per type; receipts feed stock instantly.
- POs (Jul): create → send → receive (with lot/expiry input) → done.
- Counts (Jul): count sheet → variances → adjustment ticket.
- F&B (Aug): recipe screens; deduct-on-sale verified e2e.
- Retail (Aug): scan-driven in/out; counter availability live.
9. Data & Domain
- No new core entities expected - InventoryTicket, Vendor/PO, InventoryStock (lot/expiry), InventoryIdentifier, MaterialRecipe all exist; the increment is screens + wiring + e2e verification (incl. the known CDC gaps on updates).
10. Dependencies & Assumptions
| Dependency | Why |
|---|---|
| Barcode per variant (Products, Jul) | Retail scan flows |
| Retail mode (PRD-RTL-001) | Counter context for live stock |
| Design (Jul) | Volume of screens makes design the critical path |
11. Risks & Open Questions
- Largest FE surface of Phase 2 - slice strictly in the Jul/Aug order above.
- Real-time counter stock depends on closing known CDC gaps (updates not captured).
12. Release Plan & Launch Criteria
Jul: foundation slices. Aug: industry slices. Launch: AC-IOP-01 passes on a pilot F&B and a pilot retail merchant.
13. FAQ
- Do we build production orders? No - Phase 3. Recipes auto-deduct is the Phase-2 depth.
References
URD IOP · Phase 2 - By Month · Epic BANA-1323