pos-restaurant-ui-standard

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Platform Notes

平台说明

Optional helper plugins may help in some environments, but they must not be treated as required for this skill.

可选辅助插件在部分环境中可能有用，但不得将其视为使用本技能的必需条件。

Restaurant POS UI Standard

餐厅POS UI标准

Use When

适用场景

Standard Restaurant POS UI derived from the Restaurant POS redesign plan. Use for any restaurant POS screen to enforce the approved layout, components, accessibility, and speed workflow.
The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.

基于餐厅POS重设计方案制定的标准餐厅POS UI。适用于所有餐厅POS屏幕，以确保遵循已批准的布局、组件、无障碍设计和高效工作流程。
任务需要可复用的判断逻辑、领域约束或经过验证的工作流程，而非临时建议。

Do Not Use When

不适用场景

The task is unrelated to
```
pos-restaurant-ui-standard
```
or would be better handled by a more specific companion skill.
The request only needs a trivial answer and none of this skill's constraints or references materially help.

任务与
```
pos-restaurant-ui-standard
```
无关，或更适合由更专业的配套技能处理。
请求仅需要简单答案，本技能的约束条件或参考资料均无法提供实质性帮助。

Required Inputs

必需输入

Gather relevant project context, constraints, and the concrete problem to solve; load
```
references
```
only as needed.
Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.

收集相关项目背景、约束条件以及具体要解决的问题；仅在需要时加载
```
references
```
。
确认期望的交付成果：设计、代码、评审、迁移计划、审计或文档。

Workflow

工作流程

Read this
```
SKILL.md
```
first, then load only the referenced deep-dive files that are necessary for the task.
Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.

首先阅读本
```
SKILL.md
```
，然后仅加载完成任务所需的相关深度参考文件。
应用本技能中的有序指导、检查清单和决策规则，而非随意挑选孤立片段。
交付成果需明确标注假设条件、风险以及后续工作（若相关）。

Quality Standards

质量标准

Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
Prefer deterministic, reviewable steps over vague advice or tool-specific magic.

输出内容需以执行为导向、简洁明了，并与仓库的基础工程标准保持一致。
除非技能明确要求更高标准，否则需保持与现有项目惯例的兼容性。
优先采用可确定、可评审的步骤，而非模糊建议或工具特定的“魔法操作”。

Anti-Patterns

反模式

Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
Loading every reference file by default instead of using progressive disclosure.

将示例视为可直接复制粘贴的模板，而不检查是否适配、约束条件或失败模式。
默认加载所有参考文件，而非采用渐进式披露方式。

Outputs

输出成果

A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
References used, companion skills, or follow-up actions when they materially improve execution.

符合任务要求的具体结果：实施指导、评审发现、架构决策、模板或生成的工件。
当无法仅通过现有上下文完成任务时，需明确标注假设条件、权衡方案或未解决的缺口。
若能显著提升执行效果，需列出使用的参考资料、配套技能或后续行动。

Evidence Produced

生成的证据

Category	Artifact	Format	Example
UX quality	Restaurant POS UI audit	Markdown doc covering the standard restaurant POS layout, input speed, and back-of-house integration findings	`docs/pos/restaurant-ui-audit.md`

类别	工件	格式	示例
UX质量	餐厅POS UI审计	Markdown文档，涵盖标准餐厅POS布局、输入速度和后厨集成结果	`docs/pos/restaurant-ui-audit.md`

References

参考资料

Use the
```
references/
```
directory for deep detail after reading the core workflow below.

Use this skill for any restaurant POS screen. It enforces the approved UI layout, workflow, and accessibility targets from the Restaurant POS redesign plan.

阅读以下核心工作流程后，如需详细内容可查看
```
references/
```
目录。

本技能适用于所有餐厅POS屏幕，可确保遵循餐厅POS重设计方案中已批准的UI布局、工作流程和无障碍设计目标。

When to Use

适用场景

Building or refactoring restaurant POS screens for tablet, kiosk, or handheld.
Reviewing restaurant POS UX for speed, clarity, and kitchen integration.
Standardising restaurant order entry, split billing, and KDS behaviour.

为平板、自助终端或手持设备构建或重构餐厅POS屏幕。
评审餐厅POS UX的速度、清晰度和厨房集成效果。
标准化餐厅订单录入、拆分账单和KDS行为。

Required Baseline

必需基线

Follow the three-level hierarchy: context (floor plan, table, covers), order (cart, modifiers), actions (send, pay, void).
Use large touch targets (minimum 48×48dp; 56×56dp for primary actions; 64×64dp preferred for kitchen-floor use).
Auto-focus search on order-entry load; debounce at 150 ms.
Quick-access lanes for Recent, Favourites, and Popular items, refreshed per service.
Sticky or floating cart with a single dominant Pay call-to-action.
Never generate a fiscal invoice until Pay is confirmed; bills are non-fiscal previews.
WCAG 2.2 AA compliance for contrast, focus order, and target size on every interactive surface.

