Cashier、保险回款、套餐与诊后任务 PRD

患者标签 V1 的「有未付」按本篇真实患者责任余额及账单授权范围派生；标签判定、页面与权限唯一见 Frontoffice §2.7（2026-11-01 已确认；本地实现与逐项验证边界见该节）。标签不改变付款／结算门禁，不提供独立清账操作。

更新：2026-11-02 · 责任：Line A；涉及 Pharmacy、医生及 Finance 交接

2026-09-09 导航归属： Cashier 置于 Business Operations；Insurance & Benefit Programmes 独立维护共享保险／企业／员工计划，Packages & Coupons 集中现有套餐和优惠活动。持卡、Visit 付款安排、账单核验与回款仍在各业务记录处理。套餐现有支付链路、Coupon 核销及叠加的未完成项不因入口合并升级为已完成。票据模板的日常入口唯一放在 Cashier 右上角齿轮，票据读取／打印沿用有效动作与逐账单范围，权限一致性修复见统一打印；模板编辑仍使用 billing.documents.manage 及既有配置门禁；System Settings 不再向普通护士或医生提供重复卡片。模板更改不重写历史账单。完整目录与配置范围见App 与配置层级。

功能地图

围绕一次结账及其后续账务组织功能。待办、历史和日报是工作入口；费用、付款和票据是各自业务对象。

1. 一次结账处理什么

相连临床桌面中，链接图标放在应用名称之后，不另占共享患者栏；Billing 的预览／Checkout 自身标题保留患者及 Chit。窗口排列使用桌面 Dock 的 Layout 菜单；Billing 使用标准窗口展开／还原控件，不另设展开按钮行，并恢复原位置。问诊收费审核处仅在 Billing 未可见时提供 View Billing，复用现有窗口及财务权限。Billing 在问诊期间显示同一明确 Visit 的唯读已储存草稿预览：诊金、已保存处方／服务费用、可用金额、缺价和刷新时间。源模块未保存时显示 Changes awaiting save，缺价保持未能提供而非零。费用编辑和临床 Review & Sign 保留在问诊；保存来源变更后刷新预览，原调整仅在来源指纹相同的情况下复用，否则提示重新审价。成功临床签署后加载现有正式 Checkout；预览不建草稿、不取消确认、不签署、不开票及不收款。财务输入未完成时来源费用变化标为 stale，保留输入并要求复核。医生继续受既有唯读范围限制，Invoice、Settlement、Pharmacy 及付款门禁仍由服务端执行。预览接口及验证证据见工程设计。

已轉換診所依持牌 Center／Zone 模型共用 Center 收費隊列、Invoice、收款及未付餘額；Zone 是服務位置及追溯維度。保留原 Zone 價目／覆寫，未過帳費用採實際服務 Zone 價目，已過帳金額不靜默重算。新單據採持牌 Center 身份並保存服務 Zone；原號碼、金額、付款、模板及文件快照保持原值。

Cashier 用于完成本次就诊的结账，由护士操作，不单独设置收银角色。护士需要在当前诊所服务对应医生，并具有相关财务操作权限；处理付款无需另行取得医生的临床记录查看授权。

护士在一张付款清单中核对费用、折扣及逐项 Co-pay，录入一种或多种付款方式及必要欠款安排，再通过一次 Confirm payment 确认。系统在同一事务内为本次选择处理的当前项目建立所需正式发票、登记真实收款并确认结算；不要求护士先逐组 Post Invoice。发票、实际收款、结算与收据仍为不同可追溯对象，权限及财务状态由服务端分别检查。

Checkout Completed 表示现场结账和离院安排完成。尚未收回的款项保留在应收账（AR），后续到账、退款和调整都记录在原业务上，不重写临床记录。

1.1 检验独立结算

同次就诊既有药品又有检验时，检验可以先独立结算，药品仍审方后结算。检验不增加前置审核，不等待药房审方／库存门禁；药房原有审方、库存及结算要求继续适用。2026-10-26 确认在此基础上支持逐项处理；每个项目仍遵守自身临床门禁，详见 §1.2。

• 费用记录保持同一原 Visit／检查申请关联，区分检验费用组与其余费用及各自结算状态。检验组确认不能让药品组显示为已结算，也不能绕过药房门禁。
• 检验执行采用对应检验费用范围的 Settlement confirmed：包含实收、零额及已明确确认的保险／患者欠款安排；不要求全部应收到账。发票过账、打印或仅存在 AR 不单独放行。
• 付款分配、第三方责任、患者欠款与退款应可追溯至对应费用组，不能同一金额重复满足两组结算。本轮发票及付款分配设计见下方界面与发票方案；业务已确认与工程建议分别标注。
• 检验结算成功后创建或放行对应执行单；未成功交接需展示待处理／失败和重试，不重复收款或重复创建检验单。V-Lab／外部实验室按实际项目选择分流。
• 检验已结算／已放行不等于整次 Checkout Completed。整次离院交接仍检查其余应处理费用、药品与既有交接条件；不要求长期检验报告先出齐。
• 取消、退费、项目修订及撤销检验结算对原执行单的影响须按状态细化，不能自动撤销另一费用组，也不能以财务退款推定 LIS 已停止检测。

唯一检验业务门禁及样本／报告规则见 V-Lab LB-01。当前代码已有按费用组开票／结算路径；2026-10-16 核对发现最终 Checkout 的跨组版本校验及界面状态存在缺陷，本轮按 §4.3 修复。代码存在、本地验证、STG 与 UAT 状态分别见 WS5 和专项证据。

前台不执行这些付款操作。医生的只读入口及后台财务职责仍按各自授权范围处理，完整分工见 权限方案。该规则于 2026-09-14 确认，角色模板、队列、接口及存量账号仍待对应实施核验。

1.2 统一付款清单与发票归属

2026-10-17 用户确认：取消 Laboratory／Medication & other charges 费用组 Tab，在原 Checkout Queue → Visit 详情展示一张付款清单。2026-10-26 用户确认在同一清单内增加逐项处理方式，取代原“不建设项目选择”的限制；费用组 Tab 不恢复，§1.1 检验独立结算与药房临床门禁保持有效。

2026-10-19 用户确认：进入单个患者的付款详情后，隐藏 Checkout／Billing History 等工作区级 Tab 切换；以患者及 Visit 身份、当前付款内容和 Back to checkout queue 为操作主线。返回队列后恢复工作区导航，并保留原搜索和筛选。发票自身的 Billing history／补收款入口、原发票追溯、未保存保护及财务权限保持有效；此变化不删除 Billing History 功能。

底层同一 Visit、每个费用组允许按不同次处理范围建立多张 Invoice，同一个有效收费来源不得重复存在于有效已开票记录；历史／作废／更正票仍归原组。统一清单不建立额外总发票，不自动拆分旧合并发票或重记历史支付。Payment／AR 保留所属 Invoice 及费用组，一笔实收不能重复抵扣。检验已结算不阻止尚无付款／结算的药品按既有规则退回问诊；已付款药品仍须受控财务更正。实现与验证状态见 WS5 和专项证据。

Lab 的承接与后续界面唯一见 Lab PRD，我方内部服务拆分见 工程方案。

1.3 团队与工作场景

2026-09-07 已确认：Billing & Insurance 是同一个团队／角色入口，账单、保险核验、付款责任和回款作为团队内部工作组织。后台岗位在后台处理获授权的原 Clinic／Visit／Invoice 业务；现场 Cashier 操作由当前 Clinic 与负责医生有有效服务关系、且具相应财务动作权限的护士／Frontline Staff 执行。只有预约及基础资料维护权限的接待身份，不因共用入口获得签到或 Cashier 权限，也不把后台团队混入 Clinic 角色列表。

Finance 保留为唯一后台财务角色，在后台处理获授权的 Clinic 与 WDL／CP 财务业务，具备价格查看／维护、病人附件查询／查看、每日日结报告查看的目标权限。角色归属、数据范围、历史快照及报告只读边界统一见 组织与权限产品方案。本节是新确认的产品规则；团队入口、有效权限合并与后台场景已按平台实施边界章节 实现；旧账号保留来源诊所范围，完整后台跨诊所授权与权限细分尚待实施。

当前来源范围： BackOffice 工作单位本身不代表已获某个诊所的 Cashier 收入范围。通过既有动作权限后，若当前上下文没有可查询的 Clinic／Center，Checkout Queue、Billing History、到账列表及 Day-end 明确说明范围不可用，并提示切换至已有授权的诊所／Center；无授权服务 Zone 同样单独解释。权限不足仍明确拒绝，不能用空列表掩盖。此状态与“在有效范围内没有符合筛选的记录”、读取失败和真实零收入分别展示，不生成／导出零收入报表，也不允许在无来源范围时登记到账。本轮不新增跨诊所选择器或授权。

2. 页面功能与字段

默认入口与返回（2026-10-16 确认）： 从桌面独立打开 Cashier 时先显示 Checkout Queue，不因另一应用保留了患者／Visit 上下文而自动进入某人的付款或草稿预览。用户从队列明确选择 Visit，或从问诊／eMR／账单发起带明确对象的关联入口后，才打开相应记录；问诊期间的已储存草稿预览与只读边界继续保留。返回队列须有可见的文字入口，清除本窗口的记录选择并保留队列筛选，不清空其他临床应用的患者或草稿；回到队列后，共享上下文更新不能自动再次打开患者。历史详情及票据设置同样提供有明确目的地的返回动作。返回、切换、关闭仍执行未保存输入和进行中操作保护；关闭 Cashier 不完成 Checkout、不撤销已记录付款；关闭后不得由 Consultation 或共享患者监听重新打开，窗口规则见 Platform §6.5。

队列附件（2026-10-24 确认；2026-10-27 更新呈现）： Checkout Queue 每个 Visit 的操作区提供带提示及键盘焦点的 28px 附件图标 Add attachment，与 Open 保持 6px 间距；在弹窗内显示患者／本次就诊、选择文件、保存及已保存附件列表；不要求先进入付款详情或退回问诊。入口按实际附件权限显示，上传逐文件校验类型与大小，并在服务端复核当前患者、原生 Visit、诊所范围及操作资格；仅追加本次公共补充附件，不暴露医生私人附件、不放开已完成记录的删除／修改。上传成功后刷新列表；失败保留未成功文件，关闭未保存文件须提示；上传中阻止关闭及切换。上传不更改签署内容、付款分摊、发票、收款、药房门禁或 Checkout 状态。权限及来源规则复用 Frontoffice 附件规则。

整体界面遵循 Desktop UI Design System：使用共享主题的主动作及选中态、Element Plus 表单／表格与 AppDialog，保留 Cashier 窗口的应用识别色。收费、付款责任、实际收款与结账交接按任务分区；本次可处理范围、患者应付及下一步保持清晰。窄窗口通过分区换行或表格内部滚动保留金额和操作，不缩小关键财务文字或隐藏门禁。

相连参照窗采用紧凑的 Charges／History／Day-end 导航，不重复窗口应用名称；现有可读页签及 Settings 权限继续有效。患者及 Chit 位于内容头部，刷新为有名称及提示的图标按钮。问诊期间，已储存来源按 Consultation、Medicines、Services & investigations 分组，显示药品数量及单价、来源金额、缺价／待保存／需重新覆核状态、更新时间及固定的 Saved total。缺价行与不完整总额继续显示 Unavailable。

Cashier 已选患者的头部放在 Charges／History／Day-end 导航之前，并复用与 eMR／Consultation 相同的姓名、头像、DOB／年龄／性别及患者编号呈现；已签署状态也采用同一组件。付款清单的身份摘要只取当前获授权的 Visit 响应，服务端同时返回患者姓名、编号、DOB 与性别；缺失值保持未提供，不能用缓存中同一 Patient 的旧 DOB／性别覆盖，不为只读财务角色额外读取完整病历。队列和正式 Checkout 的 Patient No. 取该 Visit 所属集团、诊所及患者匹配的有效诊所关联 PN；缺少时显示患者编号待定，不以全局 VPN、历史快照或其他诊所 PN 补足。此只读显示不改写既有 MRN／VPN 或收费记录。Chit 仍按同一 Visit 核对，不能借用其他就诊编号。三应用采用问诊参考的统一窗口栏、实色主动作和中性任务表面，风险及财务状态保留语义色。

签署后的只读 Checkout 将收费表放在前面，来源、数量、单价、折扣及金额采用适合窄参照窗的排列；付款详情可展开查看，字段仍禁用且不提供财务提交动作。未为只读会话读取的套餐账户不显示虚假的 None linked。具写权限的既有完整审价、开票、付款、结算及退回流程保持有效。所有患者与财务命令继续通过现有安全切换及服务端授权。

