Test Cases: Orders

Module	CORE-07	URD	Orders URD

Cases are aligned to URD v0.3 functional areas and verified against the Sale Service developer docs. QE findings note behavior confirmed in the codebase that the URD does not spell out.

1. Coverage Summary

Area	URD reqs	Test cases	Covered
Sale Order (ORD)	16	18	✅
Check Splitting (CHK)	5	4	✅
Kitchen Tickets (KIT)	9	8	✅
Kitchen Stations (STA)	3	3	✅
POS Sessions (POS)	8	6	✅
Reservations (RSV)	5	4	✅
Loyalty Points (PNT)	3	3	✅

2. Test Cases

TC-<AREA>-NNN lines up with URD-<AREA>-NNN. Priority = P1 (critical) / P2 (major) / P3 (minor).

2.1 Sale Order

TC ID	URD ref	Scenario	Steps	Expected	P
TC-ORD-001	URD-ORD-001	Create draft order	1. Cashier authenticated for a merchant 2. Create order	Order created with status DRAFT, scoped to merchant and device	P1
TC-ORD-002	URD-ORD-002	Add product to draft	1. DRAFT order 2. Add a product	Line item added; price captured at add-time; quantity defaults to 1	P1
TC-ORD-003	URD-ORD-002	Edit blocked outside DRAFT	1. PROCESSING order 2. Try to add an item	Rejected — items editable only in DRAFT	P1
TC-ORD-004	URD-ORD-003	Same product merges quantity	1. DRAFT order with Product A (qty 1) 2. Add Product A again	Existing line quantity increases (no duplicate line)	P2
TC-ORD-005	URD-ORD-004	Quantity zero removes line	1. DRAFT order with item (qty 1) 2. Update quantity to 0	Line is removed (soft-deleted); total recalculates	P2
TC-ORD-006	URD-ORD-005	Combo fans out	1. DRAFT order 2. Add a combo product	One lead line + zero-priced child lines created in one transaction	P1
TC-ORD-007	URD-ORD-005	Combo re-add rejected	1. Combo already in order 2. Add the same combo	Rejected — use edit to change quantity	P2
TC-ORD-008	URD-ORD-006	Checkout locks price	1. Product added at 50,000 2. Catalog price changes to 60,000 3. Checkout	Total uses locked 50,000, not the new catalog price	P1
TC-ORD-009	URD-ORD-006	Checkout transition	1. DRAFT order with ≥1 item 2. Checkout	Status DRAFT → PROCESSING; totals calculated	P1
TC-ORD-010	URD-ORD-007	Empty cart rejected	1. DRAFT order with no items 2. Checkout	Rejected — at least one item required	P1
TC-ORD-011	URD-ORD-007	Negative quantity rejected	1. DRAFT order 2. Set an item quantity to -1 on add	Rejected — quantity must be ≥ 1	P1
TC-ORD-012	URD-ORD-008	Revert to cart	1. PROCESSING order 2. Revert	Status PROCESSING → DRAFT; items editable again	P1
TC-ORD-013	URD-ORD-009	Cancel non-terminal	1. Order in DRAFT / PROCESSING / PARTIAL 2. Cancel	Status → CANCELLED; reason recorded when given	P1
TC-ORD-014	URD-ORD-009	Cancel terminal rejected	1. COMPLETED or CANCELLED order 2. Cancel	Rejected — terminal status	P1
TC-ORD-015	URD-ORD-010	Partial payment	1. PROCESSING order 2. Payment success for less than total	Status → PARTIAL	P1
TC-ORD-016	URD-ORD-011	Full payment completes	1. PROCESSING order 2. Payment success ≥ total	Status → COMPLETED	P1
TC-ORD-017	URD-ORD-014	Attach customer	1. Order 2. Attach a customer	Customer linked; visible on order detail	P2
TC-ORD-018	URD-ORD-016	Max items boundary	1. DRAFT order with 100 items 2. Add the 101st	Rejected — max-items limit reached	P2

QE finding — quantity-zero delete

Source sale-order-item.service.ts: updating a line to quantity ≤ 0 soft-deletes it rather than raising a validation error. TC-ORD-005 validates this convention; the URD does not spell it out.

QE finding — checkout has no item lock

Source checkout.service.ts: checkout reads items then calls pricing with no pessimistic lock across the two steps, so a concurrent item edit during checkout is a potential race. TC-ORD-008 / TC-ORD-009 assume no concurrent edit.

