Standalone H3.5: customers should spot their order at a glance when staff yells the number.
The full id stays on the receipt (e.g. POS-06-0003); we add the sequence tail
(0003) as a big/bold/centered block right under the store header.
tsc --noEmit clean. Three files
touched, no migration, no new dep. Component-render probe verifies the block toggles on
presence of sequenceTail and that the existing
Order: POS-06-0003 line is preserved.
The big block sits between the store header and the first divider. When the receipt is
built from a historical fetched order whose API response shape predates this slice (no
sequenceNo), the block silently doesn't render — old reprints look identical.
/cafe/api/cafe/orders already returned sequenceNo in the response — so the post-order success modal builds with the new block out of the box./cafe/api/cafe/orders/[orderId] was the gap. Now also exposes sequenceNo so the orders-list reprint flow gets the new block too.NativeOrderForReceipt gains sequenceNo?: number | null (optional for back-compat).buildNativeReceipt derives sequenceTail using the same padding rule as formatPosOrderNumber: 4-digit zero-pad up to 9999, raw integer beyond. Null/0/missing → null → block doesn't render.ReceiptData.sequenceTail drives the new block in khmer-receipt.tsx. The component stays presentation-only; padding logic lives in the builder.ReceiptData.sequenceTail?: string | null field presentOrder: POS-... small line preserved unchangedNativeOrderForReceipt.sequenceNo + buildNativeReceipt pad-rule (4-digit ≤9999, raw beyond, null on 0/missing)/cafe/api/cafe/orders/[orderId] exposes sequenceNoRaw: 01-probe.json · result.json
components/receipt/khmer-receipt.tsx · lib/native-receipt.ts ·
app/api/cafe/orders/[orderId]/route.ts