Billing History 可见性（按现行组织与权限规则校正）： Doctor、Frontline Staff、Finance Team 的系统默认包含各自适用的只读能力，集团可在角色上限内调整；历史 Nurse／Finance 身份沿用其当前有效配置。入口与读取必须依据实际生效的动作权限，不能因角色名称、空模板或旧默认值补发 billing.read；已有有效读取权限也不能被旧导航隐藏配置遮蔽。集团模板明确禁用的动作保持禁用；没有任何符合当前读取路由要求的有效权限时，普通登录和 Assume 均拒绝访问。医生同时可查看 Checkout Queue 中本人正在结算的 Visit、费用与已记录付款／结算进度；本人范围由服务端限制，直接访问其他医生 Visit 或 Invoice 不得绕过。护士和财务沿用当前有效服务／诊所授权范围。读取权限不授予结算、改价、收款、退款、Void、重新确认或检验交接写权限；只读会话不显示财务提交按钮，付款输入保持禁用。账务更正与第三方回款入口须同时满足现有服务端路由的动作权限和受控更正资格；不能仅凭可以执行 Checkout 或角色名称，显示服务端会拒绝的操作。本轮只校正入口可见性，不扩大后台授权。

Cashier 顶部保留三个日常工作入口；票据模板属于配置，从右上角 Settings 进入，不作为平级 Tab：

角色入口边界（2026-09-12）： 医生可进入 Cashier App 的 Checkout Queue、Billing History 和 Day-end Report，三者均只返回本人责任医生范围的数据；医生不能维护票据模板，且结算、收款、退款、Void 等写操作仍由 Cashier 写权限控制。billing.day_end.read 与只读 Cashier 数据权限独立于 Packages & Coupons，后者可见不代表获得 Cashier 操作权限。

普通身份与 Assume 的同范围规则（2026-10-18）： 在相同有效角色、目标员工、Clinic／Center 和 Zone 授权下，普通登录与 Assume 使用同一责任范围。普通身份取本人，Assume 取已绑定的目标员工，不以真实管理员身份补充可见记录；未绑定有效目标员工的医生 Assume 不返回本人责任记录。Doctor、Allied Health Professional 及兼容医生角色先按 Visit 的稳定 doctor_user_id 判断归属，只有该字段为 NULL 才按 provider_id 对应的员工身份回退；稳定 owner 指向其他医生时不能用 provider、重名或管理员身份绕过。该规则同时覆盖 Checkout Queue、Visit／付款清单详情、Invoice 详情、Billing History 与 Day-end。护士／Frontline Staff 的有效服务关系也同时约束队列、详情及历史，撤销关系后直接访问旧链接不能继续读取。角色范围始终与集团、Clinic／Center、Zone 和既有动作权限取交集；范围一致不代表取得写权限，写操作仍检查当前有效动作权限及 Assume 模式。退出 Assume 后恢复原管理员身份与 membership，不保留目标员工范围。

票据设置（2026-09-08 确认）： 右上角使用轻量齿轮入口，悬停或键盘聚焦显示 Settings 提示，打开 Cashier settings，内含 Payment methods 与 Invoice & receipt templates；明确显示 Back to Cashier，返回打开设置前的工作页并保留其条件与工作内容。现有标准详细发票、分类汇总发票、付款收据及诊所自定义版式继续复用；可配置 A4／A5、英文／繁体／双语、列、页尾及默认模板，不能改写收费金额。进入或离开设置时，未保存内容须先继续编辑或明确放弃；保存中禁止切换。旧模板 Tab 的已保存启动目标兼容转入设置，不恢复为主导航。

Checkout Queue 展示契约： 一条 Visit 一行，Laboratory／Medication & other charges 在该 Visit 内分别显示就绪与阻断，不因两组费用生成两条患者行。金额列显示「Visit total／就診總額」，合计全部有效收费组，已结算组仍只计一次；已过账／已付款组取其发票总额，其余组取当前签署净额。它不代表本次待收余额；来源金额不完整时显示检查金额，不默认补零。默认覆盖当前授权诊所跨日未结账记录；按就诊日期升序、首次签到时间升序、稳定 Visit ID 升序，缺少签到时间放在对应日期组末尾并标记未记录。它表达到诊先后，不冒充“进入收银台的等待时间”；改价、付款、审方更新或重试不改原排序依据。医生／状态／搜索条件应用到全量授权结果后排序分页；Ready／Blocked 只是可执行性筛选，不自动改成医疗或收费优先级。

Billing History 与待结账分开，右侧 Action 固定列须容纳完整 Open 按钮及内边距，在普通与窄窗口均不裁切文字或点击区域；窄窗口可横向滚动数据列，Open 仍固定可用。现有列表按发票创建时间及 Invoice ID 降序，时间明确标为发票创建而非到账／结算时间；同一 Visit 可有多张有效凭据，不能按患者姓名合并。历史查询、详情返回、并发状态变化和读取失败遵循共同列表契约。检验可独立结算的入队资格仍以 §2 检验交接为准，旧接口仅接受 Ready for cashier 的现状不能覆盖该要求。

本次只迁移维护入口，沿用已有模板、版本、默认状态及票据快照，不新建底表、不迁移或重置现有模板数据。列表／保存继续使用原 API 与诊所范围；可读但没有 admin.workflow.configure 的账号保持只读，设置入口不授予维护权限。底表来源与字段关系见 Cashier 工程参考；正式票据快照规则见 §4.1。

Payment Collection、Invoice Builder、Receipt History、Outstanding、Refund／Void 是上述对象内部的操作，不再独立占据 Cashier 顶部 Tab。2026-09-08 明确恢复诊所／医生 Day-end Revenue Report，取代此前将收入报表随 Daily Closing 一并排除的解释；现金盘点关账／Period Close 本期不建设。

2.1 待结账队列与医生筛选

医生下拉与患者搜索、Checkout 状态共同限定队列。数据范围始终是当前有效会话的 Medical Group／Clinic／Center／Zone 与上述角色责任范围取交集后的 Ready for Cashier Visit，包含跨日待办。医生选项由这份完整授权待办集合独立生成，不随搜索词、状态、所选医生或当前页缩减；选项只返回医生标识和显示名，不夹带患者资料。

空值表示当前授权范围内的 All doctors，不扩大医生本人或护士／Frontline Staff 的服务范围。格式合法但当前没有匹配记录的值返回空队列；无效的筛选键明确拒绝，不退回全部记录。医生条件在服务端统计及分页前应用，与 q／status 取交集；就绪／阻断状态仍依据当前真实收费与药房门禁计算。返回的 total 为组合条件下的记录数，不能只筛选当前页。

更换或清除医生条件、改变状态或提交搜索时回到第 1 页。清除医生恢复 All doctors，保留其他搜索／状态条件。已选医生最后一条待办离开队列时，界面仍明确保留当前选中条件，允许用户清除，不自动扩大查询范围。筛选不改变费用、发票、结算或临床记录。

2.2 收费与药房的岗位边界

Cashier 只查看本次处方的药房审核、预留、结算交接及阻断原因。移除 Open Pharmacy 等直接启动 Drug Dispensing 的跨岗位按钮；收银人员通过状态判断是否可结账，不能从 Cashier 进入审方、打印药签、备药或发药操作。护士原有明确 Return to Consultation 动作继续保留，不等同于药房审核退回。

Nurse／Reception 的桌面目录不显示 Drug Dispensing，保存布局不恢复该窗口，缓存 App 对象或 App ID 启动请求也不能打开。由药房身份切换到这些角色时移除原药房窗口，保留仍有权使用的 Cashier 及其他窗口。Pharmacy 和其他既有获授权角色继续通过各自工作台入口承接药房工作。

本轮收敛的是前端工作台入口与窗口边界，未迁移后端历史 pharmacy.dispense 权限，也不能据此宣称 Nurse／Reception 的所有药房 API 已被撤权；真实服务端权限迁移需另行核对角色矩阵与历史调用。医生筛选、桌面入口及跨角色交接已在精确提交 a8e8b802d3738f1e6ce025af9b3a274a2814ab94 完成隔离回归：CI 34091809502 的后端、前端、浏览器与清理检查全部通过。真实后端部署和业务 UAT 仍未完成。

flowchart LR
  V[Visit 本次计划快照] --> R[核对费用与付款责任]
  S[签署收费来源] --> R
  R --> C[一次确认全部当前可处理项目]
  C --> I[冻结各原费用范围的 Invoice]
  I --> P[记录实际 Payment]
  I --> A[明确患者或第三方 AR]
  C --> D[药房进入待备药]
  P --> T[Receipt 实收凭据]
  C --> F[Print invoice 统一入口]
  A --> L[后续补收或回款分配]

图中结算须同时满足整张审方、有效库存及当前费用版本；未付款欠款必须显式登记，不能仅凭存在 AR 自动放行。

3. 费用复核与开票

金额展示统一遵循平台两位小数契约：单价及总额显示两位小数，保留原始单价精度参与计算；缺价不得显示为零。

功能目的： 把本次有效收费来源形成可追溯的发票。

使用者与对象： 有结账权限的现场员工；Charge、Payer Split、Invoice。

操作与结果： 复核来源／数量／价格及当前折扣 → 逐项核对患者／第三方承担 → 录入本次付款／欠款 → 一次确认时冻结所需发票及登记收款。

关键边界： 草稿、已 Post 发票、实际收款是不同对象；历史账单不随目录价格变化。

BL-01： 只汇总真实有效来源。医生的 Billing Draft、签署 Charge Snapshot 与 Cashier Invoice 是不同对象；不能重复把同一处方或服务加两次。上游已取消／替换版本必须标清影响，不能继续收旧版本价。

BL-02： 折扣来源分 Coupon、Insurance／Benefit Contract、Doctor Adjustment、Package／Membership、Manual Exception。自动规则记录来源 ID／版本；医生调整与人工例外必须保留依据。Cashier 统一折扣的原因按 §3.2 记录分类及必要备注；医生行折扣的说明与界限见 Consultation PRD。百分比与固定减额不能导致负净额。

BL-03： Post 前复核数量、权威价格、折扣、付款方及本次保障异常。Invoice 冻结项目、适用价格和规则快照。缺价不自动补 0；100% 折扣或套餐扣减后净额为 0 仍是有收费来源，不自动等于 No Cashier Required。

目录新价格、患者卡有效期或合同后来改变，不改已 Post Invoice；更正需独立记录。复杂折扣叠加和套餐扣减顺序需已批准规则，不能测试人员自行猜定。

3.1 当前金额与统一折扣编辑

2026-10-28 确认：护士可将本次未结算收费金额上调至原价以上，例如原金额 100、当前 80，可保存为 120；超出原金额减受保护优惠券的部分独立记为正向金额调整，不以负折扣或改写临床原价表示。2026-10-23 已确认的统一折扣方式继续适用：Cashier 在 Payment list 行内直接修改 Consultation 带入的当前有效折扣，支持折扣率、折扣金额与 Net amount 三项联动；医生／护士的修改人、原值、新值及时间由后台审计记录，界面不再分成 Doctor discount／Other discounts／Additional discount 三列。本规则取代 2026-10-16 的“保留医生折扣、护士只能追加固定减额”；原单价及数量继续只读，不改变药房获授权改价规则，不追溯重算历史交易。

三个输入同时可见，以最后编辑的一项为计算依据；任意一项有效输入都会立即更新另两项、逐项责任及清单净额合计。无效或空白输入保留为待修正状态，清空衍生值并阻止覆核／保存，不将空白当作零。比例计算金额时按分四舍五入；折扣金额或净额输入保持精确值，比例只作两位小数显示，不通过显示比例反算覆盖金额。例如原金额 1,000.00，80.00% 对应减免 200.00、折后 800.00；减免金额改为 250.00 后比例为 75.00%。原金额为 0 时仍可直接填写非负 Net amount，比例显示 0.00%，不发生除零；正金额全部记为正向调整。净额高于原价时实付比例可显示大于 100%，该比例暂作只读，通过 Net amount 继续调整；改用折扣金额会清除正向调整并重新计算净额。

折扣率、折扣金额及净额在 Payment list 的同一收费行直接输入，无须先点击 Adjust discounts。表内金额列可随窄视口横向滚动，项目身份固定在左侧；清单合计及主要收款操作保留可见。首次修改后在表下显示原因及 Cancel changes／Save amounts；保存前以 Confirm amounts 紧凑确认框展示修改前后净额和未付票作废影响。尚有未保存折扣、无效值、收费版本冲突或结果未知时，不能确认付款。取消仅丢弃本地折扣草稿。历史百分比修订保留原“减免比例”语义，新录入的八折使用独立输入类型，不重释或重算旧账。

首次默认带入当前有效折扣：没有历史 Cashier 调整时就是 Consultation 的折扣；历史人工例外和护士追加减额合并为一个当前可编辑金额，不丢失已有优惠。保存新值是替换该金额，不再与医生原折扣重复相加。实际已应用的 Coupon 是独立权益，保留其已记录减免／核销；只有非零时在项目下说明 Applied coupon 及金额，不常驻空的 Other discounts 栏。本轮不新增 Coupon 维护入口、合同优惠或复杂叠加规则。