遵循三级层级结构：上下文（平面图、桌台、客人数）、订单（购物车、 modifiers）、操作（发送、支付、取消）。
使用大尺寸触摸目标（最小48×48dp；主要操作56×56dp；后厨使用优先64×64dp）。
订单录入页面加载时自动聚焦搜索框；防抖设置为150毫秒。
快速访问栏展示最近、收藏和热门菜品，每班次刷新一次。
固定或悬浮购物车，搭配单个突出的支付号召按钮。
确认支付前不得生成正式发票；账单仅为非正式预览。
所有交互界面需符合WCAG 2.2 AA标准，包括对比度、焦点顺序和目标尺寸。

Restaurant POS Flow Overview

餐厅POS流程概述

The canonical transaction lifecycle runs from seating through close. Every screen in the POS maps to exactly one phase in this lifecycle; screens that blur phase boundaries are rejected in review.

text

+-----------+    +-----------+    +-----------+    +-----------+
| 1. Seat   | -> | 2. Order  | -> | 3. KDS    | -> | 4. Prep   |
|  table    |    |  entry    |    |  ticket   |    |  cook     |
+-----------+    +-----------+    +-----------+    +-----------+
                                                        |
                                                        v
+-----------+    +-----------+    +-----------+    +-----------+
| 8. Close  | <- | 7. Pay    | <- | 6. Bill   | <- | 5. Serve  |
|  table    |    |  settle   |    |  preview  |    |  runner   |
+-----------+    +-----------+    +-----------+    +-----------+

Lifecycle rules:

Seat to Order: tap a table on the floor plan, pick covers, and the order entry screen opens with table and server pre-bound.
Order to KDS: pressing Send routes items to the kitchen station printer or KDS screen and starts the prep timer.
KDS to Serve: the kitchen bumps each ticket; the runner view shows "Ready" items grouped by table.
Serve to Bill: Bill is a preview only; it does not commit revenue and can be reprinted any number of times.
Pay to Close: payment settles the check, triggers accounting postings, and returns the table to Dirty until bussed.

标准交易生命周期从入座到结台。POS中的每个屏幕都对应此生命周期中的一个阶段；模糊阶段边界的屏幕将在评审中被驳回。

text

+-----------+    +-----------+    +-----------+    +-----------+
| 1. Seat   | -> | 2. Order  | -> | 3. KDS    | -> | 4. Prep   |
|  table    |    |  entry    |    |  ticket   |    |  cook     |
+-----------+    +-----------+    +-----------+    +-----------+
                                                        |
                                                        v
+-----------+    +-----------+    +-----------+    +-----------+
| 8. Close  | <- | 7. Pay    | <- | 6. Bill   | <- | 5. Serve  |
|  table    |    |  settle   |    |  preview  |    |  runner   |
+-----------+    +-----------+    +-----------+    +-----------+

生命周期规则：

入座到订单：点击平面图上的桌台，选择客人数，订单录入页面将自动绑定桌台和服务员信息并打开。
订单到KDS：点击“发送”按钮将菜品发送到厨房工作站打印机或KDS屏幕，并启动准备计时器。
KDS到上菜：厨房完成每个订单后点击“确认”，传菜员视图将显示按桌台分组的“已就绪”菜品。
上菜到账单：账单仅为预览；不会确认收入，可多次重新打印。
支付到结台：支付完成后结清账单，触发记账，并将桌台标记为“脏台”，直到清理完毕。

Floor Plan View

平面图视图

The floor plan is the default home screen for servers. It supports two layout modes toggled from the top bar: Grid (auto-arranged rectangles) and Freeform (drag-positioned tables, saved per venue).

Table status colour codes:

Available:
```
#10B981
```
(green).
Occupied:
```
#3B82F6
```
(blue).
Reserved:
```
#F59E0B
```
(amber).
Bill-Pending:
```
#EF4444
```
(red).
Dirty:
```
#6B7280
```
(grey).

Status state table:

From	To	Trigger	Side effect
Available	Occupied	Seat covers	Start table timer
Occupied	Bill-Pending	Request bill	Lock item adds without manager PIN
Bill-Pending	Dirty	Payment settled	Post revenue, free check number
Dirty	Available	Busser marks clean	Reset timer, clear server binding
Available	Reserved	Booking synced	Lock seating window ±15 min

Interaction rules:

Minimum touch target per table tile: 56×56dp; tiles scale up to 88×88dp on 12" tablets.
Tap assigns the current server; long-press opens the table detail sheet (covers, server, elapsed time, open check).
Colour is never the only status cue; every tile also shows a status label and an icon for colour-blind operators.
Floor plan auto-refreshes every 5 seconds while idle and immediately on status-change events from the server.

平面图是服务员的默认主屏幕。支持两种布局模式，可通过顶部栏切换：网格模式（自动排列的矩形）和自由模式（可拖动定位桌台，按场所保存）。

桌台状态颜色编码：

可用：
```
#10B981
```
（绿色）。
占用：
```
#3B82F6
```
（蓝色）。
已预订：
```
#F59E0B
```
（琥珀色）。
待结账：
```
#EF4444
```
（红色）。
脏台：
```
#6B7280
```
（灰色）。

状态转换表：

原状态	目标状态	触发条件	副作用
可用	占用	选择客人数	启动桌台计时器
占用	待结账	请求账单	无经理PIN码则无法添加菜品
待结账	脏台	支付完成	记录收入，释放账单编号
脏台	可用	服务员标记为干净	重置计时器，清除服务员绑定
可用	已预订	同步预订信息	锁定入座窗口前后15分钟

交互规则：

每个桌台 tile 的最小触摸目标为56×56dp；在12英寸平板上 tile 可放大至88×88dp。
点击可分配当前服务员；长按打开桌台详情面板（客人数、服务员、时长、未结账单）。
颜色不得作为唯一状态提示；每个tile还需显示状态标签和图标，以适配色觉障碍操作人员。
空闲时平面图每5秒自动刷新，桌台状态变更时立即从服务器获取更新。

Order Entry Flow

订单录入流程

The order entry screen uses a three-panel layout optimised for 10" to 13" tablets in landscape. Portrait mode collapses the cart into a slide-over sheet.

Panel layout:

Left panel (20% width): category tabs stacked vertically with icon plus label; selected tab uses
```
#3B82F6
```
background and white text.
Centre panel (55% width): item grid with 3 to 5 columns depending on viewport; each item card shows name, price, and a small availability dot.
Right panel (25% width): cart with line items, quantity steppers, modifier summary, and a sticky subtotal row.

Controls:

Search bar pinned to the top of the centre panel, 48dp tall, auto-focused on load.
Quantity stepper: circular +/- buttons at 48×48dp minimum; tapping the number opens a numeric pad for values above 9.
Subtotal strip sticky at the bottom of the cart panel with Send and Pay buttons side by side; Send is secondary, Pay is primary.

React sketch:

tsx

<OrderEntry>
  <CategoryTabs value={category} onChange={setCategory} />
  <ItemGrid
    items={items.filter(i => i.category === category)}
    onTap={addToCart}
    columns={responsive(3, 4, 5)}
  />
  <Cart
    lines={cart.lines}
    onQtyChange={updateQty}
    onRemove={removeLine}
    subtotal={cart.subtotal}
    onSend={sendToKitchen}
    onPay={openPayment}
  />
</OrderEntry>

Tailwind conventions:

Item card:

rounded-2xl border border-slate-200 p-3 active:bg-slate-100

Cart line:

flex items-center gap-2 py-2 border-b border-slate-100

Primary Pay button:

h-14 px-6 rounded-xl bg-emerald-600 text-white text-lg font-semibold

订单录入屏幕采用三面板布局，优化适配10至13英寸平板的横屏模式。竖屏模式下购物车将折叠为侧边滑出面板。

面板布局：

左侧面板（20%宽度）：垂直堆叠的分类标签，包含图标和文字；选中的标签使用
```
#3B82F6
```
背景和白色文字。
中间面板（55%宽度）：菜品网格，根据视口显示3至5列；每个菜品卡片显示名称、价格和小型可用状态点。
右侧面板（25%宽度）：购物车，包含行项目、数量调节器、modifier摘要和固定小计行。

控件：

搜索栏固定在中间中间面板顶部，高度48dp，页面加载时自动聚焦。
数量调节器：圆形+/-按钮最小48×48dp；点击数字可打开数字键盘，输入大于9的数值。
小计栏固定在购物车面板底部，“发送”和“支付”按钮并排显示；“发送”为次要按钮，“支付”为主要按钮。

React示例：

tsx

<OrderEntry>
  <CategoryTabs value={category} onChange={setCategory} />
  <ItemGrid
    items={items.filter(i => i.category === category)}
    onTap={addToCart}
    columns={responsive(3, 4, 5)}
  />
  <Cart
    lines={cart.lines}
    onQtyChange={updateQty}
    onRemove={removeLine}
    subtotal={cart.subtotal}
    onSend={sendToKitchen}
    onPay={openPayment}
  />
