Feature Package PK-04 — Restaurant & F&B
Status: Package Specification
Domain: Restaurant / Kitchen / Procurement
Maps to: Process 1 (Shopping Lists & Approvals / Requisition-to-PO), Playbook H-4
External integration: ERPNext (finance/procurement SoR), Solver Gateway (:3070)
1. What This Package Does
Gives the F&B operation one auditable procurement and inventory system — from weekly requisition through vendor split, three-way match, and payment release — replacing email-based orders, verbal approvals, and unmatched invoices.
2. Features & Functionality
| Feature | What it does | Who uses it | What stands behind it |
|---|---|---|---|
| Requisition assembly | Build a purchase requisition with line items (produce, dairy, dry goods, amenities), quantities, cost center, urgency | Executive chef, F&B manager, steward | cns://workflow/requisition claim with line items |
| Threshold-based approval routing | Requisition is routed by declarative amount bands to the right approver(s); dual custody above tier | Finance controller, F&B manager | lookup.claims.threshold.procurement.v1 (TIER_1/2/3); fn::poce::record_step per signer |
| Vendor basket split (solver) | The solver proposes the least-cost split of the basket across approved vendors based on price, stock, and quantity | Executive chef, procurement officer | Solver Gateway procurement.basket_split@1 (branch_and_bound 1.4.0); proposes only; buyer disposes |
| Purchase order sync | Approved requisition → ERPNext purchase order (idempotent); PO number mirrored back | Procurement officer | Camel → ERPNext POST /api/resource/Purchase Order; integration_entity mirror |
| Goods receipt & three-way match | Receiving logs delivery against PO; invoice is matched to PO + receipt before payment release | Storekeeper, accounts payable | Three-way match (PO, receipt, invoice); PoCE-recorded |
| Inventory / par-level tracking | F&B stock levels tracked as resource:inventory; low-stock alerts trigger new requisitions | Steward, storekeeper | resource table; declarative par-level lookups |
| Cost-center allocation | Every line item is charged to a cost center (kitchen, bar, banquet, room service) for P&L visibility | Finance controller | cost_center on requisition claim; budget pool binding via truth_edge |
3. Workflow (Step by Step)
- Chef builds requisition (line items, quantities, cost center: kitchen)
- Threshold policy computes approval tier (e.g., TIER_2_MANAGEMENT)
- F&B manager + finance controller sign (dual custody, PoCE steps)
- Approved requisition → solver proposes vendor split (chef reviews, accepts/adjusts)
- Camel creates ERPNext PO; PO number stored in
integration_entity - Goods received; three-way match; payment released
- Stock deducted; cost center charged; PoCE receipt issued
4. Guard Rails
- No PO without a PoCE-approved requisition
- No synthetic vendor IDs; basket split proposes only, chef disposes
- ERPNext owns fiscal GL and tax; Sovereign owns approval state
- If ERPNext is unreachable →
502fail-closed; no dummy PO numbers - Solver failure →
503 invent_refuse; never a fake "optimal" split
5. Evidence & Audit
- Requisition claim, approval signatures, ERPNext PO reference, goods receipt, invoice match, PoCE receipt
- Verifiable by finance auditors offline