具备 billing.checkout 及对应诊所范围的护士／Frontline Staff 可编辑。保存时选择 §3.2 的折扣原因分类，补充备注按该节规则填写；后台追加分类、员工原文、修改类型、输入原值、原折扣、新折扣、原／新正向金额调整、原／新净额、操作人、时间、稳定收费来源及版本，临床签署内容与旧账务事实保持不可变。旧追加／人工例外接口不能覆盖已有统一折扣修订，需刷新后使用当前编辑器。

编辑资格按对应费用组／发票财务历史判断：当前组尚无付款或结算且 Visit 为 Ready for Cashier 时可编辑，另一费用组已结算不单独锁定本组。零额结算、第三方安排和后续退款／撤销均计入该组历史，不能借撤销绕过限制。已发生财务事实后继续通过原交易受控更正。

存在尚未付款／结算的草稿或已 Post 发票时，保存折扣同一事务作废旧票并保留快照；重新复核逐项付款责任，在后续 Confirm payment 中明确签发所需新票；保存折扣本身不自动签发替代票。来源、医生签署版本、数量或原有优惠依据改变时，旧修订不静默套到新收费依据；旧窗口提交被拒绝并要求复核。取消或无效输入均不改写金额，重复请求不重复记账。

正向金额调整与折扣修改共用上述权限、原因、来源版本、事务、幂等和财务历史保护。新票据小计包含正向调整，并保留原金额及调整额用于核对；旧票据及签署快照不变。

保存金额不等于确认结算。 患者承担与第三方承担按 §5.0 重新核对，付款责任确认失效；仍须开票、实收／零额／明确付款安排及对应组结算。折扣修改不绕过药房、库存或检验门禁。

3.2 退回、折扣及欠款的原因记录

2026-10-18 本轮采用简短分类与独立备注，适用于 Cashier 的 Return to Consultation、统一折扣及患者欠款安排。新表单必须选择有效分类；除 Other／其他外，备注可留空，不要求为普通分类补写套话。选择 Other 时备注必填。分类与员工输入原文分别保存、显示和审计，不把系统分类文案或自动摘要冒充员工说明；旧自由文本请求继续接受，历史原文保持原样，不反推或补写分类。

普通付款及 Complete checkout 不新增必填原因。最终交接仍需明确勾选确认；系统不能将预设“已核对”句子记成员工自由文本。退款、Void、付款方式纠正等受控财务操作继续沿用各自原因及凭据要求，不套用本节来取消门禁。

3.3 Consultation review 的范围边界

2026-10-29 的统一产品契约见 Consultation §5.1：Service 按 Edit 审核／Sign 发布，进入 Ready for Cashier 后不可直接修改，Registration Queue 与 Cashier 共用正式退回规则；退回不开放已结算项目。Cashier 只读取已批准／发布的有效 Service，不读取待审副本。原签署、票据、结算及执行历史保留，旧金额／版本提交拒绝。此前临床完成后护士直接修订待收费 Service 的例外已被取代。

实现与验证证据按当前执行记录判断，旧直接维护流程的通过记录不作为新权限／状态规则的验收。

4. 一次性结算与药房联动

功能目的： 确认患者本次付款或欠款安排，向药房发出可备药结果。

使用者与对象： Cashier；当前 Invoice、Payment、患者／第三方 AR 与结算记录。

操作与结果： 审核与库存通过 → 记录实际收款或明确欠款安排 → 确认结算 → 药房备药；结算后统一打印 Invoice。

关键边界： 结算确认不等于全部到账；Receipt 仅对应真实付款，已登记欠款保留应收。

BL-04： 药房审核期间只可先核对其他费用，药费显示等待药房确认；不先收其他费用。全部药品审核／库存预留通过后，核对有效价格版本，统一结算全部费用。未通过、退回、价格待核对或预留释放时服务端阻断收款。

BL-05： 药房所需条件是 Cashier“结算已确认”：普通自费收妥全部本次款项；整次应收 0 时显式确认零金额结算；保险全额承担且患者 Co-pay 为 0 时无需选择收款方式，可确认付款安排，患者实收为 0，不生成虚假收据，保险金额保留为第三方应收；存在第三方责任时须明确确认，且患者自付已结清或全部余款已明确登记欠款，再确认付款安排。2026-09-10 用户明确确认“登记欠款安排后即可放行备药”，覆盖此前患者自付必须全部结清的限制。Cashier 可登记患者本次全额欠款、部分付款后的余款或保险 CoPay 欠款，不增加本轮未要求的额外审批。实际收款、零金额确认、患者与第三方应收分别记录，不把未到账应收伪装成 Paid。整张当前处方审方、有效库存及费用版本门禁仍须通过；结算确认不自动写为已备药／已发药。

BL-06： Receipt 关联真实收款；零金额结算留确认记录但不生成实际收款流水。重复提交、重印均不增加付款。现有多笔付款数据基础保留，但不得把原“先收服务费／后收药费”或跨阶段部分收费当作本期正常药房流程。

BL-09 退回与重新问诊： 原已确认的分步设计是：药房退回整张处方时阻断 Cashier，但 Encounter 暂留 Ready for Cashier；护士查看药房原因并明确执行 Return to Consultation 后，才转入 In consultation，两个动作分别审计。

2026-10-29 状态锁整合： 药房反馈已恢复上述分步路径：保留 Visit 原状态，建立异常／医生待办、释放可退回预留并阻断收费；不能代替护士正式 Return。该修复消除此前代码直接重开与原分步设计的差异；两次动作及后续临床重新提交的本地验证、Git 与运行边界见本轮证据，不据此宣称 UAT。

当前退回实现将 Prescription、Service Selection 与 Billing Draft 在同一事务恢复为普通可编辑草稿，保留首次签署、原 Handoff 及原收费快照，不要求 Amendment reason／Cancel-Replace Handoff；医生重新 Review & Complete 后生成新的当前签署版本再交由 Cashier／Pharmacy。患者要求再次问诊或不要药，仍由获授权的 Cashier 员工明确发起退回；Cashier 分类与备注按 §3.2 留存，不能以分类代替现有药房反馈事实。未发生实收／结算的相关发票可在退回事务中作废并保留；已发生付款或结算后不得直接回退，须走受控财务更正。本地测试、Git 及部署状态另行记录；其他未决业务事项不因本次状态修复而关闭。

本次药品改价只影响当前处方收费，改价必填原因、允许零价，所有 Drug Dispensing 操作人员可在未结算时直接操作；管理人员事后处理改价记录，不审批本次改价。Cashier 必须使用新费用版本；不覆盖已签署临床记录、已 Post Invoice 或历史付款。重新形成费用／账单快照的服务端方案需按现有表和审计能力设计。

金额为合成测试数据。

4.1 合并混合收款、票据与重试

2026-10-16 用户确认：逐项记录患者／医疗卡责任分摊，患者实际收款可合并并使用 Cash、Card、FPS 等混合付款，不要求逐收费行选择实际付款方式。

逐项处理（2026-10-26 用户确认）： 保持现有清单、付款责任和混合收款逻辑，在未开票且当前可处理的收费行增加本次处理方式。诊金、单种药品、单项检验及其他收费使用同一规则：

已确认项目保持原冻结责任及账单，后续补收只针对原 Invoice，不能再次选择为新项目开票。患者责任为 0 的项目使用 Pay now 零额／第三方责任结算，不制造“下次付款”欠款。每条项目本次支付金额之和与下方付款方式及医生账户金额之和必须一致；方式分配不越过逐项已确认金额，金额、来源及分配保留在票据和审计。所有项目暂不处理时允许只确认处理安排或同时收取通用 Deposit，不建立虚构账单。

未通过自身临床门禁的项目仍待覆核，不因逐项选择或 Deposit 收款放行。整张处方临床审方保持；其后的付款及实物放行按具体药品对应的有效结算判断，不能借同处方另一项的结算放行。已签署收费版本发生变化时要求受控更正，不将旧版本已开票项目套入新费用。

确认前展示本次项目范围、患者应付、各方式实际付款、剩余患者欠款及第三方责任；已开票项目保持原冻结分摊，新项目在同次确认时开票。系统按明确、稳定的规则分配实际付款至原发票及费用组，同一金额不能重复抵扣。按发票 ID 升序、录入付款行顺序分配，分配结果保存在原发票、结算和审计中；护士无需增加一次分配预览或把每种付款方式手工拆到每条收费行。单组路径继续适用相同规则。

服务端在写入前逐组验证权限、发票、费用／账务版本和门禁。所需发票过账、收款、分配、患者余款安排与结算记账在同一事务中全部成功或全部拒绝；同一请求超时重试返回原结果，不重复记账。实际检验交接失败单独展示待处理和重试，不重新收款、不重复建立执行单。第三方责任不是实收；患者未付差额只能在明确确认欠款安排后保留为患者应收，不能自动转给医疗卡承担。

结果未知时恢复原命令： 付款确认或折扣保存的响应无法确认时，保留原 Visit、完整提交内容及同一幂等标识。恢复读取尚未结束时仍属于进行中操作；恢复读取失败或财务命令结果仍未知时，禁止编辑、Discard、返回／关闭及身份／工作上下文切换。页面提供 Check saved result／核实储存结果，以原提交内容与原幂等标识确认该次命令；普通列表刷新可以展示当前账务，但读取成功或金额发生变化不能单独证明原命令已成功。收到确定的保存结果后才将原命令标为已确认并解除保护；恢复失败仍保留原请求。Discard 只能丢弃尚未提交的输入，不能当作撤销可能已入账的操作。

发票正式 Post 时固定当时有效默认模板版本和患者／诊所／医生显示快照；付款登记时固定 Receipt 模板。更改默认模板仅影响未来签发。旧数据缺少历史快照时，首次重印明确保存其补录来源，不能声称还原历史模板。草稿有 DRAFT 标识，作废发票显示 VOIDED，退款后重印显示已退款金额；Credit Note 与调整后金额单独显示，原发票总额不改写。

Post 使用有效默认 Invoice 模板，模板选择位于结算后的打印入口。Invoice 已有按次选择版式及独立冻结打印模板的基础；2026-10-27 确认将同一能力扩展至 Receipt、打印内容与医生科室身份，完整规则见下方统一打印。原签发模板、费用和身份快照保持原值；无既有打印快照且未另选版式时沿用原签发版式。保留历史／草稿文档的既有访问边界。

每一笔实际付款记录明确方式、金额和外部凭据；付款方式不得自动推断。拆分支付在同一结算事务中全部成功，或全部拒绝。失败重试使用同一请求标识；原命令结果未知时不得修改内容或换键重试，确认结果后新的金额／方式提交才生成新标识。零额结算不生成虚假 Receipt，打印请求不新增收款，也不等于打印机已成功出纸。

Invoice／Receipt 统一打印、内容选择与重印

2026-10-27 用户确认并授权实施；统一打印窗口、医生多科室及服务端预览／快照已实现并通过受影响完整服务链的本地验证。 默认英文、可切换语言，版式与纸张默认展开；实现与 STG 发布核验分别记录在专项证据，业务 UAT 尚未执行。STG 核验复现了护士有有效 billing.checkout、能读账单却因缺少独立 billing.read／billing.documents.read 而被打印入口拒绝的组合；此路径已纳入兼容资格与回归验证。原截图账号和票据未能在本次护士范围内确认，不把相同症状的复现等同于原会话完整取证。

PRINT-01 入口与对象。 Checkout 和 Billing History 的 Print invoice／Print receipt 进入同一打印窗口，按“选择用途 → 调整内容 → 选择医生科室身份 → 预览 → 打印”操作。Invoice 表达原费用与应收，Receipt 必须绑定该 Invoice 下的有效真实 Payment；部分收款区分账单总额与本次实收，零收款不产生 Receipt。既有 DRAFT、VOIDED、退款、Credit Note 及调整后金额规则持续适用。此统一窗口不包含 Deposit 专用收据改造，不新增发票、收款、结算或费用拆分。

PRINT-02 用途与版式。 复用现有诊所模板、语言、纸张、默认版本及维护权限，在其上提供三种用途预设；预设只是显示选项组合，仍可逐项调整。Invoice 与 Receipt 均可为本次输出选择有权使用的有效模板；Receipt 不因已有原始模板快照而忽略本次显式选择，原始快照不被覆盖。

保险版只表示资料用途，不声称已获保险公司接受、符合所有公司指定表格或自动完成索赔。指定公司专用样本另行核对，不能以此预设替代业务核实。

打印窗口设计（2026-10-27 已确认）。 桌面左侧为内容设置、右侧为即时票据预览；窄窗口按设置、预览、确认顺序排列。布局沿用共享 AppDialog、表单、按钮和键盘焦点规范。左侧依次为用途预设与费用展示、医生与科室、补充资料、Layout & paper；后者每次打开默认展开，直接显示模板、纸张与语言。默认语言为 English，可选 繁體中文 或 English / 繁體中文；选择作用于当前打印窗口的标签与票据输出，不改患者、药品、医生或原始诊断记录，也不修改系统全局语言。新打开另一笔票据恢复默认，不跨患者保留敏感选项。