</OrderEntry>

Tailwind约定：

菜品卡片：

rounded-2xl border border-slate-200 p-3 active:bg-slate-100

。

购物车行项目：

flex items-center gap-2 py-2 border-b border-slate-100

。

主要支付按钮：

h-14 px-6 rounded-xl bg-emerald-600 text-white text-lg font-semibold

。

Modifier Selection

Modifier选择

Modifiers open in a bottom sheet on tablets and a side sheet on wider screens. Each modifier group declares a selection rule and an optional price delta per option.

Group rule table:

Group type	Selection	Example	Confirm rule
Mandatory single	exactly 1	Protein: Beef, Chicken, Fish	Confirm disabled until picked
Mandatory multi	min N, max M	Sides: pick 2 of 4	Confirm disabled until min met
Optional single	0 or 1	Sauce on side	Confirm always enabled
Optional multi	0 to M	Extras: cheese, bacon	Confirm always enabled

Rendering rules:

Price delta is shown inline:
```
+UGX 2,000
```
or
```
-UGX 500
```
, right-aligned and using the monospaced numeric variant.
Selected options use
```
#3B82F6
```
border and a check glyph; unselected use
```
#E5E7EB
```
border.
A running modifier subtotal appears at the bottom of the sheet next to the Confirm button.

React component sketch:

tsx

function ModifierSheet({ groups, onConfirm }) {
  const [selected, setSelected] = useState<Record<string, string[]>>({});
  const satisfied = groups
    .filter(g => g.mandatory)
    .every(g => (selected[g.id]?.length ?? 0) >= g.min);
  return (
    <Sheet>
      {groups.map(g => (
        <ModifierGroup
          key={g.id}
          group={g}
          value={selected[g.id] ?? []}
          onChange={v => setSelected(s => ({ ...s, [g.id]: v }))}
        />
      ))}
      <ConfirmBar
        disabled={!satisfied}
        delta={sumDelta(selected, groups)}
        onConfirm={() => onConfirm(selected)}
      />
    </Sheet>
  );
}

Modifiers在平板上以底部面板打开，在宽屏设备上以侧边面板打开。每个modifier组定义选择规则和每个选项的可选价格增量。

组规则表：

组类型	选择规则	示例	确认规则
必填单选	必须选1个	蛋白质：牛肉、鸡肉、鱼肉	未选择前确认按钮禁用
必填多选	最少选N个，最多选M个	配菜：4选2	未达到最少数量前确认按钮禁用
可选单选	可选0或1个	酱汁分装	确认按钮始终启用
可选多选	可选0至M个	额外配料：芝士、培根	确认按钮始终启用

渲染规则：

价格增量显示在行内：
```
+UGX 2,000
```
或
```
-UGX 500
```
，右对齐并使用等宽数字变体。
选中的选项使用
```
#3B82F6
```
边框和勾选标记；未选中的使用
```
#E5E7EB
```
边框。
面板底部显示实时modifier小计，旁边是确认按钮。

React组件示例：

tsx

function ModifierSheet({ groups, onConfirm }) {
  const [selected, setSelected] = useState<Record<string, string[]>>({});
  const satisfied = groups
    .filter(g => g.mandatory)
    .every(g => (selected[g.id]?.length ?? 0) >= g.min);
  return (
    <Sheet>
      {groups.map(g => (
        <ModifierGroup
          key={g.id}
          group={g}
          value={selected[g.id] ?? []}
          onChange={v => setSelected(s => ({ ...s, [g.id]: v }))}
        />
      ))}
      <ConfirmBar
        disabled={!satisfied}
        delta={sumDelta(selected, groups)}
        onConfirm={() => onConfirm(selected)}
      />
    </Sheet>
  );
}

Kitchen Display System (KDS)

厨房显示系统（KDS）

The KDS renders each open ticket as a card on a dark canvas to reduce kitchen glare. Cards sort oldest-first and wrap to new columns on overflow.

Card anatomy:

Header row: table number in 32dp bold, server initials, and elapsed time clock.
Body: itemised list, with modifiers indented under their parent and allergen flags in
```
#EF4444
```
.
Footer: prep time estimate, course tag (Starter, Main, Dessert), and the Bump button spanning full width.

Elapsed-time colour coding:

Elapsed	Background	Border	Meaning
0 to 5 min	`#064E3B`	`#10B981`	On track
5 to 10 min	`#78350F`	`#F59E0B`	Watch
10 min or more	`#7F1D1D`	`#EF4444`	Late, expedite

Interaction rules:

Bump gesture: single tap arms the ticket, a second tap within 3 seconds confirms and hides it; a slide-back pill offers a 10-second undo.
Audio chime on new ticket: short 400 ms tone; muted during staff-configured quiet windows.
Course firing: the expeditor taps Fire on a course to promote it from Hold to Active; held items render at 40% opacity.
Item strike-through is not used; cancelled items are removed and a separate red Cancel banner surfaces the change.

KDS在深色画布上渲染每个未结订单卡片，以减少厨房眩光。卡片按创建时间从早到晚排序，超出时自动换行到新列。

卡片结构：

标题行：32dp粗体桌台号、服务员首字母和时长计时器。
主体：菜品列表，modifier缩进显示在对应菜品下方，过敏原标记使用
```
#EF4444
```
。
页脚：预计准备时间、菜品类别标签（前菜、主菜、甜点）和全屏宽度的“确认”按钮。

时长颜色编码：

时长	背景色	边框色	含义
0至5分钟	`#064E3B`	`#10B981`	正常进度
5至10分钟	`#78350F`	`#F59E0B`	需关注
10分钟及以上	`#7F1D1D`	`#EF4444`	超时，需加急

交互规则：

确认操作：点击一次标记订单为待确认，3秒内再次点击确认并隐藏订单；提供10秒内的滑动撤销选项。
新订单提示音：400毫秒短音；员工可配置静音时段。
菜品触发：调度员点击菜品的“触发”按钮，将其从“待处理”转为“进行中”；待处理菜品以40%透明度显示。
不使用删除线标记取消的菜品；取消的菜品将被移除，并显示单独的红色取消横幅提示变更。

Table Management

桌台管理

Table operations are exposed from the table detail sheet and from the floor-plan long-press menu.

Core operations:

Seat assignment: pick covers 1 to 8 with a stepper; values above 8 open a numeric pad. Covers are required before the first item send.
Merge tables: drag table A onto table B; a confirmation dialog lists combined covers, merges open checks, and retains the earliest seat time.
Split table: open the split sheet, drag seats from the source to a new table tile, and the source check forks into two linked checks.
Table transfer: move the entire order from table A to table B with a single action; the KDS receives an update event so in-flight tickets reroute.

Merge and split rules:

Merge is blocked when either table is in Bill-Pending; the user must settle or cancel the pending bill first.
Split creates a new check that inherits the service charge and tax policy of the parent; tips are reallocated by cover count unless overridden.
All merge, split, and transfer actions log an audit entry with the actor, timestamp, and source and target table IDs.

桌台操作可通过桌台详情面板和平面图长按菜单触发。

核心操作：

入座分配：使用调节器选择1至8位客人；超过8位时打开数字键盘。首次发送菜品前必须选择客人数。
合并桌台：将桌台A拖动到桌台B上；确认对话框显示合并后的客人数、合并未结账单，并保留最早的入座时间。
拆分桌台：打开拆分面板，将客人从源桌台拖动到新桌台tile，源账单将拆分为两个关联账单。
转移桌台：一键将整个订单从桌台A转移到桌台B；KDS将收到更新事件，正在处理的订单将重新路由。

合并与拆分规则：

若任一桌台处于“待结账”状态，合并操作将被阻止；用户需先结清或取消待结账单。
拆分将创建新账单，继承原账单的服务费和税费政策；小费将按客人数重新分配，除非手动覆盖。
所有合并、拆分和转移操作都会记录审计条目，包含操作人员、时间戳以及源和目标桌台ID。

Split Billing

拆分账单

Split billing is triggered from the check screen and supports three independent modes. Each mode generates one payment tab per split so the cashier settles them in any order.

Mode 1: Split by item.

Seat tiles across the top of the screen show the cover count.
The server drags each line item to a seat tile; unassigned items remain in a shared pool.
A "Shared" pool divides its total equally across all seats on settlement.

Mode 2: Split by percentage.

Presets for 50/50, 60/40, and 70/30; a Custom option lets the server type N shares that must sum to 100%.
The preview shows the computed amount per share, rounded to the currency's smallest unit with the residual assigned to the first share.

Mode 3: Split by count.

Even split across the seated cover count; the UI shows "UGX X per cover" and rounds the residual to cover 1.
Supports a partial-count override for guests leaving early while others continue.

Common rules:

Service charge and tax are split proportionally to each tab's subtotal share.
Each split tab produces its own receipt and its own revenue posting reference; they share the parent check number with a suffix (
```
-A
```
,
```
-B
```
).
Switching modes after the first payment is captured requires a manager PIN and voids the prior captures.

拆分账单从账单屏幕触发，支持三种独立模式。每种模式为每个拆分部分生成一个支付标签，收银员可按任意顺序结清。

模式1：按菜品拆分