QE finding — max items = 100

Source sale.service.ts: addSaleOrderItem enforces MAX_NUMBER_OF_ITEMS_IN_ORDER = 100 with pessimistic locking. TC-ORD-018 validates the boundary.

2.2 Check Splitting

TC ID	URD ref	Scenario	Steps	Expected	P
TC-CHK-001	URD-CHK-001	Split into checks	1. Order 2. Split into multiple checks	Multiple sale checks created under the order	P2
TC-CHK-002	URD-CHK-002	Allocate items to check	1. Split order 2. Assign items / quantities to a check	Each check holds its allocated items and total	P2
TC-CHK-003	URD-CHK-004	Order completes via checks	1. All checks on an order completed	Order status → COMPLETED	P2
TC-CHK-004	URD-CHK-005	Roll back split	1. Split order, no check paid 2. Roll back	Checks removed; order returns to a single bill	P3

2.3 Kitchen Tickets

TC ID	URD ref	Scenario	Steps	Expected	P
TC-KIT-001	URD-KIT-001	Send to kitchen	1. Order with items 2. Send to kitchen	Ticket + ticket items created	P1
TC-KIT-002	URD-KIT-002	Idempotent send	1. Send with an idempotency key 2. Retry with same key	No duplicate ticket created	P1
TC-KIT-003	URD-KIT-003	Ticket lifecycle	1. New ticket 2. Progress items	Ticket moves PENDING → PROCESSING → READY → COMPLETED	P1
TC-KIT-004	URD-KIT-004	Item lifecycle	1. Ticket item 2. Start cooking → ready → served	Item moves PENDING → COOKING → READY → SERVED	P1
TC-KIT-005	URD-KIT-005	Auto-progression	1. Mark all items READY	Ticket auto-progresses to READY without manual ticket update	P1
TC-KIT-006	URD-KIT-006	Void and resend	1. Sent ticket item 2. Need a quantity change	In-place edit not allowed; void old + send new	P2
TC-KIT-007	URD-KIT-008	Real-time update	1. KDS connected 2. Item status changes	KDS and dashboard receive the live update	P1
TC-KIT-008	URD-KIT-009	Served triggers consume	1. Kitchen item marked served	Stock consumption is triggered for that item	P2

QE finding — real-time events are fire-and-forget

Source checkout.service.ts, payment-webhook.service.ts: WebSocket broadcasts are not awaited. A broadcast failure is logged but does not roll back the order operation. TC-KIT-007 covers delivery, not delivery guarantee.

2.4 Kitchen Stations

TC ID	URD ref	Scenario	Steps	Expected	P
TC-STA-001	URD-STA-001	Create station	1. Manager 2. Create a named station (i18n)	Station created and scoped to merchant	P2
TC-STA-002	URD-STA-002	Category routing	1. Map a product category to a station 2. Send those items	Their tickets route to the mapped station	P2
TC-STA-003	URD-STA-003	Station printer config	1. Configure a station printer with auto-print	New tickets at that station auto-print	P3

2.5 POS Sessions

TC ID	URD ref	Scenario	Steps	Expected	P
TC-POS-001	URD-POS-001	Open session	1. No open session on device 2. Open with float	Session created OPEN with opening float	P1
TC-POS-002	URD-POS-002	One session per device	1. Open session on device 2. Open another on same device	Rejected — one open session per device	P1
TC-POS-003	URD-POS-003	Close & reconcile	1. Open session 2. Close with counted cash	Discrepancy = actual − expected recorded	P1
TC-POS-004	URD-POS-004	Z report once	1. Close session	Exactly one Z report (PosSessionReport) generated	P1
TC-POS-005	URD-POS-006	Order attaches to session	1. Open session 2. Create an order on the device	Order linked to the open session	P2
TC-POS-006	URD-POS-008	Recount on close	1. Close, then re-close with a corrected count	Recount tracked; final figures updated	P3

2.6 Reservations

TC ID	URD ref	Scenario	Steps	Expected	P
TC-RSV-001	URD-RSV-001	Create reservation	1. Host 2. Create with guest name, phone, party size, time	Reservation PENDING; table held (allocation active)	P2
TC-RSV-002	URD-RSV-002	Confirm then check in	1. Confirm reservation 2. Check in	PENDING → CONFIRMED → CHECKED_IN	P2
TC-RSV-003	URD-RSV-005	Check-in spawns order	1. Confirmed reservation 2. Check in	Sale order spawned and linked; allocation re-targeted	P2
TC-RSV-004	URD-RSV-002	Cancel reservation	1. PENDING or CONFIRMED reservation 2. Cancel	Status → CANCELLED; held tables released	P2