• 内容选项变化立即使旧预览失效；只有当前选择的服务端预览可用于确认。预览加载、缺少资料、权限不足与来源变动分别给出可理解的提示。
• 诊断及保险资料默认不选；用途预设不自动开启敏感资料。不可用选项显示具体原因，不能呈现一个可勾选但无真实来源的功能。
• 医生本人固定显示；科室下拉只列该医生的有效配置及“不显示科室”。历史版本重印与重新选择内容明确区分。
• 底部显示当前选项摘要、Cancel 与 Print invoice／Print receipt。打印结果只确认已发起浏览器打印，不声称打印机已出纸。

以下截图取自本地真实应用及隔离合成数据，表示本轮实现界面，不代表线上应用或 UAT 验收。执行覆盖与限制见本地验证记录。

PRINT-03 内容选项与金额。 支持逐项明细／按费用类别汇总／仅总额；原价、折扣、药品名称、检测项目名称、诊断、科室、付款方及保险资料按适用内容控制。隐藏原价同时隐藏明细单价与底部原金额；隐藏折扣同时隐藏逐项及总折扣。各显示模式均保留可识别的原票据、币种、最终收费净额及适用的本次实收、未付、退款、作废和调整事实；不能通过选项将部分付款显示成全部付清。医生本人固定为本次实际接诊医生，科室的显示／隐藏不隐藏或替换医生本人。

PRINT-04 隐藏项目的含义。 本期只隐藏名称、不排除收费：药品可汇总为“药品费用”，逐项选择隐藏的检测名称汇总为“其他检测费用”，其他允许隐藏名称的项目汇总为“其他费用”。相应数量、单价等可能透露原项目的信息随汇总折叠，费用净额仍计入对应汇总并与总额勾稽；输出注明“部分项目已汇总展示”。隐藏名称必须作用于最终打印内容，不能只通过样式遮盖、把原名称留在输出 HTML／PDF 的隐藏节点或附加数据中。全部名称隐藏、混合可见／隐藏、折扣及退款后均须保持金额一致。连项目及金额一起排除不属于本期 Invoice／Receipt；未来若需“选定项目费用清单”，另行定义其小计、原票据引用及非原收据替代的语义。

PRINT-05 医生与科室。 医生身份由原 Invoice／Visit 的稳定 Provider 来源及冻结姓名确定，不允许换成其他医生、按同名猜匹配或由打印人手填。该医生有多个已配置可用科室身份时，本次选择其一、采用有效默认项或不显示科室；缺少配置时仍可不显示科室，不编造占位身份。配置唯一规则见 Platform 医生票据科室身份。选择只影响本次输出，不改 Visit、原发票、主要 Specialty、价格或权限。旧票没有科室快照时，新增选择记为本次来源，不冒充历史签发身份。

PRINT-06 诊断与保险来源。 诊断仅来自与本次 Visit 对应的正式、可验证诊断记录及其版本，不从 Note 自由文本、AI 建议、其他 Visit 或手填内容猜补。必须通过实际生效的读取权限；Platform 公共／保密资料拆分仍待开发，不能用 PRD 目标规则冒充现有可用接口或借 Cashier 权限读取保密 Note。保险字段使用本次已保存的计划／付款方及可追溯核验资料；缺失历史快照时标明来源及记录时间，不用患者当前卡资料静默覆盖历史。无权限、无记录、未接通来源分别说明，禁止把空白视为核实通过。正式显示前由用户核对预览；金额事实不随保险版改变。

PRINT-07 权限与失效。 具有效 billing.documents.read 的会话，或具有效 billing.read／billing.checkout 且未被显式禁止票据读取的 Nurse／Frontline Staff，可在既有服务／诊所／Centre 与获授权 Zone 范围内打印可访问账单；模板读取、打印候选、预览、正式打印与重印使用一致的权限和对象范围。保留普通／Assume 同范围、显式拒绝、服务关系撤销及租户隔离，不以角色名自动补发动作或扩大模板维护权限。能够打开 Billing History 不单独证明可以打印全部记录；缺少资格应在入口说明原因。服务端在预览及最终提交重新校验；切换患者、Invoice、诊所、角色或 Assume 后废弃旧预览，迟到响应不得覆盖新上下文。确认前状态／资料变动时要求重新预览。

PRINT-08 打印快照与重印。 原 Invoice／Payment 为账务依据；每次确认打印另存模板及版本、内容选项、显示字段、医生科室、来源版本、操作者／时间及必要输出版本。服务端决定金额和身份，不接受客户端覆盖账务、医生或诊断文本。预览不记作正式打印；确认只记“已发起打印”，不认定设备已出纸。提供“按上次版本重印”和“重新选择内容打印”；前者保留原显示选项和当时身份，后者形成新的打印快照，两者均保留原事件。没有历史快照时明确说明来源不足，不承诺完全还原。

重印仍须校验当前读取权限，并核对作废、退款、更正等必要状态；历史输出不能绕过撤权，不能把已失效票据作为当前有效凭据。原快照不覆盖，当前必要状态变化应在新的重印事件及输出中明确标记；为保证预览与输出一致，发生状态变化时重新预览。医生科室改名／停用不回写旧快照；新选择按当前有效配置，历史版本保留当时显示但不隐去当前票据失效事实。

实施边界。 权限排查修复先于新增打印功能；统一内容／预览、Provider 多科室配置及诊断读取分别有实施与验收门禁。已有模板渲染、单一 Specialty 和打印事件不能作为新增能力完成证据。工程接口、迁移建议和执行顺序唯一见实施计划；本地完整链验证、PRD 发布、Git 交付、应用部署、STG 与 UAT 分别报告。

可配置付款方式与保留欠款（2026-10-22 用户确认）

付款入口增加 Delay payment、On doctor account、Deposit，它们的会计含义固定，不能以修改名称把应收或预付款改成新现金实收。

• Delay payment： 明确选择延后付款后，可以整笔欠款，也可以与本次部分实收组合。保留原发票、未付金额、原因、可选到期日、确认人／时间和诊所跟进责任；未收金额不生成实际 Payment／Receipt。后续从 Billing History 对原发票补收，原欠款安排及每次收款历史继续留存。
• On doctor account（2026-10-23 修正）： 属于下方 Payment method，不属于付款来源／保险责任选择。自动使用本次 Visit 的 Doctor／Provider，不显示或接受其他 Responsible doctor。可承接全部或部分患者自付，并与现金、卡、Deposit 及明确的患者欠款组合；保险／企业承担金额不变。例如总额 1,000、保险承担 800、自付 200，选择 On doctor account 200 后分别保留保险应收 800 与本次医生应收 200，患者未付为 0，实际收款为 0。以稳定 Provider ID、冻结姓名和金额保存医生应收，未到账不生成 Payment／Receipt；无明确本次医生时阻断该方式。Billing History 对原发票分别补收患者、保险／企业及医生款项，各自不得超过余额；同名医生不合并责任，名称匹配 remittance 不抵扣医生余额。历史发票仍按原有冻结责任读取，不批量改写旧记录。
• Deposit： 只使用该集团内当前患者、相同币种的已有预付款余额，余额不足则整个确认失败，发票、收款与余额同时回滚。付款确认在原发票记为预付款抵扣，并追加账户扣减流水；保留抵扣凭据、金额、余额、原发票、操作者和时间。退回原 Deposit payment 时资金原路恢复患者预付款账户，追加退款流水，不能变成外部现金退款。普通 payment-method correction 不允许将 Deposit 与外部实收互相转换。重复提交、重复退款请求不会重复扣减或恢复。

Deposit 余额读取（2026-11-02 用户确认）： 护士在其有权访问的患者范围内，凭现有 Cashier 读取资格查看币种及可用余额；套餐患者面板不再额外要求套餐财务读取权。查看不会创建账户、改写余额或开放退款、成本和分摊明细。收取／抵扣、退款／冲正继续分别校验原权限，完整边界见 Platform 套餐账户与交易权限。

Apply deposit／抵扣已有预付款 使用上述患者通用账户余额，独立于 Collect deposit／收取新预付款。预付款账户不会根据旧 Package entitlement、欠款或现有发票推算余额。迁移已有预付款时，仅具有 admin.workflow.configure 的人员可按患者一次性导入已对账的原始余额，必须提供来源凭据和原因；该导入不代表本次新到账，不进入实收日报。账户已有任何流水后不能重复导入或覆盖开账余额；不提供任意余额覆盖。2026-10-26 确认新增真实 Deposit 收款：在独立 Collect deposit 区录入实际外部付款方式、正数金额和非现金凭据，存入同集团、同患者、同币种通用余额，可在后续其他 Visit／项目按既有权限抵扣，不绑定当前药品或发票。新增 Deposit 不支付本次所选项目、不生成服务发票或医疗收入，也不能以 Deposit、Delay payment 或 Doctor account 自我充值。与本次结算在同一最终确认内原子保存；本次新增资金不隐式充当同一请求的既有余额。

System Settings → Payment methods 为主设置入口；具备 Cashier 访问资格的管理人员也可从其右上角 Settings → Payment methods 进入同一配置。系统管理员在有效 Back Office 岗位进入后，须明确选择其管理范围内的目标诊所；诊所管理人员的 Cashier 快捷入口默认本诊所。配置可用方式、显示名称和停用状态，并可新增实际外部收款方式；设置读取允许现有 Cashier 读取或系统配置权限；写入须有 admin.workflow.configure 管理权限，不为普通收银人员扩大管理权限。目标诊所须属于当前医疗集团且处于有效状态；跨单位配置另核验现有管理责任，普通收银身份不能通过目标 ID 读取或改动其他诊所。方式代码与处理类型固定，已有方式通过停用保留，不删除后复用代码；保存使用版本校验并重新读取确认。历史 Invoice、Payment／Receipt 和 remittance 保留当时的方式名称快照，之后改名／停用不改写历史。新付款提交在服务端重验当前启用状态；历史退款继续按原始资金类型处理。

新 Deposit 每笔生成独立 DPT 收据及账户 collection 流水，保留冻结患者／诊所／Visit、实际方式、金额、凭据、操作者及时间，可从 Deposit 流水打印。开账导入与真实收款明确区分。最终确认分别展示账单支付、新增 Deposit、已有 Deposit 抵扣、外部实收、患者欠款及暂不处理项目；超时重试沿用原请求，不重复入账。

真实 Deposit 收款进入收款日 Day-end 与 Business Report 的实收及付款方式汇总，独立标明 Deposit collection，不计入开票收入；之后抵扣不重复计入实收。Deposit 抵扣和余额恢复减少／恢复已有资金负债，不是新增外部资金：Day-end 与 Business Report 的实收、现金退款和 net collections 均排除这些移动；发票结清额、应收余额和开票收入仍按实际账务记录计算。界面同时说明本次外部实收、Deposit applied 和剩余欠款，不能用“实收零”掩盖已使用预付款。

来源：2026-10-22 本轮修改请求第 4 项及 2026-10-23 用户对 Payment method、本次医生固定归属、持卡条件与 Cashier 可修改 check-in 付款安排的明确修正。实现与本地验证证据、PRD 发布及 STG 状态分别记录，不因本规范更新视为上线。

4.2 历史纠正

历史检索（2026-10-17，I-063）： Billing history 保留在 Cashier 顶部导航并显示历史图标；按发票建立日期（香港时区）提供 Today／Last 7 days／Last 30 days，均包含今天。日期快捷操作保留当前搜索词与账单状态并回第一页；Reset filters 清除搜索词、状态和起止日期，不改变当前诊所／区域及权限范围。页面明确显示时间范围与作用范围；开始日期不得晚于结束日期。

尚未完成 Checkout 的就诊，若结算被退款更正撤销，剩余款项必须回原 Checkout 复核当前费用及药房状态后统一结算。Billing History 显示原因及 Open checkout 入口，不提供会被后端拒绝的独立补收按钮。仍有效的付款安排可以从原 Invoice 登记患者补缴或第三方回款，即使当场 Checkout 尚未完成；Checkout Completed／Closed 后的历史应收继续在 History 办理。患者金额已补足时，Checkout 明确提示重新确认原结算，不再要求新增付款或误称第三方安排。退款更正撤销结算时，原欠款记录保留但不自动重新授权放行；回 Checkout 重新安排欠款须再次明确确认。History 的既有重新确认路径仍要求先补足患者责任。

历史应收保留原 Visit 关联，即使 Visit 已 Closed 仍可登记实际到账；不重开临床记录。Checkout Completed 后、取药前如付款纠正撤销了结算，补足患者责任后可从原账单明确重新确认结算；必须仍是同一处方／费用版本及有效预留，不新增付款、不改变 Checkout 状态。Closed 不允许此药房重新放行，只可处理历史财务应收。每项付款方的补收不超过其剩余责任，第三方应收不显示为已到账。Void 仅适用于无付款的草稿／已过账发票，退款不通过删除或改写 Payment 完成。