屏幕顶部显示客人tile，包含客人数。
服务员将每个行项目拖动到客人tile；未分配的菜品保留在共享池中。
结算时“共享”池的总金额将平均分配给所有客人。

模式2：按百分比拆分

预设50/50、60/40和70/30；自定义选项允许服务员输入总和为100%的N个份额。
预览显示每个份额的计算金额，四舍五入到货币最小单位，余数分配给第一个份额。

模式3：按人数拆分

按入座客人数平均拆分；UI显示“每位客人UGX X”，余数分配给第一位客人。
支持部分人数覆盖，适用于部分客人提前离开而其他人继续用餐的场景。

通用规则：

服务费和税费按每个标签的小计比例拆分。
每个拆分标签生成独立收据和收入记账参考；它们共享原账单编号，并添加后缀（
```
-A
```
、
```
-B
```
）。
首次支付完成后切换模式需要经理PIN码，并作废之前的支付记录。

Void & Refund Flow

取消与退款流程

Voids and refunds are privileged actions and always route through a manager PIN modal. The modal cannot be dismissed by tapping outside; it requires explicit Cancel.

Flow steps:

Server taps Void on a line or check.
Manager PIN modal opens; four- to six-digit PIN with lockout after 5 failures in 10 minutes.
Reason code dropdown appears with the fixed set: Entered in error, Customer cancelled, Kitchen mistake, Comp, Other (requires free-text note of at least 10 characters).
Void preview shows the impact on subtotal, tax, service charge, and tip.
Confirm writes the void event, notifies the KDS if the item was already fired, and updates the check total.

Refund rules:

Refund is available only after a payment is settled; partial refunds are allowed down to a single line.
Refunds post to the original payment method when the gateway supports it; cash refunds open the cash drawer with an audit record.
Both voids and refunds appear on the end-of-day reconciliation under dedicated totals, never netted into gross sales.

取消和退款为特权操作，必须通过经理PIN码弹窗完成。弹窗无法通过点击外部关闭；需明确点击“取消”按钮。

流程步骤：

服务员点击行项目或账单的“取消”按钮。
打开经理PIN码弹窗；4至6位PIN码，10分钟内连续失败5次将锁定。
显示原因代码下拉菜单，固定选项包括：输入错误、客户取消、厨房失误、赠送、其他（需至少10字符的自由文本说明）。
取消预览显示对小计、税费、服务费和小费的影响。
确认后记录取消事件，若菜品已发送则通知KDS，并更新账单总额。

退款规则：

仅在支付完成后可退款；支持部分退款，最低可退单个行项目。
若支付网关支持，退款将原路返回；现金退款将打开收银抽屉并记录审计信息。
取消和退款均在日结对账中单独统计，不会计入总销售额。

Receipt Design

收据设计

Receipts target 80mm thermal printers. The layout uses a monospaced font at 12pt body and 14pt for totals to keep character alignment under heat variance.

Vertical order:

Logo, capped at 80px height and 400px width, centred.
Restaurant name, address line, phone, and tax identifier.
Date and time, table number, server name, and check number.
Itemised list with modifiers indented 2 characters under their parent.
Subtotal, tax line per rate, service charge, and grand total, right-aligned.
Payment method, amount tendered, and change due.
Footer with a QR code linking to the digital receipt and feedback form.

Formatting rules:

Currency amounts are right-aligned to a fixed column; the item name is left-aligned and truncated with an ellipsis at column 28.
Modifier price deltas are shown in parentheses next to the modifier name.
The QR code is 120×120 px and is quiet-zoned by 4 modules on all sides.
Re-printed receipts carry a "REPRINT" watermark and a sequence number.

收据适配80mm热敏打印机。布局使用等宽字体，正文12pt，总计14pt，以确保在温度变化下字符对齐。

垂直顺序：

Logo，高度不超过80px，宽度不超过400px，居中显示。
餐厅名称、地址、电话和税号。
日期和时间、桌台号、服务员姓名和账单编号。
菜品列表，modifier缩进2字符显示在对应菜品下方。
小计、各税率税费、服务费和总计，右对齐。
支付方式、支付金额和找零。
页脚包含二维码，链接至电子收据和反馈表单。

格式规则：

货币金额右对齐至固定列；菜品名称左对齐，超过28列时用省略号截断。
Modifier价格增量显示在括号中，紧跟modifier名称。
二维码尺寸为120×120 px，四周保留4模块的空白区。
重印收据带有“REPRINT”水印和序列号。

End-of-Day Reconciliation

日结对账

Shift close opens a reconciliation workflow that a manager must complete before the POS will accept a new shift.

Summary sections:

Gross sales, voids, refunds, and net sales, shown as currency totals and as counts.
Sales by category: Food, Beverage, and Other, each with subtotal, tax, and tip share.
Sales by payment method: Cash, Card, MoMo, Airtel Money, Bank Transfer, and House Account.
Tip total by server and a separate pooled-tip figure when tip pooling is enabled.
Discrepancy report comparing expected cash-drawer balance to the counted balance; differences over a configurable threshold require a manager note.

Close rules:

The reconciliation snapshot is immutable once signed; corrections are posted as adjustments to the next shift.
Exports are written as CSV and PDF to the shift archive and pushed to the accounting module through the companion
```
saas-accounting-system
```
skill.
Any open check on the floor plan blocks close; the manager must settle or transfer it explicitly.

班次结束时将启动对账流程，经理必须完成该流程后POS才能接受新班次。

汇总部分：

总销售额、取消金额、退款金额和净销售额，显示货币总额和数量。
按类别划分的销售额：食品、饮料和其他，各包含小计、税费和小费份额。
按支付方式划分的销售额：现金、刷卡、MoMo、Airtel Money、银行转账和挂账。
按服务员统计的小费总额，以及启用小费池时的单独小费池金额。
差异报告，对比收银抽屉预期余额与实际清点余额；超过可配置阈值的差异需经理备注。

结账规则：

对账快照一旦确认即不可修改；更正需作为调整项计入下一班次。
导出文件保存为CSV和PDF至班次归档，并通过配套
```
saas-accounting-system
```
技能推送至记账模块。
平面图上的任何未结账单将阻止结账；经理必须明确结清或转移账单。

Staff Management UI

员工管理UI

Staff operations live in a dedicated back-office tab. The front-of-house POS exposes only clock-in, clock-out, and tip summary.

Clock-in and clock-out:

4-digit PIN entry with an optional selfie photo for shift audit.
Lockout after 5 failed PIN attempts within 10 minutes; manager override clears the lock.
Clock events write to the timekeeping table and surface in the shift reconciliation.

Tip allocation view:

Totals by server and by shift, with filters for date range and service (Lunch, Dinner, All-day).
Pooled-tip view shows the pool, the allocation rule (by hours, by sales, or by points), and each recipient's computed share.

Server performance:

Orders completed, average ticket size, and upsell rate expressed as a percentage of eligible tickets that added a premium modifier or upsell item.
Ranked table with the top and bottom 5 performers; rankings are advisory and are never surfaced to guests.

员工操作位于专用后台标签页。前台POS仅显示打卡、退卡和小费汇总。

打卡和退卡：

4位PIN码输入，可选自拍照片用于班次审计。
10分钟内连续失败5次PIN码将锁定；经理可解锁。
打卡事件记录到考勤表，并显示在班次对账中。

小费分配视图：

按服务员和班次统计的总额，支持按日期范围和服务时段（午餐、晚餐、全天）筛选。
小费池视图显示池金额、分配规则（按工时、销售额或积分）以及每位接收者的计算份额。

服务员绩效：

完成订单数、平均客单价和追加销售率（以添加高级modifier或追加菜品的合格订单百分比表示）。
排名表显示前5和后5名绩效人员；排名仅作参考，不得向客人展示。

Offline Mode

离线模式

The POS must keep taking orders when the network is unavailable. Offline mode uses an IndexedDB queue (Dexie.js) and a cached menu snapshot.

Offline behaviours:

Menu cache is refreshed on login and every 15 minutes while online; the cache carries a signed version tag.
Orders, voids, and payments are written to a local queue keyed by a client-generated UUID so retries are idempotent.
KDS routing falls back to a station printer when the KDS is unreachable; tickets are replayed on reconnect with a duplicate-suppression window.
The UI surfaces an offline banner in
```
#F59E0B
```
with a queued-operation count; tapping the banner opens the queue inspector.

Conflict resolution:

Default is last-writer-wins on non-financial fields.
Price, tax rate, and modifier price are server-authoritative; on conflict the local record is recomputed and the operator is notified if the total changes.
Conflicts that cannot be auto-resolved are parked in a review queue and block close until a manager acknowledges them.

Cross-reference:

pwa-offline-first

for the underlying queue, service-worker, and sync mechanics.

网络不可用时POS必须继续接受订单。离线模式使用IndexedDB队列（Dexie.js）和缓存的菜单快照。

离线行为：

菜单缓存在登录时刷新，在线时每15分钟刷新一次；缓存带有签名版本标签。
订单、取消和支付记录写入本地队列，使用客户端生成的UUID作为键，确保重试操作幂等。
当KDS不可用时，KDS路由 fallback 到工作站打印机；重新连接时将重放订单，并设置重复操作抑制窗口。
UI显示
```
#F59E0B
```
颜色的离线横幅，包含排队操作数量；点击横幅可打开队列检查器。