2.7 Loyalty Points

TC ID	URD ref	Scenario	Steps	Expected	P
TC-PNT-001	URD-PNT-001	Earn on completion	1. Order with a linked customer 2. Payment succeeds	Points awarded for the completed order	P2
TC-PNT-002	URD-PNT-002	Idempotent award	1. Duplicate payment-success event for same order	Points awarded once only	P2
TC-PNT-003	URD-PNT-003	Balance per merchant	1. Customer earns across orders	Balance accumulates per customer per merchant	P3

3. Traceability

Every Must requirement maps to ≥1 test case. Gaps are flagged.

URD requirement	Test case(s)	Status
URD-ORD-001	TC-ORD-001	✅ Covered
URD-ORD-002	TC-ORD-002, TC-ORD-003	✅ Covered
URD-ORD-003	TC-ORD-004	✅ Covered
URD-ORD-004	TC-ORD-005	✅ Covered
URD-ORD-005	TC-ORD-006, TC-ORD-007	✅ Covered
URD-ORD-006	TC-ORD-008, TC-ORD-009	✅ Covered
URD-ORD-007	TC-ORD-010, TC-ORD-011	✅ Covered
URD-ORD-008	TC-ORD-012	✅ Covered
URD-ORD-009	TC-ORD-013, TC-ORD-014	✅ Covered
URD-ORD-010	TC-ORD-015	✅ Covered
URD-ORD-011	TC-ORD-016	✅ Covered
URD-ORD-012	—	⚠️ Uncovered (Should — order split)
URD-ORD-013	—	⚠️ Uncovered (Should — order merge)
URD-ORD-014	TC-ORD-017	✅ Covered
URD-ORD-015	—	⚠️ Uncovered (Should — multi-currency)
URD-ORD-016	TC-ORD-018	✅ Covered
URD-CHK-001	TC-CHK-001	✅ Covered
URD-CHK-002	TC-CHK-002	✅ Covered
URD-CHK-003	—	⚠️ Uncovered (Should — per-check customer)
URD-CHK-004	TC-CHK-003	✅ Covered
URD-CHK-005	TC-CHK-004	✅ Covered
URD-KIT-001	TC-KIT-001	✅ Covered
URD-KIT-002	TC-KIT-002	✅ Covered
URD-KIT-003	TC-KIT-003	✅ Covered
URD-KIT-004	TC-KIT-004	✅ Covered
URD-KIT-005	TC-KIT-005	✅ Covered
URD-KIT-006	TC-KIT-006	✅ Covered
URD-KIT-007	—	⚠️ Uncovered (Should — rush / sequence)
URD-KIT-008	TC-KIT-007	✅ Covered
URD-KIT-009	TC-KIT-008	✅ Covered
URD-STA-001	TC-STA-001	✅ Covered
URD-STA-002	TC-STA-002	✅ Covered
URD-STA-003	TC-STA-003	✅ Covered
URD-POS-001	TC-POS-001	✅ Covered
URD-POS-002	TC-POS-002	✅ Covered
URD-POS-003	TC-POS-003	✅ Covered
URD-POS-004	TC-POS-004	✅ Covered
URD-POS-005	—	⚠️ Uncovered (Should — X report)
URD-POS-006	TC-POS-005	✅ Covered
URD-POS-007	—	⚠️ Uncovered (Should — non-cash expected vs actual)
URD-POS-008	TC-POS-006	✅ Covered
URD-RSV-001	TC-RSV-001	✅ Covered
URD-RSV-002	TC-RSV-002, TC-RSV-004	✅ Covered
URD-RSV-003	—	⚠️ Uncovered (Should — source tracking)
URD-RSV-004	—	⚠️ Uncovered (Should — occasion tagging)
URD-RSV-005	TC-RSV-003	✅ Covered
URD-PNT-001	TC-PNT-001	✅ Covered
URD-PNT-002	TC-PNT-002	✅ Covered
URD-PNT-003	TC-PNT-003	✅ Covered

All Must requirements are covered. Uncovered items are Should-priority enhancements pending test authoring.