已在外部完成的退款，必须记录原 Payment、金额、原因和凭据。Payment correction 保留原收费，退款金额重新成为应收并撤销原结算放行；Service refund 生成独立 Credit Note 冲减应收，原 Invoice 金额不变。当前服务退款只支持患者责任部分；第三方 Credit 分摊、正式审批流与在线退钱仍待实现。有未完成或已供药品时须同时留下人工药房／库存处理记录；Credit Note 必须明确确认签署处方仍有效，不能以财务冲减代替取消药品，系统不会自动退库。药房最终交付仍要求有真实授权的另一位 Pharmacy Checker 完成实物复核；单人／紧急例外在重新认证及审批流程完善前不可使用。

4.3 结账界面：阶段、金额与票据入口

付款确认弹窗分别显示本次账单付款及其实际付款方式、新收 Deposit 及其实际收款方式／参考号、既有 Deposit 抵扣、患者欠款和第三方责任；外部实收总额只汇总新增收款。Deposit 流水金额与余额统一两位小数，时间按界面格式显示，独立收据在对应流水提供 Print receipt。Deposit 余额作为金额信息独立展示，通过紧凑的 View history／Hide history 按钮展开或收起流水；不使用整行输入框式折叠栏。键盘焦点提示限定在按钮上，余额区与新增收款按钮保留间距，窄窗允许换行。本项呈现调整不改变账务规则。

信息承接与票据入口： 费用、Visit 本次计划、已核对付款责任、实际收款和欠款沿用同一上下文，阶段变化不重新填写同一信息；确认失效及草稿保留见 IN-05–07。结算前集中复核费用、责任与本次付款／欠款，不重复展示 Invoice 模板、预览或打印区。结算已确认后提供一个 Print invoice 入口，在统一打印窗口选择用途、模板、内容及医生科室并预览后打印（实现、Git 与目标运行证据见该节，业务 UAT 单列）；实收结清、零金额、保险及患者欠款安排确认均适用，不要求全部应收到账。Receipt 仍关联真实付款；模板／账务快照和每次打印记录的唯一规则见 票据与重试。历史操作及模板管理仍在 Billing History 和 Settings，不在当前 Checkout 复制。

患者入口与 follow-up 安排： 单患者付款详情在独立 Follow-up arrangements 板块提供 Book follow-up；仅当前患者实际保存有保险卡并具备相应读取权限时显示只读 Check Policy，无卡不显示。Policy 沿用患者保险卡／关联 Policy 查看器，优先展示当前选中的患者保险卡，其次展示已保存卡片并可选择其他已保存卡片；自费患者也可查看已保存卡片，查看本身不更改本次付款来源或责任。Book follow-up 仅向具备预约创建权限的用户开放，带入当前患者并打开既有预约日历；沿用预约时段、医生、服务地点、冲突及保存校验，成功保存后关联来源 Visit，取消编辑不创建预约，不改动收款草稿、处方或本次就诊状态。 普通复诊沿 Frontoffice 统一问诊规则，Calendar 手动复诊与问诊完成后的自动复诊均不再区分 GP／SP。

Calendar Reminder 交接： Cashier 来源预约保存成功后刷新后续安排摘要，由下方统一协调流程集中提供 Reminder；独立 Calendar 预约保留成功后的快捷提醒。仅当前有权护理岗位可操作统一卡片式 Reminder 弹窗；医生及其他非护理岗位不显示手动或自动跟进入口。检测入口在 Cashier 本轮处理成功确认后展示，包括零实收、下次付款或本次暂不处理的安排保存成功；这是触发时机，不是付款资格门槛。候选取本次 Visit 已保存且仍需跟进的检测，不限已付款／已开票行，覆盖未付款下次再付、本次暂不处理、保险／企业／月结。只收 Deposit 时也按是否有真实待跟进检测判断，不凭 Deposit 虚构项目。未提交／失败不自动弹出，但已保存检测可从来源手动设置；提醒不改变原结算、欠款及检测执行门禁。来源付款详情支持稍后补建；同一 Visit、患者及责任诊所的获授权后续预约和检测在同一弹窗以卡片集中安排，各自保留真实来源、时间和独立提醒，已有提醒及后续补收去重。Reminder 保存／失败独立于已成功的账务事务，不增加收费门禁。预约、检测与未预约针次跟进的字段、批量、状态、权限、来源变化及 REM 验收条件唯一见 Frontoffice §4.7。用户随后授权本地实现及预览；实际验证与边界见 专项记录。

Invoice 区历史入口（2026-11-03 用户确认）： 普通已结清且未关联 Deposit 的就诊不显示 Billing history 按钮；存在患者、医生或第三方未结欠款，或当前就诊实际收取／抵扣过 Deposit 时显示。按真实当前欠款与本次就诊关联判断，不以历史欠款备注、原第三方金额或患者其他就诊的 Deposit 余额判断。Deposit 板块的 View history 保留，Print invoice／Print receipt 和独立 Billing History 工作区权限不变。

Follow-up arrangements（2026-11-02 已确认并本地实现）： 2026-11-03 更新：本组操作的原因／补充说明全部选填，留空不阻止提交；稍后联系仍必须有有效联系日及责任人／团队，处理结果与操作审计继续必需。单患者 Cashier 增加持续可见的独立板块，展示医生交接选择、实际预约与护士处理结果。进入详情即可查看，确认本次收费／付款安排后突出未处理事项；“结完账”包含延期、保险／月结、defer 及零实收安排保存成功，不要求全额付清。

• 已有预约： 展示来源 Visit 显式关联的真实预约，提供查看；仅 Booked／Confirmed 预约提供调整和有权限时取消，已取消／已完成仅查看，不默认重复新增；过期、取消及来源异常必须如实显示，不能因为查不到未来预约就推断无需 follow-up。
• 待护士确认： Check follow-up with nurse 且尚未处理时提供 Book follow-up、Arrange later、Patient declines。必须落实处理结果，不要求病人必须预约。
• 稍后联系： 保存下次联系日期及合资格护士／明确的诊所护理团队责任，并成功建立关联待安排 Reminder，才算本次交接已处理；关闭弹窗不算完成。
• 病人拒绝： 未预约时记录 Patient declines，原因选填并保留操作人、时间和原医生交接。提示“医生已交接 follow-up 安排。病人目前选择不安排，原因可选填。此操作会保留医生原始交接记录。”病人之后改变意愿可重新安排，历史不覆盖。
• 已有预约取消： 使用 Cancel follow-up appointment，显示具体预约及受影响提醒，原因选填并通过原预约权限／状态校验；取消失败保留原结果，不把尚未预约的拒绝写成取消。取消复诊不取消 Lab／Imaging 安排。
• No follow-up： 中性显示医生选择，仍提供有权护士主动预约入口，不强制额外处理记录，也不将该选择作为病人拒绝。

统一顺序为：核对交接与已有预约 → 确认本次收费／付款安排 → 处理 follow-up → 集中设置真实来源的统一 Reminder → 完成 Checkout。可提前预约；由 Cashier 发起的预约保存返回安排摘要，避免每步自动弹出提醒；独立 Calendar 预约的快捷入口保留。付款结果未知后查询确认成功，复用正常成功的后续入口，不再次收款。已跳过提醒来源在新来源出现时保持未选且可恢复；没有 follow-up、只有检测时独立设置检测提醒。

新契约下未处理的 Check follow-up with nurse 在 Complete checkout 前由服务端要求处理结果；已预约、已保存稍后联系或病人明确拒绝均可满足此项。原财务与交接条件继续独立校验；提醒跳过不等于病人拒绝。后续操作失败不能撤销成功收款或重新签署问诊。既有预约被取消后按真实取消结果／后续选择记录，不永久解释为无需复诊；旧记录与已完成 Checkout 不追溯阻塞。

状态读取失败在本板块显示错误与 Retry，保留付款成功事实；切换患者／Visit 后清除旧上下文。Next contact 只显示仍有效的稍后联系安排及其 pending Reminder，已结束记录保留历史入口。状态／接口与迁移见实施方案，实际验证及 Git／运行边界见交接专项。不改变预约／Reminder 权限，不给仅收费岗位额外护理权限。

2026-10-27 已确认： Checkout Queue 移除 Print FU label 按钮，操作列保留 Open 及有权限时的附件图标。此决定取代 2026-10-23 的队列 FU 打印入口要求。单患者详情 Book follow-up、已保存的来源 Visit／follow-up 关联、Calendar／Registration 的 Print label 及其患者电话字段继续保留；通用标签规则见 Frontoffice。

列表遵循 共享列表规范，以 Registration Queue 为参考。三个工作入口采用紧凑的顶部切换，移除旧式常驻左侧模块栏；使用与 Consultation 一致的页面标题、搜索工具栏、患者／Visit 信息层级、状态标签及表格密度。收费明细占用可用宽度，数量、单价、折扣和净额对齐；1280px 和 1366×768 下关键金额及主要操作必须可见。表格和录入仍复用 Element Plus 与桌面共享组件，不复制 Consultation 中尚未迁移的旧原生控件。

Cashier 对齐 Drug Dispensing 的视觉层级：患者／历史发票使用共享深蓝信息栏；主要分区复用带中性图标的 WorkspaceSectionHeader，白色内容区配合清楚的分隔、18px 标题及14px 表格内容；顶部入口使用紧凑的选中态。Checkout、Billing History、票据版式编辑及弹窗保持一致，次级字段与说明不与主标题争夺注意力。费用／付款状态、金额和单一主要操作仍遵循下表。

进入 Checkout 后，患者／Chit 与签署身份位于头部，正文按以下顺序组织：

1. Payment list：一张表同时展示收费与付款责任，不再重复一个 Payer Split 明细表。项目身份固定在左侧，窄窗允许金额列在表内滚动；原价、数量、当前折扣、净额、逐项 Patient Co-pay 和 Third party 清楚对应。当前未开票项目共用付款来源及已核验计划；Insurance 未编辑的 Co-pay 默认 0，表示本项全额由保险承担；员工仍须核对保险资格、预授权及患者／第三方责任。手动清空输入保持待填写，不能转换成 0。
2. Collect payment：默认一行方式、金额、参考编号；需要时 Add payment method。方式不自动推断，非现金必须有凭据；本次付款合计与当前患者应付分别展示。输入合计低于应付时自动出现剩余欠款、跟进分类、独立备注、可选约定日期及确认框，不再先选择 Pay in full／Outstanding 或另一层 partial 开关。
3. 确认结果与凭据：成功后显示真实已收、患者欠款及第三方应收；原发票、逐笔 Receipt、Billing History 与检验交接结果继续可查。未就绪项目留在原清单，之后只处理剩余适用费用。
4. 固定底部动作：显示本次收款金额和 Confirm payment。复核弹窗一次确认当前所选项目及独立新 Deposit；所选项目全部结算且其余明确暂不处理后可 Complete checkout，最终交接单独确认。

折扣按 §3.1 在收费行内直接联动修改折扣率／折扣金额／净额；保存前显示原／新值、原因分类、已填备注及旧未付票作废影响。保存后保留各项 Co-pay、实际付款输入及欠款说明，撤销旧责任／欠款确认；Co-pay 超出新净额时阻止提交并定位该行。已开票未付账单被折扣作废时，同时保留其付款来源和逐项分摊；多个重新打开账单的付款方与当前输入不一致时，保留逐项金额并要求明确选择付款来源，不静默改成全自费。

已结算的收费组或已完成 Checkout 的清单不再显示“Encounter is not Ready for Cashier”作为待办阻断；其他费用、版本或权限阻断仍按真实结果显示，付款及离院资格继续由服务端判断。

已载入清单的后台资料刷新不短暂禁用同一页面的下一步按钮；实际版本变化仍撤销过期复核，写入、未知结果和主动刷新期间继续执行原保护。

付款方式在确认及已收记录中使用可读名称；关闭确认弹窗的过渡期间保留原操作内容，不闪成离院或退回问诊说明，也不得触发已关闭操作。未保存输入在返回队列、切换工作入口／Visit、关闭窗口前须继续编辑或明确放弃；进行中写操作及 §4.1 的结果未知恢复期间禁止切换，不能通过放弃草稿解除已提交命令的保护。定时刷新且来源／账务版本未变时，保留输入和正在确认的对话框；真实费用、资格、门禁、余额或结算状态变化时保留可复核输入并撤销旧确认。整单版本包含全部显示范围，不能只检查某一个组而忽略另一组变化。