冲突解决：

非财务字段默认采用最后写入者获胜规则。
价格、税率和modifier价格以服务器数据为准；发生冲突时重新计算本地记录，若总额变更则通知操作人员。
无法自动解决的冲突将存入审核队列，需经理确认后才能结账。

交叉参考：

pwa-offline-first

提供底层队列、服务工作线程和同步机制。

Accessibility

无障碍设计

The POS is used under bright kitchen light, with gloved hands, and across long shifts. Accessibility is a functional requirement, not a bolt-on.

Touch and pointer:

All interactive targets are at least 48×48dp; primary flow targets are 56×56dp. WCAG 2.2 target size AA is 24×24 CSS px, but the kitchen-floor minimum is 48.
Spacing between adjacent targets is at least 8dp to prevent mis-taps with gloves.
Long-press is never the only path to an action; every long-press has a visible button equivalent.

Colour and contrast:

Text contrast ratio is at least 4.5:1 against its background for body copy and 3:1 for large text (18pt or 14pt bold).
A high-contrast theme toggle swaps the palette to a near-black background with
```
#FFFFFF
```
text and
```
#FBBF24
```
focus rings, tuned for bright kitchens.
Status colour is always paired with an icon and a label, never colour alone.

Input and feedback:

Audio feedback is opt-in per device and uses distinct tones for Send, Void, and Error.
Haptic feedback mirrors audio where the device supports it.
All forms expose visible focus, programmatic focus, and keyboard navigation for external-keyboard users at the cashier station.

POS在明亮厨房环境中使用，操作人员可能戴手套，且需长时间工作。无障碍设计是功能性要求，而非附加项。

触摸与指针：

所有交互目标最小48×48dp；主要流程目标为56×56dp。WCAG 2.2目标尺寸AA标准为24×24 CSS px，但后厨使用最小为48dp。
相邻目标间距至少8dp，以避免戴手套时误触。
长按不得作为操作的唯一路径；每个长按操作都有可见的按钮替代方案。

颜色与对比度：

正文文本与背景的对比度至少4.5:1；大文本（18pt或14pt粗体）至少3:1。
高对比度主题切换可将调色板转为近黑色背景搭配
```
#FFFFFF
```
文本和
```
#FBBF24
```
焦点环，专为明亮厨房环境优化。
状态颜色始终搭配图标和标签，不得仅使用颜色。

输入与反馈：

音频反馈为设备可选功能，发送、取消和错误操作使用不同音调。
设备支持时，触觉反馈与音频反馈同步。
所有表单支持可见焦点、程序化焦点和键盘导航，以适配收银台外接键盘用户。

Canonical Source

标准来源

The canonical layout and component specs live in:

docs/plans/restaurant-pos/2026-02-03-restaurant-pos-ui-redesign.md

(project-local design reference when present).

标准布局和组件规范位于：

docs/plans/restaurant-pos/2026-02-03-restaurant-pos-ui-redesign.md

（项目本地设计参考，若存在）。

Companion Skills

配套技能

```
pos-sales-ui-design
```
— general POS patterns (cart, checkout, payment).
```
webapp-gui-design
```
— React/Next.js/Tailwind design-system conventions.
```
pwa-offline-first
```
— offline order queueing and sync.
```
mobile-rbac
```
— roles for waiter, cashier, manager.
```
saas-accounting-system
```
— revenue lines for food/beverage/other.
```
inventory-management
```
— ingredient-level depletion on order completion.

```
pos-sales-ui-design
```
— 通用POS模式（购物车、结账、支付）。
```
webapp-gui-design
```
— React/Next.js/Tailwind设计系统约定。
```
pwa-offline-first
```
— 离线订单排队与同步。
```
mobile-rbac
```
— 服务员、收银员、经理角色权限。
```
saas-accounting-system
```
— 食品/饮料/其他收入记账。
```
inventory-management
```
— 订单完成时食材消耗统计。

Sources

参考来源

Apple HIG for iPad POS —

developer.apple.com/design/human-interface-guidelines

Material Design for Android tablets —
```
m3.material.io
```
WCAG 2.2 target size —
```
w3.org/TR/WCAG22
```
Square POS product docs (industry reference) —
```
squareup.com
```

Apple iPad POS人机界面指南 —

developer.apple.com/design/human-interface-guidelines

Android平板Material Design —
```
m3.material.io
```
WCAG 2.2目标尺寸 —
```
w3.org/TR/WCAG22
```
Square POS产品文档（行业参考） —
```
squareup.com
```

References

参考资料

references/restaurant-pos-ui-standard.md

references/restaurant-pos-ui-standard.md