最终 Checkout 判定： 服务端逐个有效费用组核对本组当前有效发票、该组收费版本和 Settlement confirmed，不能把药品结算版本与所选检验组费用版本比较，也不能用另一组结算填补当前组缺失状态。经校验确实没有费用来源的组不产生阻断；来源版本缺失、失效或无法计算不能当作空组跳过。有收费来源但净额为 0 的组仍须显式零额结算。仅有检验、仅有其余费用，以及两组分别或合并结算，均使用同一判定。统一清单的最终 Checkout 判断覆盖全部适用费用组。完成动作仍要求既有交接确认，重试不重复改变状态。后端返回逐组阻断及下一步，界面不把总括错误留到最后点击才出现。

页面从患者、合并收费与逐项分摊、本次混合收款，到结算及离院交接连续组织。每项状态持续可见；检验结算成功不冒充药品已结算、已备药／发药或报告完成。

患者已付使用患者实际付款口径，不将保险／企业到账混入患者余额计算；发生 Credit 时原 Invoice 总额保留，调整后金额作为当前费用口径并解释差额。确认开票／收款弹窗也应突出待确认金额、患者及付款责任，不能把关键金额埋在长段落中。

4.4 套餐销售、启用与本次服务覆盖

套餐定义、患者多账户及查询入口唯一见 Catalogue §7.1。2026-10-28 已确认新套餐销售走 Cashier Invoice／Payment；2026-11-01 用户补充确认：经 Cashier 确认结算或付款安排后即可使用，允许未付清，原欠款继续保留。

• 正式首次结算同事务检查套餐总限额、本销售诊所限额及当前销售资格；成功后只计一次，超额或范围失效时付款与账户启用整体回滚。跨版本累计，退款不返还销售名额；eshop 登记不占限额，唯一规则见 Catalogue §7.1。
• 任选组覆盖须指明实际候选服务；Service 意向／Cashier 套用提议不占名额，确认预约或结算才绑定并校验同组重复。每个名额沿购买快照固定分摊，组内不补差价；原生 Lab／疫苗须实际执行后核销，不能手工代替。
• 本次 Consultation → Services 发起销售，自动关联当前患者、Visit、套餐购买版本和收款上下文；Cashier 在临床交接后处理，开票前移除待售项目不产生收款或已启用权益。Cashier 按真实实收、Deposit 抵扣、合法零额或明确欠款安排确认后启用。账户可用不等于资金已付清，不接受客户端 Paid 字段替代实际交易。
• 同次购买并使用时，先完成套餐购买结算／付款安排并激活权益，再确认本次抵扣；购买未成功前诊金仍按未覆盖处理。覆盖后不重复收取同一诊金，关联的购买 Invoice、服务 Invoice 及原生来源保持可追溯。问诊权益仅在本次原生问诊完成签署和有效本次结算共同满足后幂等扣一次，单独保存意向、签署或购买激活均不够。
• 保留原购买 Invoice、患者付款、第三方责任和欠款。后续使用套餐不再次收取原套餐购买款，不把原欠款复制到每次使用 Visit；补缴回到原购买账单办理。
• 本次付款清单直接呈现每项服务的套餐意向、具体患者账户／权益名额、覆盖金额和剩余应收。收银人员在主清单确认使用、更换符合条件的权益，或明确撤销意向恢复普通收费；未处理意向阻挡对应项目结账，不将未打开套餐详情视作同意自费。医生未预选时，可为已有收费来源选择匹配权益；新增或改变临床服务仍回临床流程。独立已就绪项目可沿现有规则结算，暂不处理不等于取消套餐意向。
• 套餐抵扣展示（2026-11-11 用户确认）： 付款清单按患者套餐账户显示紧凑分组卡片，套餐名称及账户编号只在卡片头展示；相同服务及相同购买组件条件的权益合并为一行，不同服务分行，不以内部权益 ID 作为日常选择标签。每行使用整数“本次使用”数量控件，支持同服务多次选择并可减至 0；显示符合条件的次数与本次最多可用次数。系统将数量分配到具体可用权益和不重复的完整收费来源，保留已选名额及来源关联；数量不得超过当前可匹配的独立服务次数，不能将同一收费重复抵扣或在 Cashier 新增临床服务。单条收费的数量与套餐单次映射数量仍须一致，不将一条汇总收费自动拆成多次服务。不同购买账户、购买组件或限制条件不混并；任选服务分行但共用同一名额池，原不允许重复的选项最多使用一次。已选卡片显示选择状态，区块显示所选总次数及覆盖金额；最终结算仍逐项冻结权益、来源和金额，现有权限、占用、核销与更正边界不变。
• 确认选择在最终结算前仅为提议，不占用名额。最终提交同事务重验来源版本、资格和可用次数，冻结发票明细的账户／权益／覆盖金额，记录实收及结算并占用权益；失败整体回滚，重放不重复收款、开票或占用。全部覆盖也须明确零额结算。套餐覆盖不是外部 Payment，不把分摊价值变成 Deposit；同一费用不得重复覆盖。
• 已 Post 来源不得直接新增、替换或清除套餐覆盖，须走既有受控财务更正；结算占用须与发票明细冻结的覆盖事实一致。取消未结算覆盖只撤销本次收费关联，合法预约预留继续保留；已结算或执行的释放沿原受控流程。
• 同次新购与使用在同一 Cashier 页面按两次明确确认连续办理：先购买结算／付款安排并启用，再刷新本次预选权益并确认服务覆盖／结算。购买未成功时相关服务保持待处理；购买已成功而服务结算失败时保留原购买结果，恢复后继续服务结算，不重复收套餐款。
• 确认覆盖时保存具体权益、当前收费来源／版本、发票明细和结算关联，并原子占用，不能仅将费用设为零而丢失套餐来源。真实服务发生后才按对应触发节点核销；疫苗以实际 administered 为准，付款、供药和接种分别记录。
• 新销售入口必须沿用当前 Consultation／Visit 的真实临床来源；每笔套餐购买为独立资金交易，可由明确标记的 billing-only／仅收款记录承接原 Invoice 约束，并保留来源 Visit 关联，不生成新的医生、临床签到或临床完成事实。临床队列、病历就诊时间线及到诊统计须排除该记录，临床写入拒绝；Billing History 与真实收款报表按原交易保留。每份套餐销售对应独立 package_sale 来源和 Invoice，原付款归属不能从混合账单推测。
• 新销售实收、后续服务使用／收入触发、退款／Credit 和未收应收分别记录；不重复统计外部资金，不由本轮方案自动制定新的会计、税费或保险分摊政策。

外部已购的原有效期、剩余次数与历史选项沿 Catalogue §7.1，登记不产生本地购买款或收入，不由 Cashier 补造付款。2026-11-03 问诊销售与同次先购后用已通过列明的完整本地服务链及官方 Chrome 流程；实际先收套餐价、后抵扣诊金及扣次结果见 GP／SP 专项证据，Git／STG、目标应用部署与 UAT 单独验证。

未结算销售可受控作废并关闭待启用权益；已启用账户不得用普通 Void 跳过套餐退款／纠错。后续本次服务先保存使用提议，Cashier 根据当前收费版本确认并同事务占用；撤销有效结算且未执行后才受控释放。旧独立 reserve／consume／reverse 写入口关闭，不允许绕过执行来源或恢复已退款权益。 原生接种／Lab 记录被真实撤错或报告全部撤回时，可由具原执行更正资格者预览并明确确认受控纠错，校验当前源版本、权益版本、有效结算及后续资金记录；保留原执行／收入历史并追加对应反向事件，先回结算占用，不直接恢复可花用次数。有效执行、退款冻结／已退／已终止或后续资金冲突均阻止；若需释放占用，再走原结算受控撤销。普通服务完成记录只能有原因地修订时间／证据，不以更正另扣一次。代码、迁移、完整链验证及目标环境状态见专项证据。

5. 保险与企业计划

功能目的： 将本次保障资料转为明确付款责任，并追踪后续回款。

使用者与对象： Billing & Insurance／Cashier；Visit 计划快照、付款分摊及 Remittance。

操作与结果： 承接人工核验 → 复核责任与 CoPay → 开票结算 → 实际到账后分配并冲抵对应应收。

关键边界： 有卡、人工资格确认、第三方责任和实际到账分别记录，不互相替代。

2026-10-28 用户确认暂时隐藏 Cashier 的 Doctor insurance support 板块，并暂停该项前后端保险结账拦截；不再要求先有 Supported 或有效 Exception approved 才能建立保险付款责任。保险资格、有效期、预授权、逐项 Co-pay 及付款责任审核继续独立执行。共享规则、例外申请／审核与历史证据保留，待审申请不自动通过；暂停期间新发票记录未执行此门禁，不生成支持／批准结果，历史发票原快照不改写。恢复启用后，Cashier 重新显示自动结果和本次例外，结账服务端在同一事务核验并冻结证据；普通收款权限仍不能自行确认例外。完整契约见共享规则与本次例外。

5.0 本次付款责任、CoPay 与 Outstanding Payment

来源：2026-09-10 确认保险全额／CoPay、部分或全部欠款及后续补缴；2026-10-16 确认 CoPay 下沉至每条收费明细，护士直接填写患者承担，医疗卡承担自动计算；实际收款汇总并支持混合方式。2026-10-17 进一步确认统一清单、逐项直接设置 Co-pay、自动部分欠款及一次确认，不建设任意勾选项目付款。实现、测试、部署状态另见 WS5 与专项证据。

IN-05 连贯选择（2026-10-24 修正）： Cashier 的 Payment arrangement 统一使用下拉选项框，只提供 Insurance、Self-pay 两种，不使用 tab／分段按钮，不提供企业福利、员工福利或 Other payer 作为新选择。具有 Cashier 收款及患者卡维护权限时，即使尚无保险卡，也可先选择 Insurance 并新增；不具维护权限且没有已保存保险卡时，Insurance 不可选并提示尚无持卡。未保存卡片或未完成本次审核均不能确认保险付款；Policy 入口仍按实际保险卡及权限显示。check-in／Prepare 的付款安排只是初始值，确认当前未冻结账项前可从保险改为自费，也可选择患者名下另一张保险卡；有卡不等于自动使用保险。旧企业／福利记录保留原快照及历史账务，未开票项目须明确选择当前支持的付款安排，不静默转换责任。上方安排决定患者与保险各承担多少；下方 Payment method 决定患者部分采用现金、卡、On doctor account、Deposit 或延期付款，可拆成多行。例如 Self-pay 480 可拆为本次现金 180、医生账户 300；保险账单的患者 Co-pay 也使用同一混合付款区域。换卡重新核对有效期、资格及预授权，旧卡审核不能套用新卡；审核人／时间由服务端记录，卡片必须属于当前患者，不能仅输入机构名称构造保险责任。确认前可反复修改付款方式，确认时与发票、实际收款、应收分配同事务保存。保留原 check-in 快照，另存 Cashier 最终选择及发票冻结依据；已确认发票通过 §4.2 受控更正处理。页面刷新收到新发票、责任金额、实收余额或结算状态时，旧确认及待提交确认框失效；账务状态未变时保留未提交草稿。

保险卡选择与维护（2026-10-24 确认）： 选择 Insurance 后，在 Payment arrangement 旁显示患者保险卡下拉框，列出当前患者已有保险卡；具维护权限者可选择 Edit selected card 维护已选卡，下拉最后一项固定为 Add insurance card。新增／维护均打开弹窗，复用患者卡的计划、会员编号、有效期校验和查重；新增目录限 Insurance，不将企业／员工福利转为保险。保存绑定当前 Cashier Visit 和患者，要求当前有效收款及患者资料维护权限，拒绝其他诊所／患者、已离开 Cashier 或导入历史记录；已成功请求可按同一键重试，编辑使用版本基线防止覆盖他人更新。保存后刷新卡列表、选中已保存卡并清除旧资格／预授权及付款责任确认，保留其他未提交的金额、Co-pay 和折扣输入。取消／关闭未保存草稿须确认，不能新增卡或更改原选择；保存结果未知时保持弹窗并重试原请求。卡片保存只维护患者卡，不自动修改原 check-in／Prepare 快照或历史发票；本次卡片与责任在重新人工审核并确认付款后才冻结保存。已有账单不阻止维护卡资料，但已冻结责任仍按受控更正规则处理。

逐项 CoPay（2026-10-23 支持比例）： 选择 Insurance 后，每项同时显示患者 Co-pay 比例和金额，可任意修改其中之一并联动另一项。比例为患者承担比例，范围 0–100%，最多四位小数；按该行折后净额计算并四舍五入到分，保险承担始终等于净额减患者金额。直接修改金额时反算比例，最多显示四位小数；输入比例时保留输入值，避免金额取整导致比例跳变。空白、越界或精度不符不能当作零，阻止确认。零净额的患者金额为零，反算比例显示零。调整比例或金额都撤销旧责任确认；折扣调整保留已填患者金额并反算新比例，不自动按旧比例改变患者责任。覆盖诊金、每种药品、每项检验及其他有效收费行，不能只按诊金／药费分类或只录整单第三方金额。每项输入的是整行患者承担，含该行全部数量，精确到分且介于 0 与折后应收之间；空白表示未确认，不自动转成 0。患者承担 0 为该项全第三方，等于净额为该项全自付，其余为部分承担；同一账单允许混合。全部明细恰好均为患者全付或第三方全付时，仍保留已明确选择的 CoPay、付款方及核验来源，不强制改换模式；非自费来源继续要求责任确认。Self-pay 自动逐行承担全部净额；Insurance 逐行填写患者比例或金额，不再增加 Full coverage／CoPay 的整单模式选择。已有正式发票的模式与分摊保持冻结。净额为 0 与净额大于 0 但患者承担为 0 分别记录。

当前折扣变动后重新计算净额及第三方责任，保留患者已填金额供复核；超过新净额时定位该行要求修改。付款责任确认失效，必须重新确认。开票前服务端核对完整的当前收费行及版本；拒绝缺失／重复／未知行、非有限金额、负值和超出精度／净额的输入。Invoice 按行冻结来源、原金额、当前有效折扣及修订依据、原始签署与历史调整审计、患者及第三方分摊和付款方依据，汇总金额由服务端计算，不信任客户端整单合计。

例如原金额 500.00、当前折扣金额 70.00（14.00%），折后应收为 430.00；患者承担 80.00，医疗卡承担 350.00。患者承担汇总 300 时可以一次收 Cash 100＋Card 150＋FPS 50，无需把实际方式拆到每条费用。收费责任、已收金额及未收余额仍分开显示。

IN-06 实际方式： Cash／Card／FPS／Bank transfer 等实际付款方式只用于真实已收款。每笔输入金额、付款方与必要凭据；Other 必须留下可追踪说明。Delay payment / Outstanding Payment 选择映射为患者欠款安排，不能作为一笔付款方式伪造实收或 Receipt；Deposit 抵扣使用已有余额，依 §4.1 的专门资金分类与流水处理。一次确认可原子保存多笔实收与余款安排；任何失败全部回滚，同一请求重试不重复收款或登记。

IN-07 欠款确认： 本次录入实收小于患者应付时，自动显示原患者应付、本次实收、剩余患者欠款及第三方待收。按 §3.2 选择跟进分类，备注仅在 Other／其他安排时必填，约定付款日期保持可选，并主动确认患者欠款安排；本轮不新增强制日期、审批或个人任务分派。服务端根据当前账本和本次真实付款计算正数欠款金额，记录分类、员工原文、确认人、时间及原始安排；跟进行动由分类确定，责任固定为原 Visit 来源诊所，客户端不能改成任意员工或其他单位。此责任记录不代表系统已经创建任务、联系患者或完成催收。全额不付时不要求建立零元付款行。不得超收患者或第三方各自剩余责任，也不能以一方的到账掩盖另一方欠款。分类、必要备注或主动确认缺失时保留编辑并说明阻断原因。确认后修改、增加或删除本次收款行，会取消原欠款确认，必须按新的剩余欠款重新确认；历史安排按原文或已保存分类展示，不自动补写原因。

IN-08 后续补缴： 使用 Billing History 的 Outstanding 筛选定位原 Invoice，显示患者欠款和第三方待收两个余额；从原账单 Record payment 选择付款方、实际方式、金额与凭据，允许分次补缴。每次只冲抵所选付款方剩余责任，产生对应实际 Payment／Receipt，保留原安排和所有历史；患者付清不等于第三方到账，账单所有应收结清后才显示 Paid。Closed Visit 也可补缴，不重开临床或重发药。欠款确认本身不进入日报实收；补缴按实际发生日进入收款，不能再次累计原开票收入。

页面结构： 采用统一指南 §4的全宽对象工作区。同一清单完成费用及逐项付款责任复核，紧接本次付款／欠款录入，正式责任快照仍可查；底部固定一个当前主要操作，金额分层显示。本次全付、部分付、全部欠款沿用同一组输入，根据实际合计自动呈现必要安排；确认对话框复用 AppDialog。保留三个主入口和右上角 Settings，不把 Outstanding 或付款方式新增为主 Tab。

5.1 预约计划及人工审核结果

Checkout 患者上下文只读展示 Visit 保存的 Payment Arrangement 与计划名称。Insurance、企业或员工计划不自动设置第三方责任或金额；Cashier继续分别确认患者自付、第三方责任和实际收款方式。已有账单的 Visit 不允许从 Appointment／Registration 改写付款来源，需使用收费调整流程。未新增自动赔付／应收或资金通道。完整前置规则见 Frontoffice §4.3。

人工核验结果如何承接

本期 Appointment／Registration 使用人工审核确认按钮记录计划、资料变化、有效期、资格和预先申请结果，并由服务器记录审核人、时间与本次计划／日期范围。待核实、不合资格、申请待批阻断准备交接；旧 Checked 文案不构成通过证据。Cashier 仍需复核本次保障及付款责任，不将“人工确认”自动转换为保险公司承诺或企业应收；完整输入和状态规则见 Frontoffice §4.4。

5.2 资料和核验分工

IN-01／IN-02： 本期可人工核验并记录方式、人员、时间、结果和证据，不伪装保险公司实时答复。没有资料时不能默认成功，不能将上次预约 Case／Eligibility 自动复制成这次结论。

5.3 回款分配

IN-03： 登记保险实际到账金额及参考资料，选择一项或多项 Claim／Invoice 分配；允许部分分配并保留未分配余额。分配总额不得超过可分配到账额或对应可冲抵余额。误分配先撤销该分配，再建立正确分配，原 Invoice 和到账事实保留。

回款记录不等于电子 Claim、自动 Adjudication 或自动核赔。本期实现仍不完整，需单独端到端验收。

IN-04 已确认： 第三方未到账保留为该付款方的 AR；其回款等待不阻塞已按 BL-05确认的备药交接。结算条件只维护在 BL-05，患者欠款及补缴规则见 IN-05–08。

6. 退款、更正与关闭

BL-07： Invoice Void、退款及冲正需要原交易关联、权限、原因和审计。已付款或已发药的纠正需同时检查 Pharmacy、库存、Benefit／Package 的影响；不能删付款行或直接改签署处方掩盖事实。具体退款审批及差额执行沿用受控财务流程；本期已发药退换在药房人工处理并记录异常及结果，不自动退库或退款。

Return to Consultation（2026-10-22 用户确认）： Ready for Cashier 中未收款、未结算且未发药的药物／其他费用，即使仍为 Awaiting review、Pharmacy 从未退单，Cashier 也可直接退回问诊；不要求先存在 Pharmacy return。退回保留原因、旧签署版本、旧发票和释放预留的审计，未付款发票作废，医生更正后重新签署并再次审方。药房反馈只是一种可选原因来源，不是普通退回的前置条件。

独立 Lab 已付款不阻止未付款药品退回。退回及重新签署保留原 Lab 收费来源、金额、责任分配、Invoice、Receipt、Settlement 和执行 Handoff，不撤销、重复收费或重新创建检验。已成立的 Lab 项目不得借药品退回删除或更换实验室；重新签署改变了 Lab 收费事实时，保留更正阻断并提示处理原检验账务。

药品已收款时 Pharmacy 不能普通退单。由具现行退款权限的人员在 Cashier 原交易记录完成退款；尚有未退金额、未解决的第三方责任、已发药／正在送药或 Encounter 已完成／关闭时不能普通退回。对未交付药物且药物及其他费用组全部实收均已退款的就诊，Cashier 必须明确确认取消该组剩余应收后才能退回：原发票作废、原结算撤销、预留释放，并把作废发票关联至受控退回记录；旧收款、退款和签署版本始终保留。退款本身不自动重开处方，不自动退库，也不修改独立 Lab。之后新处方须重新签署、审方和结算，不能继承旧付款授权。部分退款、第三方／零额安排及已发药的差额改方继续走单独受控处理。

退款审批不得由 PRD 助手按行业惯例代替产品决定。 通用退款只确认上述原交易、权限、原因、审计和跨模块影响门禁；尚未明确的审批角色、分级、时限及例外仍待业务确认，不自动批准或推断审批人。套餐部分退款已有单独确认：沿现有 Cashier 退款权限，不增加独立审批或双人批准，按下方 §6.2 执行；不得用本段通用未决事项重新阻断已定套餐流程。

BL-08／CL-01： 完成当场结账并确认患者取药、检查、文档和后续安排后，才表示 Checkout Completed。满足临床签署、Checkout、付款／应收安排、即时 Handoff 接收及无阻断条件后，首次签署满 24 小时且不存在未完结待发药记录才自动 Closed；每晚必须在 System Settings 配置的 Nightly close window 内完成结算和报表准备，逾期进入异常清单但不改变 24 小时生命周期；待领取会暂缓关闭，AR 不阻塞，原记录不可重开。

现金盘点关账、Period Close、经营看板和完整财务核算不属于本期验收。诊所／医生 Day-end Revenue Report 按下节 2026-09-08 的明确要求实施。

独立 Administration Business Report V1按 2026-09-30 新增范围提供跨获授权诊所的经营分析，不改变本 Cashier 范围、单诊所访问限制或现金盘点关账边界。

6.1 Day-end Revenue Report

DE-01 目标与主体： 用户于 2026-09-08 明确要求诊所及医生层级的每日收入报告，查看总收入、收入来源及对应 chit；随后确认先依据底表代码构建，只保留新的数据，报表主体与病人无关。报表按当前诊所＋香港业务日期生成，可限定一位医生；不设置患者报表或患者筛选。chit 仅作为收入凭据的次级下钻。

DE-02 数据与范围： 读取新 Cashier 的正式发票、冻结费用行、逐笔 Payment、Refund 和 Credit Note，复用关联 Visit／Operating Unit 的有效会话范围校验；普通与 Assume 身份的责任归属规则见 §2。旧 MyPlatform 的 chic_chit、历史 eMR／Consultation metadata 账务不展示、不汇总，不建设旧新账本合并。All doctors 只表示当前角色与诊所／Center／Zone 授权范围内的全部医生；跨诊所需要切换已有授权上下文，不能用查询参数扩大权限。BackOffice 或无可查询 Zone 时按 §1.3 显示来源范围不可用，不返回收入汇总或可导出的报告，不把工作单位名称当成收入诊所。只有有效范围内成功查询到真实空结果时才显示零／空报告。不同币种分别统计，不换汇混加。

DE-03 收入与收款： 当日净收入＝当日过账发票金额－当日 Credit－当日已过账发票 Void。原过账金额保留，之后才发生的 Void 不从原报表日期抹除；草稿及从未过账的 Void 不算收入。Credit／Void 是独立调整，不虚构分摊到具体费用行。按冻结行的真实业务类别展示问诊、药品、检查／服务等开票来源；底表未区分的检查与服务继续合并，不猜分类。付款方式和付款方解释资金来源；Payment 按 paid_at、Refund 按发生日归入香港业务日。前日发票今日到账只增加今日实收，不再次增加今日开票额；零额结算、第三方安排、未到账 AR 不算实际收到的钱。净收款＝当日实收－当日退款，允许负数；一次 Service refund 同时产生退款现金事件和 Credit 收入事件，两者各计一次。当前调整后金额／未收余额必须标为 Current，不能冒充所选日期的历史日终余额。

DE-04 日期与医生： 数据库账务时间当前采用 Asia/Hong_Kong 本地 TIMESTAMP，业务日按 [00:00, 次日00:00) 查询，不再次加八小时。开票快照保存 Doctor ID 与姓名，后续 Visit 改派不改变原发票和关联收款／更正的收入归属；本轮之前缺 Doctor ID 快照的新系统账单回退当前 Visit 归属，不能声称已还原历史身份。Doctor ID 是稳定分组键，同名不同 ID 分开；无 ID 的姓名分组和 Unassigned 必须可解释。非法日期、医生或币种拒绝，合法无数据条件显示空结果。

DE-05 界面与追溯： 先显示报表主体、日期、币种、生成时间及收入／资金汇总，再显示业务来源和医生分组；底部账单记录是可展开的凭据，不把患者数量或患者列表作为报表重点。下钻复用新 Invoice、Visit、费用行及付款关联。Visit ID 与真实 Chit No. 分开，不用 V-<id> 冒充旧系统 Chit No.；本轮不显示旧系统历史报表。显示字段优先使用票据冻结快照，缺值不伪造。

DE-06 导出与安全： CSV 与打印来自当前已生成报告，保留筛选、生成时间及金额口径。修改日期／医生／诊所或角色后旧结果失效，禁止以旧数据导出新条件报表；异步旧请求不能覆盖新范围。CSV 正确转义逗号、引号、换行和公式起始字符，打印转义自由文本。真实后端失败不得自动用预览样例替代；公开预览使用明确标注的独立合成报告。

DE-07 权限与边界： 报告使用既有 billing.day_end.read，并与当前来源诊所／Center／Zone 及角色责任范围取交集；不因持有 billing.checkout 自动获得报告入口或全诊所数据。生成报告只读、禁用缓存，不执行日结关账、修改账务或新增 Finance 全集团权限。后台跨诊所授权继续按平台权限实施，不因报告界面或无范围提示出现而默认完成。

DE-08 验证： 至少覆盖多医生／同名医生、多收费行、拆分付款、零额／草稿／Void、跨日到账及退款、更正日期、币种隔离、香港日界、医生筛选、空结果、范围隔离及导出打印勾稽。底表与历史入口调查见 agent_docs/test_cases/cashier/day-end-source-readback-20260908.md；实际部署、测试及发布证据见 agent_docs/test_cases/cashier/day-end-validation-20260908.md。规则已确认，本轮实现与验证状态分别记录，不代表 STG／UAT 已验收。

6.2 套餐部分退款、权益终止与后续预约

eshop 人工登记账户没有 CMS 原收款，不能进入本地现金退款／Credit 流程，界面明确原购买渠道处理；参考分摊金额不是可退款实收。以下原 Payment 退款流程适用于有 CMS 原资金来源的现场购买账户。

2026-10-28 已确认首次接种 Visit 可进入套餐退款，原购买可能属于另一 Visit；2026-11-01 明确退款例外边界。各入口均定位同一患者套餐和原资金来源，不重开病历或迁移历史交易。患者套餐详情／原账单快捷入口的具体布局见补齐方案。

欠款与退款分别处理。 允许欠款使用不表示未收款可以退成现金；取消未使用服务也不自动消除原欠款。退款页面须显示实际退还、原欠款、已确认应收调整及待核实事项。没有可靠来源和已确认分摊规则时，不自动决定欠款减免、手续费、保险分摊或差额转 Deposit，保留原账本并转现有受控财务处理；实际退款登记与应收跟进状态分开呈现。

退款冻结／已退款服务不得继续使用原套餐授权。原服务 Invoice 经原有受控流程真实作废或结算撤销后，可解除未执行费用的原覆盖关联；权益及退款预留保持原状态，之后服务须按新的普通自费结算或其他合法授权处理，不能把解除关联当作恢复套餐。已执行服务继续受原事实及更正流程保护。

新套餐退款须与通用退款共用原 Payment 余额及预留约束，防止从另一入口超退。数量／金额原子处理、预约及执行并发、无原款历史迁移和验收计划见补齐方案。本轮已有受控命令实现，实际链路与未覆盖验收项见本地专项证据，目标环境部署及业务 UAT 另验。

7. Tasks & Notifications

7.1 用途与处理边界

统一中心承接各 App 中需要本人关注、审批、确认及跟进的事项。沿用 tasks-follow-up 入口，名称为 Tasks & Notifications／任務與消息。业务 App 保留原始记录、权限、工作流和完成依据；中心不创建第二份处方、结果或账单。诊后回访、Recall、转介、资料交付等继续作为人工跟进事项。

2026-10-17 用户批准第一版实施统一中心、人工任务及第一批来源接入，并要求使用现有模块的设计规范、图标和组件，完成本地完整服务链验证后展示实际页面与流程。简单审批／确认可在中心处理；处方修订、H5 身份审核、代编辑临床比对等进入原 App 的具体记录。所有动作重查当前权限及来源版本，沿用原业务服务与审计；普通“已读”或“完成任务”不能替代临床签署、付款、库存动作或原审批决定。

当前实施边界： 第一版代码已实现；本地完整链路验证结果和已知限制见 专项验证。尚未因此推定 STG 运行或 UAT 验收。Lab／WDL 自动业务来源、通用 SLA／升级、外部邮件／短信／WhatsApp 自动发送不在第一批；获授权 Lab／WDL 员工可使用人工任务。

7.2 个人入口、视图与阅读状态

中心默认汇总本人当前有效的同集团 Clinic、WDL、Lab 职责，提供单位、所属板块（Module）、业务状态（Status）、来源及搜索筛选，不要求先切换当前桌面工作单位才能发现事项。所有条件在服务端对全量获授权事项取交集，再统计、排序、分页；列表、计数和筛选范围采用同一授权依据，不能只筛选当前页。逐项标明来源单位。状态选项来自当前视图及其他筛选范围内实际可见的状态；所选状态暂时无匹配时保留条件并明确显示空结果，不自动扩大范围。条件变化回到第一页；切换四个页签时清除状态条件，保留其他筛选。来源中的共享处理事项只保留一条业务对象，可由原流程中有资格的人员处理；完成后其他人读取到相同结果，不借通用转派创造审批资格。

桌面首页的 App 图标与任务栏均通过角标显示真实待处理数；首页图标名称下不再重复显示“待处理／未读”数量文字（2026-10-17 用户确认）。消息未读使用独立标记及辅助提示，二者不相加。图标数字为本人全部获授权单位的当前待处理数，中心选择筛选条件后显示相应范围，不能把某一筛选页的数量当成全局角标。初次读取有加载提示；失败显示不可核实，不以零代替失败。打开并成功显示详情后只确认实际显示的来源版本已读；提交确认前来源再次更新时，新版本保持未读。列表加载不会全部已读。代编辑结果须与原工作台的阅读事实衔接。阅读不代表业务确认。失败时移除旧列表／动作，不能显示旧计数为正常结果。

“稍后提醒”只改变本人的提醒时间，不改业务截止时间、原任务状态或其他人的责任；任务到时重新进入待处理，独立个人提醒到时进入消息。详情显示提醒时间并可恢复。Assume 模式仅查看当前模拟职责可见的事项，不修改真实用户的阅读、关注、提醒或业务状态。身份／单位／授权变化使列表和迟到响应失效。

7.3 人工任务与个人提醒

本节个人 Reminder 只提醒本人；Calendar 护士跟进 Reminder为诊所护理范围独立患者业务提醒（本地实现及验证见专项记录），不改变本节接收范围，也不需在 Task 中重复完成。

2026-10-17 用户补充新建时应能选择类型，包含独立 Reminder。统一入口为 New item／新增事項，表单先选择 Task / Follow-up／任務／跟進 或 Reminder／提醒，默认任务。两种类型共享现有表单、单位选择及可选患者／Visit 关联；不把提醒包装成必须填写处理结果的任务。用户同日明确确认 Reminder 只提醒自己；指定其他接收人及重复提醒不在本轮范围。

任务常显“需要做什么、单位、负责人、重要程度”；补充说明、患者、相关就诊及提醒／截止时间按需展开。人工任务和个人提醒创建时可选 Normal／普通或 High priority／重要，默认普通，并保存到原事项及创建记录。来源任务沿用源记录的优先级，不因某种类型自动提升；原来源明确记录 Urgent 时可以显示紧急，缺少优先级时不猜测。此字段用于工作安排，不新增临床分诊、自动升级或 SLA。非患者事项无需患者资料。第一版表单可关联患者及其有权查看的 Visit，详情可打开该就诊；其他采购／财务业务对象尚未提供通用关联选择器。关联对象和负责人都须通过所选单位的当前授权。负责人使用稳定用户标识，不以显示名匹配。

个人提醒必填“提醒内容、工作单位、未来提醒时间”，接收人固定为本人，不要求负责人、截止时间或处理结果。补充说明及患者／Visit 可选，并继续核验所选单位及对象权限。保存后进入 Following 展示；尚未到时不增加 Action required 或 Notifications 未读计数，即使取消关注也能在 Following 找到未结束提醒。到时变为 Reminder due，进入 Notifications 并产生新的未读版本；提前查看不会吞掉到时提醒。每次延后后的再次到点也生成新的阅读版本，过期页面操作不能覆盖新状态。

个人提醒可查看、标记已读、稍后提醒及关闭。“稍后提醒”的时间须晚于当前有效提醒时间，列表与详情统一显示实际生效时间。查看或已读不会自动关闭；关闭无需处理结果，显示 Dismissed／已关闭提醒并进入 History，不记录为任务 Completed。提醒不提供任务的开始、转派、联络或完成动作，直接调用旧任务接口也不能绕过。第一版在中心及任务栏刷新时显示到点状态，沿用当前轮询和重新聚焦刷新；不宣称关闭应用后仍有操作系统、邮件或短信推送。

患者诊后任务继续满足 FU-01：患者、来源就诊、内容、负责人、状态、处理结果及必要关联可追溯；安排复诊创建新预约，不重新打开 Closed Encounter。暂不提供通用批量批准、自动 SLA 或未定义的升级流程。

7.4 第一批来源与结束依据

来源以原记录及版本去重；旧缺失单位或稳定负责人的任务只有在来源可证明时才回填，无法证明的记录不广播给任意用户。来源读取、动作、来源跳转均重新授权；旧缓存不能保持已撤销的权限。复杂操作携带原单位、患者／Visit、申请／提交／版本等定位信息，并遵守桌面已有的未保存内容保护。

7.5 页面与实现边界

复用 桌面 UI 设计规范：紧凑表格、四个页签、统一筛选、单个“查看”入口及详情区；窄窗口改为上下分区。人工任务和决定表单使用已有 AppDialog／Element Plus；图标来自现有 Iconify 注册表，颜色、状态 Tag、字体和间距沿用系统主题。详情保留最小必要上下文、来源动作及处理记录，不另造处方或收费编辑器。

2026-10-17 确认首页提醒、列表识别信息、操作层级及重要／逾期区分：

• 列表第一列为当前筛选与分页下的序号；标题下显示由来源及原记录 ID 生成的稳定编号，可搜索定位。序号随列表变化，稳定编号用于追踪，两者不混用。类型分为任务、提醒、审批、覆核，并直接显示所属 App 板块；来源细类、单位及实际负责人保持可查，不能只写一个泛化的 Task。
• 重要事项以醒目标签显示；有真实截止时间且当前仍未结束的事项，超过截止时间后显示红色“已逾期”及具体截止时间。没有截止时间不自动推断逾期，完成／取消等结束后不继续标为当前逾期。个人提醒到点是 Reminder due，不视为业务任务逾期。重要程度、处理状态和时间分别显示文字，颜色只作辅助；按用户后续确认采用 §7.2 的逾期及高优先级优先规则，同时间使用稳定来源键保证分页顺序一致，不修改原业务优先级或截止时间。
• 待处理视图给出当前筛选范围的逾期及重要数量，来源和计数与列表一致。个人延后不改真实截止时间；延后事项在 Following 仍可显示已逾期，但暂不计入 Action required 及其逾期数量。
• 详情只突出一个主要下一步；批准场景保留可见拒绝动作。记录联络、转派、取消及附属来源跳转收纳到“更多”，取消保留明确文字、分隔及原有必填原因。关注使用轻量状态操作；已读／未读和稍后提醒集中在“个人选项”，与业务完成分开。所有菜单沿用原权限、版本校验及确认表单，不能因收纳而取消原动作或保护。

第一版从权威业务表实时聚合并保存个人阅读／关注／提醒状态，通过打开、手动刷新、回到页面及定期刷新更新；没有宣称后台队列已经投递消息。异常来源返回明确失败，不能把读取失败解释成“没有待办”。技术实现与限制留在专项证据，产品完成只由相应业务状态判断。

8. 验收方式

BL／IN／FU 用例覆盖来源收费、审核门禁、分组及合并结算、药房同步、历史快照、回款错配及诊后任务；未完成的第三方 Credit 分摊、复杂回款、套餐及统一任务链保留各自未完成状态。不能以 Invoice 页面能打开作为 Cashier 整体通过。

2026-10-18 验收清单：原价／数量不可改、统一折扣率／折扣金额／净额三项联动及净额合计、调低／调高／清零、最后输入精度与越界拒绝、原临床签署和审计保留、所有收费类型逐项 CoPay、空白和零值区别、全自付／部分／全保障同单混合、金额精度与逐行守恒、混合付款及欠款、合并收款分配不重复、仅检验／仅药品／两组结算、从任意组完成 Checkout、旧版本与并发拒绝、重复请求不重复记账、交接失败重试、只读权限、历史票据及日报金额一致。

本轮新增契约需对照验证普通／Assume Doctor 的相同可见范围、稳定 owner 优先与仅 NULL 时的 provider 回退、越权详情／队列／历史拒绝、退出 Assume 恢复、Frontline 服务关系撤销、当前授权 DOB／性别、BackOffice 无范围与真实空结果区分、三类原因及 Other 必填／旧原文兼容、欠款可空日期与服务端责任诊所、付款／折扣结果未知时原命令恢复及切换保护。BL-09 原分步设计与现有直接退回实现的差异仍须业务对齐，不能把原因 UX 用例通过当作状态转换已获验收。使用隔离合成数据、本地完整服务链及 Docker 内官方完整 Chrome 留存截图／录像／trace；实际执行结果见专项证据，代码、本地、STG 与 UAT 分别报告。

统一票据打印验收（PRINT-01–08，2026-10-27 已确认）： 本轮本地覆盖、结果与限制见专项证据；以下仍作为业务验收口径，不代表线上或完整 UAT 已完成。