Catalogue、优惠与保险计划业务 PRD

更新：2026-10-21 · 责任：运营／Finance／保险管理／平台 · 详细底表设计保留在原 Catalogue 技术规格中

2026-09-07 角色与价格维护确认： Finance 需要查看并维护获授权的价格资料；Clinic 与 CP 的财务价格工作统一在后台 Finance 完成，不切换成 Clinic 角色。复用本 PRD 与 CP 各自的权威价格记录、生效及版本规则，不反写历史账单或采购快照；维护权限不能只配置为读取，也不自动扩大为所有主档或发布审批权限。Insurance 与 Billing 合并为 Billing & Insurance 团队入口。统一场景及权限契约见 组织与权限产品方案。当前 Finance 的目录初始化仅授予 catalogue.read／coupon.read，价格写权限仍待实施；场景入口已按平台实施边界章节 实现，不能以入口可见视作价格维护权限已交付。

功能地图

先区分“共享定义”“患者持有”“本次使用”“实际资金”四层，再阅读各主数据功能。

1. 管理边界与导航

本 PRD 维护相关主数据的既有唯一业务规范；对外入口分属 Catalogue、Insurance & Benefit Programmes 和 Packages & Coupons 三个 App，均属于 Business Operations。2026-09-09 用户确认：保险／企业／员工计划独立，不放 Catalogue；Coupon 与 Service Packages 放同一 App。

Catalogue 固定导航为 Lab & Imaging、Products、Service Items、Consultation Pricing、Change History & Controls；只维护共享服务、检查、非药品项目、价格及成本。打开即进入实际列表，不另设说明性 Overview，不嵌套保险、套餐、优惠或 Other Settings。患者个人卡号在 Patient & eMR；药品共享身份、单位、地点价格及来源库存见 Drug · WDL/CDU PRD，患者发药见 Drug Dispensing。不在普通 Products 内建立第二套药品主档。

Insurance & Benefit Programmes 承接 §6；Packages & Coupons 承接 §7。复杂 Benefit Contracts 后台仍不开放；既有有效企业／员工合同可作为卡种来源。入口及全局／个人／页面设置范围见App 与配置层级。

flowchart LR
  A[Programme 共享计划目录] --> B[Patient 患者持卡及个人编号]
  B --> C[Appointment 或 Visit 本次选择与核验]
  C --> D[Cashier 付款责任与应收]
  D --> E[Payment 实际到账与分配]
  P[Policy 或 Benefit Contract] --> A

目录更新影响后续选用；患者默认计划不自动成为本次选择，本次人工核验也不代表实际收款。各层保留自己的来源与历史快照。

2. 共用规则

MD-06： 新记录 Draft → 发布后 Active → 停用 Inactive。发布、停用及价格变更要求相应权限、原因和审计；本期不强制第二人审批。已用于交易的记录不物理删除；签署处方／医嘱、套餐购买、报价及 Invoice 保存当时项目与适用价格／规则快照。

List Price 是对患者的参考售价，Cost 是内部成本，不能用同一个字段混写。主数据更新只影响后续按规则取价，不自动改历史交易。

目录列表与选择器（本轮设计补充）： 管理列表默认 Active，显式切换 Draft／Inactive／All，不限制为当天；业务开单选择器仅返回在本次 Clinic、日期与业务条件下有效的项目，管理可见不等于可下单。项目管理按稳定 Code 升序、ID 升序；医生价格按医生显示名、稳定 Provider ID 升序。搜索覆盖代码／名称的授权结果全集，命中后仍稳定排序；空代码置末，显示名相同不得合并稳定对象。生效中、未生效、已过期与停用分别显示，不能仅靠颜色或一个 Active 字段掩盖日期限制。

新建保存 Draft 后提示所在状态并可打开已存记录，不让默认 Active 的过滤造成“保存丢失”错觉；停用成功退出 Active 并可在 Inactive 查询，历史交易引用仍可查。列表中的缺价格／Cost 显示未配置，不当作零元；查看详情和保存返回原搜索条件，版本冲突保留输入并要求重读，不静默覆盖他人修改。Change History 默认按变更时间、事件 ID 降序，显示操作者、原因、生效范围和前后值；无权限的价格／成本不通过搜索计数或导出泄漏。统一查询反馈见共同列表契约。

3. Service Items 与 Products

Category 从有效分类字典选择，Subtype 可选且必须属于所选 Category；更换分类时清空旧子类。服务端拒绝未知、停用或不匹配的分类，返回可处理的校验错误；表单内展示错误并保留输入，可修正后重试。保存期间防止重复提交及关闭丢失状态。可用诊所来自实际服务配置，套餐所需普通服务可从发布检查补齐，不因新建主档自动关联所有诊所。

Clinic 只控制能否选用，不能覆盖 Service／Product 的 List Price 或 Cost。Quantity、Lot、入库、出库和采购不在产品主档页处理。

4. Lab & Imaging

MD-02： 一个 Test Catalogue；2026-11-09 用户确认管理入口调整为 检查项目（Test catalogue）／供应商与定价（Vendors & pricing） 两个日常 tab，内部执行／外送及执行单位通过右上角 Execution settings 管理。执行设置不是价格 tab，退出设置保留原筛选与分页。该结构取代此前 Test items／Laboratory execution／Patient prices 三个并列入口。

• 检查项目： 每行是一条规范 Test Item。2026-11-09 用户更正：本页没有独立 ERP Code，唯一身份为 Unique Code；Vendor Code 属于供应商映射，同一 Test Item 可关联多个 Vendor／Vendor Code，不能作为主档单值列。主表精简为 Unique Code、Test Item Name、Category、Vendors、Status、Actions 六列，移除 ERP Code、Vendor Code 与重复的 Type。Category 按检查层级展示 Lab 或 Imaging → MRI／CT／X-ray／Ultrasound／DEXA／Other，不再把通用业务大类 Diagnostics 当作检查分类；优先复用现有检查子类，旧导入记录可回退到明确记录的 modality，缺失时显示 Imaging → 未分类，不凭名称或编码推断。分类筛选同时支持父级 Imaging 和具体子类；编辑以同一分层 Category 选择器维护已有分类字段，不增加第二套分类主数据，不改 Unique Code 或供应商映射。项目对所有诊所可用，无 Available Clinics 字段。项目管理不显示或编辑任何患者售价、参考价、成本及价格规则；这些内容统一在 Vendors & pricing 维护。正文 14px，编码及辅助文字 12px，状态不拆字；每行只保留一个常驻 32px 管理图标，也可点击整行打开同一窗口；图标具备可访问名称、悬停／聚焦提示及键盘焦点，保存仍保留文字。
• 供应商与定价： 主表每行对应一个项目＋供应商，独立展示 Vendor name 与供应商项目名称／代码，不显示 Clinic / scope，不因多个诊所服务配置重复主表行。2026-11-09 用户再次明确：检测项目适用于所有诊所，诊所仅作为既有价格规则上下文，不是项目可用范围。相同供应商下不同诊所的售价／成本配置通过展开行查看及编辑；金额或来源不一致时显示“多项价格／成本规则”，不得任取一个金额代表全部。支持项目／供应商代码搜索及供应商筛选，诊所／医生选择明确标为价格比较上下文。未选医生时不套用任意医生规则；指定诊所及医生后分别解析售价和成本。售价和成本使用独立规则，不因并排展示而合并底表或覆盖顺序。
• 完整性： 只有 Vendor Mapping、尚无服务配置的项目／供应商也要可见，明确显示尚无服务配置和未配置售价；不能把项目参考价伪装成该供应商报价。缺失值不当作零，真实零成本显示 0.00；服务配置未生效／已到期时显示相应状态。供应商原始价目表报价不自动等同于患者售价或内部成本。
• 统一项目管理窗口： 查看与编辑合并。上方维护 Test Item Name、Unique Code、Category，下方按 Vendor／Vendor Code／Vendor Test Name 展示一对多映射及状态；映射在同一窗口内展开编辑，不再叠加第二层弹窗。项目变更先保存，再维护映射；两项保存动作明确区分。只读用户使用同一窗口查看，字段不可修改、维护动作隐藏。修改名称、分类或映射不得连带改变已有售价／成本，映射状态改变也不隐式停用独立成本规则。价格行可跳入同一映射窗口；成本与售价编辑始终留在 Vendors & pricing。修改失败保留输入；未保存离开需确认，保存期间禁止重复操作／关闭。

读取与维护按当前有效动作授权区分。只有 catalogue.read 的人员可以查看项目、映射、成本及患者价格，但不显示映射、成本、执行配置或患者价格编辑动作，项目窗口以只读形式展示。保存请求进行中阻止关闭诊断详情、切换编辑表单及重复提交，成功后刷新父列表。维护入口及实际保存均要求 catalogue.manage，并遵守现有接口禁止 Assume 写入的限制；角色／工作身份变化立即清除旧编辑状态，迟到的读取或保存响应不得回填新工作区。Finance 价格写权限未因此扩展，仍按本 PRD 首段的待实施边界处理。

2026-09-14 会议及 2026-09-15 用户确认：V-Lab 项目与售价。 V-Lab 可维护新检验项目，发布后供医生在同一 Catalogue 中选用；维护入口归属不产生第二套项目主数据。所有项目默认执行实验室为 V-Lab，允许医生逐项目选择不同的有效映射实验室，并按实验室分流执行，内部／外部执行边界见 Lab PRD。

每个 V-Lab 检验项目分别维护标准成本及默认患者售价；实际患者售价按 医生在该诊所的专属价 → 诊所价 → V-Lab 默认患者价 解析。本次临时改价继续使用 Cashier 既有规则。此决定取代原 MD-02 对 V-Lab“患者售价统一、不随 Clinic／Doctor 改变”的限制；原 Cost schedule 表达成本，不替代患者售价。其他实验室及 Imaging 的新定价不由本轮自动推定。

供应商售价维护（2026-11-09）： 在统一定价表中，已有外部 Lab 服务配置及 Imaging 服务配置可直接编辑该诊所下的供应方案默认患者价，写回原 Offering price 并记录操作者、原因及前后值，不改其他供应商／诊所价格。内部及未配置执行关联的 Lab 继续继承项目默认价，默认价同样在定价页的“共用 Lab 默认价”范围编辑；它影响所有继承该项目默认价的诊所／供应商，界面必须明确说明影响范围，保留已有诊所／医生覆盖价。不能写入不参与取价的 Offering price，也不从 Test catalogue 编辑金额。Lab 继续支持既有诊所／医生覆盖价；Imaging 沿用原供应方案售价，本轮不引入医生／诊所覆盖价的新业务规则。尚无服务配置的映射可维护身份与成本，但不能保存或展示虚构的患者价；服务配置创建仍走既有配置流程。实现及实际验证边界见供应商定价界面验证。

2026-10-20 默认售价修复： 内部 Lab 及尚未配置实验室执行关联的旧 Lab Offering，默认患者价读取 Master Catalogue 当前 List Price，不能读取创建 Offering 时复制的旧价。有效医生／诊所患者覆盖价仍优先；明确配置为外部实验室的 Offering 保留自身价格。目录查询、服务选择保存和签署复核共用此解析规则；保存后再次变价仍要求签署前重新核对，已签署／已结算快照不追改。代码已修复，完成静态检查，未进行业务验收。

差异价以有效医生／诊所及项目关联配置，保留生效信息与变更审计；签署、订单及 Invoice 保留当时项目、实验室及有效价格快照，主数据变更不追改历史交易。标准成本的管理不自动生成 V-Lab 对诊所的应付结算；完成量月报范围见 V-Lab 月报。本轮只确认业务方向和优先级，医生维度取价、实验室切换及相关持久化仍待实现／验证。

Request Form Mapping 已从当前管理界面移除；旧四页结构和 Group Default Cost 不再作为验收标准。每个 Test Item 与 Vendor 的名称及代码映射独立持久化并保留变更审计；Vendor Default Cost 写入独立成本规则，与患者售价及供应商执行报价分开；按医生＋诊所＋供应商、诊所＋供应商、供应商默认的顺序维护和解析，并保留操作者及变更原因审计。

5. Consultation Pricing

MD-03： 每位医生一套 Standard Consultation Price，适用于各就诊类型与诊所，可有诊所例外。Insurance Rate 按 Doctor + Card／Policy 定义，默认全诊所适用，也可另设诊所例外。

取价优先级固定为：Doctor + Policy + Clinic → Doctor + Policy → Doctor + Clinic → Doctor Standard → Price unavailable 。

列表显示 Doctor、Standard Price、Clinic Exceptions、Insurance Rates、Status；详情维护基础价与例外、生效信息。不得再按 Doctor + Clinic + Consultation Type 建另一套基础价。当前新模型及 Billing Resolver 未落地，不能以旧 Offering 返回了价格认定该规则通过。

6. Insurance & Benefit Programmes

独立 App 管理 Insurance、Corporate membership 和 Staff benefit 目录。这些是保险／合作保障安排，不是折扣券；患者持有资料及本次付款安排仍分别归 Patient／Visit。

资格查询日期默认采用香港业务日期，不受浏览器所在时区或 UTC 日期影响。当前诊所优先跟随已选子单位，否则使用当前工作单位；该单位不在接口可选清单内时保留空值并要求明确选择，不自动落到清单第一家诊所。Find doctors 与 Check eligibility 均明确校验诊所、卡号及日期。变更诊所、卡号、日期或工作身份清除旧医生选项和资格结果；更换医生清除旧资格结果；过期响应不得重新显示旧结果。此规则不扩大接口可查询范围，也不把未匹配卡号解释为有效保险。

首次进入按当前有效权限选择工作区：具有 insurance.eligibility.read 时默认 Eligibility；否则具有 benefits.read 时进入计划目录，两者均无则显示无可用工作区。资格核查与共享目录维护分别授权，不以角色名称或查看资格推定编辑权。New Card、Edit、Manage Policies 及实际保存仅提供给同时具有目录读取、benefits.manage 写权限且当前身份可写的人员；正常登录与已绑定目标员工／任职的个人 full_support 模拟使用相同业务权限，只读模拟或未绑定有效目标身份不能写入；只读人员仍可浏览获授权卡片及说明。图片上载及卡片／保单保存进行中或结果未知时，阻止关闭编辑器／窗口、切换资格核查／目录及重复提交；提交前冻结字段和图片，上载返回后仍须校验原身份，身份变化不得继续后续上载或保存。身份／任职变化清除旧目录和编辑状态，旧请求不得回填新身份工作区；已确认保存与随后目录刷新失败分别反馈。现有接口没有写入幂等结果查询，未知结果保留待核对状态，不自动重试或承诺自动恢复；服务端仍须独立核验每次读取及写入。

6.1 卡种字段与来源

卡片详情、编辑与 Policy 管理使用有名称的模态侧栏；Tab／Shift+Tab 焦点限制在当前侧栏，打开／切换面板时焦点进入面板，关闭后返回触发入口。卡片与简单 Policy 编辑以载入时字段和待上传图片建立修改基线。Esc、关闭、Cancel、工作区切换与窗口关闭共用未保存检查：选择继续编辑保留内容并恢复字段焦点，明确放弃才退出；校验失败不清空输入，成功保存后退出不再额外询问。提交中和结果未知的阻断继续按第 6 节执行。

MD-04： 类型切换清除不兼容来源，互斥保存。历史未标类型的卡兼容为 Insurance。卡种只存来源身份，不复制合同 Plan、Rule、额度、Pricing、Eligibility 或 Utilization。

保险卡页先展示已读取的名称、提供方、类型、状态及来源等目录资料，卡面签名／图片加载独立进行，不等待全部图片才开放目录。可见卡面及主动打开的详情按需读取；图片载入中、缺图、读取失败及过期分别表达，可对失败图片重试，单张故障不使整份目录变成空列表。图片显示 URL 只属于当前身份的视图状态，不写入卡片保存字段；切换身份、重载目录或卸载时作废旧图片请求和缓存，迟到响应不得恢复上一身份图片。保险卡页为卡面网格，支持类型／提供方／状态和关键词筛选；零数据时具维护权者可使用 New Card，只读人员显示目录暂无记录。缺图明确显示，不能用示意卡冒充；无匹配、读取失败与真实空目录分别呈现。患者持卡、预约和登记统一读取此目录。

6.2 简单 Policy 管理

Manage Policies 在保险页内按上述维护权限打开侧边编辑，维护 Policy No.／Name、有效期、Holder Type、Contract／Insurance Type 与 Billing 可见性。没有独立顶层 Policy 页。企业合作计划不得写入 Policy 假冒保险合同。

6.3 计划详情与双语权益说明

• 统一独立桌面 App、页面标题及 Patient & eMR 的目录引用名称为 Insurance & Benefit Programmes。覆盖 Insurance policy、Corporate membership、Staff benefit；稳定 app ID、API 路径及既有底表保持不变。企业 / 员工计划仍引用同类型 Benefit Contract，保险仍引用 Policy。
• 卡片的 View details 和既有卡片编辑抽屉增加 Benefits & policy information 只读区。权威数据来自 policy_card_info.card_id → policy_card.id，逐条显示 title_cn、title_en、msg_cn、msg_en；保留多条记录、全文、换行、列表、强调和安全链接，在一个详情区域内按每条记录中文在前、英文在后连续展示，不分栏、不显示语言标签或选择器；空标题、空正文及全空记录自动隐藏，不自动翻译或补造业务规则。
• 说明按需从 GET /api/insurance-card-programmes/{id}/information 读取，沿用 benefits.read 权限，响应禁止缓存；不添加到共享目录、患者 H5、自助登记或患者主档快照。排除软删除说明及已删除卡片。加载中、无记录、读取失败和重试有独立界面状态，切换卡片后不显示上一个请求的内容。
• 原始 HTML 必须净化后渲染，保留文本强调、颜色及列表；移除脚本、事件处理器、表单、嵌入内容、图片及不安全链接 / 样式。JSON 附件含业务说明与门户凭证，本轮不导入附件、不将其内容写入 Git 或预览。公开／本地演示均使用合成数据。
• 用户提供的 JSON 是按名称导出的示例，缺少 card_id、id、type、clazz_id。不按名称自动建立数据库关联，不推测 clazz_id 的适用范围；上线前须用目标环境数据核对直接关联覆盖率。这是说明展示能力，不是自动保险资格核验、费率解析、Claim 或预批核执行能力。
• 验收：保险和企业计划入口使用统一名称；一张卡的多条双语说明在单一区域内完整显示，无语言选择器；纯文本、富文本、单语言空值、无记录、失败重试、跨卡切换和恶意 HTML 均有对应验证。底表无 schema 变更、无说明写入，本轮不扩展编辑或批量导入。 当前代码与合成预览已有该展示链路。目标后端部署、真实关联数据与业务 UAT 单独验收；发布记录在变更日志与测试材料中维护，不在本页逐轮追加。详情抽屉不显示 Source preview；卡片编辑保留来源选择，展示区仅使用真实双语业务说明。

6.4 保险卡计划的医生支持及本次例外

当前启用范围（2026-10-28 用户确认）：Cashier 暂时隐藏 Doctor insurance support 板块，并暂停医生支持规则／本次例外对保险结账的前后端拦截。 保险资格、有效期、预授权、逐项 Co-pay 及付款责任审核继续执行；共享规则维护、Exception review、预约／Prepare 的核实能力及历史记录保留。暂停期间不自动批准待审申请，不将 Unknown／Not supported 改写成 Supported；新发票记录本次未执行医生支持门禁，已有发票快照保持原样。下文医生支持门禁为保留功能，恢复启用后适用；恢复时 Cashier 展示与服务端拦截须一起启用。

2026-10-26 用户确认：在 Insurance & Benefit Programmes 的保险卡种详情维护共享 Supported doctors，按卡种／计划、稳定 Provider ID、诊所或全部诊所、生效起止日期记录 Supported／Not supported，并保留启停状态、依据、版本、修改人和时间；可批量选择医生。相同卡种、医生及相同诊所范围的有效重叠配置必须拒绝，指定诊所规则优先于全部诊所。卡种规则不写入每位患者的持卡资料。 2026-10-27 用户确认：Provider support rules 不设独立顶层 tab，归入 Card directory。从卡片的规则入口打开时，固定当前 Card／Plan，避免另选卡种；目录内保留跨卡规则查看／维护入口。关闭、切换卡片或离开工作区时沿用未保存保护。入口归并不授予额外权限：只有规则权限而无 benefits.read 的人员仍从 Card directory 进入其获授权的规则视图，不读取或开放完整卡片主档；Exception review 保持独立。

自动检查采用患者本次所选持卡的真实卡种／计划映射、医生、诊所及就诊日期，返回 Supported、Not supported、Unknown 三态和命中依据。缺少映射、医生或规则为 Unknown，不能伪装成明确不支持。旧 MyPlatform 资料只可作为经核实来源，不按医生姓名或机构名称猜配，不自动覆盖已维护规则。Supported 仅确认医生接受该计划，不代表患者合资格、额度、预授权或保险公司付款保证。

Not supported／Unknown 时，当前业务范围内的护士可提交本次例外申请。具有独立 insurance.provider_exception.confirm 权限的 Insurance／Billing 人员可以核实后直接确认，不要求另一人再次审批；普通 Cashier 操作权限不授予确认权。共享规则维护另用 insurance.provider_rules.manage，当前真实岗位、集团／诊所范围和只读模拟限制仍独立校验。

例外必须记录原因、核实方式及凭据说明／引用，附件可选；保存原自动结果、命中规则及版本、所选患者卡片／卡种、患者、医生、诊所、日期及本次 Appointment／Visit。服务端记录实际确认人、时间、版本及幂等请求；拒绝、撤销及再次申请保留历史。原状态仍可见，旁边显示 Exception approved，不能把原 Not supported 改写成自动 Supported。例外只放行本次医生支持检查，不更改共享规则，不替代资格／预授权及付款责任审核。

同一预约签到形成的 Visit 在全部上下文一致时可沿用例外；患者、持卡及计划依据、医生、诊所或日期改变后，旧例外失效。未保存预约修改须先保存再检查／申请，禁止用旧结果确认新草稿。Cashier 换选患者自己的保险卡可独立核实，后端重新读取卡片归属和快照；医生支持门禁启用时，结账事务重新检查医生支持与有效例外，冻结到发票；之后规则变更或撤销不反写历史发票，付款安排更正保留原票并重新校验。

实施状态：代码已有；本地完整链验证与 PRD 发布分别留证，真实医生／计划关联数据、STG 部署和业务 UAT 未确认。执行结果统一见专项证据。

7. Packages & Coupons

7.1 服务套餐、患者套餐账户与查询

套餐项目直接引用 Catalogue 同一服务主表的项目 ID；固定项目与任选组均提供「一级分类 → 二级分类 → 项目」筛选及名称／编码搜索。分类来自 Catalogue 的现行服务分类目录，切换筛选保留已选项目，可跨分类组成任选组。新选项目自动带出问诊、检测／影像、接种或普通服务执行流程，不提供另一套手工服务类型；临床来源映射及诊所 Offering 检查继续适用。

2026-11-01 用户确认： 套餐是一系列可维护的服务，关联患者账户并持续按服务抵扣／使用；同一患者可以持有多份套餐，包括重复购买的同名套餐。共享套餐定义与患者实际持有账户是两个对象，不能以患者页面修改共享定义，也不能将多个购买来源合成一笔无来源余额。

名称与界面语言（2026-11-01）： 中文统一使用“权益套餐”，英文使用 Package／Service Packages；操作文案跟随当前系统语言，英文界面不拼接中文，中文界面不附加英文对照。运行时切换语言须同步更新页签、购买、患者账户、Service 及 Cashier 的权益套餐入口与提示；病人姓名、套餐原始名称、账户编号等业务数据保持原值。

归属层级与管理范围（2026-11-02 用户确认）： 套餐主档必须区分“集团共享”与“诊所专属”，记录归属集团、所属诊所（诊所专属必填）及适用诊所。集团 Super Admin 维护集团共享模板，并明确选择适用诊所；各获选诊所共用同一已发布版本，不复制为可各自改写的模板。诊所经理仅可维护自己当前诊所的专属套餐，销售及使用范围固定为本诊所，不可扩为其他诊所；无权修改集团模板或其他诊所套餐。集团管理身份仍须遵守当前集团边界，不能因此取得患者查询、销售或退款权。

历史主档无可靠归属时标为“待确认”，不得凭名称、创建者或既往销售推断集团／诊所。由集团 Super Admin 明确补齐归属及适用范围后，重新建立并发布版本才可继续新销售；外部原订单登记按下方原已发布版本及冻结范围校验，不以当前主档替换原订单。原患者账户、已售权益、使用历史及快照保持有效并沿原范围执行。归属／适用范围修改必须使旧可售版本失效，重新发布后用于后续新购，不反写已售账户。

预约时段归属（2026-11-02 用户补充确认）： 预约时段管理从 Package Setup 移至 Calendar 的独立入口，由独立预约容量权限控制。套餐页承接套餐定义管理、外部已购登记和患者权益，新销售从本次 Consultation 的 Services 进入；普通／套餐预约共用时段与容量规则唯一见 Frontoffice 预约时段管理。

发布检查与可售状态（2026-11-03 配置流程调整）： “储存并核对”先原子保存整份套餐草稿，再自动建立或更新待发布版本并执行检查；已保存且无修改时直接核对。最终发布仍须员工核对后明确确认；页面统一展示售价、有效期、适用诊所、服务次数及分摊权重。权重不表示已分配金额，不要求权重总和等于售价；现场购买的成交金额按各次服务权重比例分摊，分摊合计与成交金额一致。eshop 已购仍按下述外部来源规则仅作分摊参考，不据此确认 CMS 实收。发布前检查稳定服务映射、执行类型及每个适用诊所的有效配置，逐项指出缺少配置的服务及诊所；只启用服务主档不代表所有诊所均可执行。未保存修改或检查未通过时不能发布；核对后主档、组件、归属或草稿版本改变须重新核对。已有发布及患者购买快照不追改。

普通服务缺少当前诊所配置时，有套餐设置及目录管理权限的本人工作身份可在检查结果内补齐：明确选择同集团有效供应商、填写供应商服务代码及变更原因，显示并核对共用目录售價，保存审计；不猜测供应商，不覆盖现有有效默认配置。Assume 身份不执行目录写入，化验／影像及疫苗保持各自原生配置及执行流程。保存后重新检查，确认发佈。草稿主档首次成功发佈时同一事务转为 Active；已停用主档不会自动恢复。新销售只列出当前诊所可用的 Active 已发佈版本；外部原订单登记使用下方历史已发布版本规则；前线无可售项时提示联系套餐管理员核对发佈及适用诊所，不引导进入无权访问的设置页。

原生问诊诊金（2026-11-04 用户确认）： 套餐可包含统一的问诊权益，不再配置 GP／SP 或按该分类匹配医生。发布时每个适用 Center 至少有有效 Doctor 任职、可执行 Zone 及有效 HKD 诊金；使用时重新核验本次实际医生与 Zone，单个 Zone 的资格不扩展为整个 Center。任职合格不表示排班有空。主要专科只用于人员专业资料，不作为套餐资格门槛。原生诊金沿现有价格规则，无须建立虚构普通 Service Offering。既有发布版本、已购权益及签署快照不改写；其中旧 GP／SP 标记不再参与适用性判断，其余范围、有效期、次数、签署及结算条件继续有效。旧草稿在重新保存时移除分类标记并重新校验。此规则取代 2026-11-03 的分类资格要求；使用意向与财务条件分别见 Consultation及 Cashier §4.4。

固定服务与任选组（2026-11-02 用户确认）： 一份套餐可同时包含固定服务和任选组。固定服务按包含次数分批使用；任选组从 M 个候选服务中提供 N 个可选名额，使用时逐项选择，可跨不同就诊分批完成。默认同组不可重复选择同一服务，可明确开启允许重复；不允许重复时 N 不得大于 M。组内不补差价，每个名额按购买时冻结的权重分配固定价值，选中不同零售价的服务不会重分摊或产生补差价。不同组及固定服务的权益仍各自独立。

• 购买时生成 N 个尚未绑定候选服务的名额，冻结候选服务、费用映射、执行类型、重复规则与分摊；以后修改模板不改变已购选项。
• Service 意向及 Cashier 覆盖提议不绑定／占用名额；确认预约预留或确认本次结算时，在同一账户事务中绑定所选服务，并校验同组重复。已预留、结算占用、实际已用，以及仍绑定选项的退款冻结名额均参加禁止重复检查；并发选择只允许一个合法结果。
• 有效取消尚未执行的预约／结算占用，且没有其他有效预约占用时，释放该名额及绑定选项；实际完成保留所选服务和执行历史，后续更正沿原受控流程。退款冻结先保留重复限制，最终退款后该名额终止；取消退款按实际可恢复状态处理。
• 每个候选项必须具有可执行的稳定映射。Lab、疫苗候选分别沿原报告发布、接种记录核销，不能通过手工完成代替；需要多个独立原生执行源的混合候选不发布。患者账户显示已用、预留／占用及剩余可选数量，预约与实际使用分别记录。

销售限额（2026-11-02 用户确认）： 限额单位为整份套餐，不是服务次数。集团共享套餐的所有适用诊所共同使用一个总限额；有单独诊所限额时，同时受套餐总余量与本诊所余量约束，取较小值。未设诊所限额仍受总限额约束；诊所专属套餐的总限额作用于所属诊所。不设限额表示不限量，不推算库存或预约容量。

• 跨套餐版本累计，以首次正式确认现场销售时计入，销售草稿不占名额；最后一份由服务端在确认交易中统一锁定校验。到其他适用诊所使用权益不重复计数。退款、作废后终止及到期均不自动返还已确认销量。
• 首次结算须重新验证模板 Active、原销售诊所仍适用及归属修订未变化；不符合时付款、结算、销量标记及账务事件整体回滚。已确认账户及幂等重放不因后续模板变化失效。
• eshop 已购登记单独统计，不占现场销售总限额／诊所限额，也不因名额不足被拦截；仍执行患者、版本、范围及 redeem code 防重复校验。登记份数不代表外部订单或付款已核验。
• 供应不足仅提供提示，不阻止保存／发布；缺少可靠供应数据时明确显示供应能力待确认，不计算虚假的可售数量。实际预约继续执行真实时段容量控制。

配置与销售使用展示（2026-11-03 用户确认调整整套流程）： Setup 保留左侧套餐导航，可按名称／代码搜索并按归属筛选，右侧编辑所选套餐。搜索只改变列表，不自动切换或丢弃草稿；主动切换仍检查未保存修改。窄窗口下导航堆叠在表单上方。

• 按基本资料、套餐内容、销售与适用范围排列。基本资料优先显示名称、售价、有效期；描述、分类、内部代码及类型按需展开，内部代码继续自动生成。新套餐在首次保存前即可添加服务、任选组及适用诊所。
• 固定服务先选服务，默认沿用服务名称，次数在内容列表直接编辑；自定义显示名称、分摊、收费覆盖及执行规则保留在进阶设置。任选组使用“可选服务／可选几项／是否允许重复”的业务标签，沿用固定名额、跨次使用及不补差价规则。目录中明确的检验／影像及疫苗类型匹配各自原生执行方式，不能为简化操作改成手工完成；复杂映射仍须核对。
• 添加、编辑、移除内容先更新本页面草稿；“储存草稿”一次保存主档、适用范围及全部内容。任一项失败则整体回滚，不提示部分成功为整份成功。保存校验当前主档版本及内容修订，拒绝覆盖他人已保存的变更。页面区分尚未保存、有未保存修改及已保存；服务编辑未完成时须完成或取消后保存。离开、关闭或切换套餐继续保护所有未保存输入。
• 保存结果未知时保留原请求并禁止继续编辑、切换或重复创建；“恢复储存结果”先查询原请求，确认未执行时才以同键重试。已提交的成功结果可恢复，不重复创建套餐；当前身份与模板权限仍重新核对。
• 选定诊所及完整服务后，在编辑期间只读检查服务映射与诊所配置。修改后立即清除旧检查结果，迟到响应不能覆盖新输入；检查失败明确提示，不当作已通过。该提示不等于已保存或已发布，正式发布仍按上文重新校验。缺少普通服务配置的修复入口继续在发布核对中，并沿用本人权限、供应商及审计要求。
• 诊所多选继续支持搜索、全选当前可见结果、清空及已选数量；经理的专属套餐固定本诊所。不限量时不要求填写额度，各诊所上限按需展开。限额编辑显示累计已售及按当前输入计算的余量，各诊所余量不能相加当作集团余额。

本次简化不改变分摊算法、销售限额口径、业务权限或已购版本快照。实际实现与验证边界见整份草稿专项。

“销售与使用”管理页按套餐汇总 CMS 已售、待确认销售、eshop 登记及剩余可售份数；权益次数另列实际已用、可用、预约预留、结算占用、退款冻结、已退款及终止。待确认账户不计入已发权益与使用统计；到期权益不能显示可用。账户分未开始、使用中、已全部完成及已结束，实际完成事实不会因到期或后续退款被抹去。详情展示各诊所销量、服务使用分布及任选组实际选项；不把预约／占用算作已消费。集团管理看本集团，诊所管理仅看当前诊所销售所属账户的汇总；前线销售从当前 Consultation 的 Services 进入，不因此取得管理统计。统计不暴露患者资料、账单明细或金额，也不代替财务报表。 支持套餐名称／代码搜索、销售所属诊所及指定套餐筛选、一键重置，并可切换按套餐／按销售诊所查看；按诊所可下钻该诊所的套餐列表。汇总、明细、服务分布及任选组使用均采用同一筛选范围。诊所归属按原销售／登记诊所，跨诊所实际执行仍计入原销售诊所；诊所经理固定本诊所，服务端拒绝越权参数。已用比例为所选范围实际完成权益次数／已发出名额，不把预留、占用算作已用；已发出分母保留退款、冻结及终止名额。筛选不重算共享销售限额，剩余可售仍受实际集团余量和本诊所余量约束。没有匹配结果时显示零汇总及明确空状态；更换条件立即清除旧结果，读取失败可重试。

购买来源（2026-11-03 用户确认）： 新销售从 Consultation → Services 的“销售新套餐”进入，自动沿用当前患者与 Visit，经 Cashier 收款／付款安排启用。Packages 主页面提供“外部已购登记”：员工选择原订单对应的已发布版本，填写 redeem code／订单参考、原有效期开始日与到期日、每个组件的实际剩余次数；不按登记日重启有效期，也不默认全部次数未用。原到期日包含香港时间当日，未开始或已过期账户可如实登记，但当前不可使用；零剩余仅保留历史。版本可为已被新版本替代或主档已停用的原已发布版本，仍须符合原版本集团与冻结诊所范围，不能把新定义套到旧订单。非重复任选组必须明确已用选项并与历史已用数量一致，后续不能重新选择；只生成剩余可执行权益，历史已用数量保留为外部来源，不伪造本地临床使用记录。

原訂單版本選擇框展開時直接列出後端按當前診所及權限返回的已發佈版本，無須先輸入關鍵字；仍可按名稱、版本號或版本 ID 搜尋，清空搜尋恢復可選清單。搜尋無匹配與當前診所沒有可登記版本須分開提示；後者提示聯絡套餐管理員核對發佈狀態及適用診所，不引導前線進入無權使用的設定頁。此規則僅適用外部已購登記的原訂單版本選擇，不改變其他目錄的搜尋優先規則，也不放寬後端凍結範圍及版本資格校驗。

当前外部登记仍为人工输入，未连接 eshop 订单／付款核验。记录来源、操作人、时间及原订单事实；规范化 code 在集团内防重复并脱敏显示。外部账户不生成本地 Sale／Visit／Invoice／Payment 或收入；版本售价仅作服务分摊参考，原付款金额未知，退款由外部销售方处理。两种来源共用患者权益查询与使用，redeem code 与折扣 Coupon 分开。此规则取代 2026-11-01 从登记日计算有效期及默认发放完整次数的行为；本轮完整本地执行范围见GP／SP 专项证据。

• 套餐主档维护服务、数量／次数、适用范围、售价、币种、有效期及可用状态；沿用 §2 的版本与交易快照规则。修改定义用于后续销售，不追改既有患者的购买明细、原价、分摊或已用记录。
• 每次购买／可靠来源关联形成独立患者套餐账户，保留 Patient ID、购买版本、原销售与收款来源、有效期、范围及逐项使用历史。患者可有多份账户，同名套餐按账户编号和购买时间区分；不能凭付款人姓名自动归属。
• 每项服务分别记录可用、预约预留、结算占用、已使用、退款冻结及已退款／其他终止；服务次数、分摊价值和 Deposit 金额不是同一个余额。不同服务的剩余次数不能视为可自由互换，套餐分摊价值不进入 Deposit 可花费余额。
• 现场新套餐销售经 Cashier 确认结算／付款安排后启用，允许保留未收欠款，不要求患者先付清；仅建销售草稿或客户端选择 Paid 不构成启用依据。购买收款与后续使用的唯一财务规则见 Cashier 套餐销售与结算。
• 预约关联到具体患者账户及服务权益；本次使用保存预约／Visit、收费来源与执行记录关联。Cashier 确认占用不代表实际服务已发生；疫苗按真实接种核销，其他服务按其明确执行节点处理。重复请求或同一执行记录重发不得重复扣减。
• 2026-11-05 选择界面按实际服务操作展示：可按套餐／包含服务的名称或代码搜索已有权益，账户作为筛选；候选直接列出服务内容和可用／不可用原因，选择后核对完整项目再确认加入。既有套餐固定 Offering 不能被普通 vendor 批量建议覆盖；销售新套餐与使用已有权益保持分开。
• Service 提供患者套餐／具体权益选择，将可明确匹配的普通服务或检查及 Offering 加入原生服务草稿；问诊权益只关联本次原生诊金及使用意向，不增加虚构普通服务行；保留原保存、签署及代改审核规则。同一权益的组合项目完整添加／移除，同一原生服务已存在且来源兼容时关联套餐意向，不重复新增；来源不兼容时提示先处理原选择，不静默替换；失效、跨患者、退款冻结或来源不匹配不得使用。疫苗／处方来源及不能由通用 Service 表达的组合显示原因，继续原生接种／处方流程，不伪装成普通服务。
• Service 的套餐选择只是本次使用意向，不扣次或占用。有效签署意向直接进入 Cashier 主付款清单，须明确确认覆盖或撤销意向改为普通收费后，才可结算对应收费组；员工确认本次结算后占用；未覆盖费用正常收取，实际履约后才核销次数。多账户选择均须可见，不静默应用隐藏账户。移除／修改服务时使未确认的旧覆盖建议失效；已结算或执行项目保持原保护。
• 需要患者级完整查询及业务场景快捷查询入口，所有入口读取同一账户和流水。本轮实现入口： Patient & eMR 承接完整套餐查询；Preparation、Consultation 与 Cashier 提供同一患者套餐面板快捷入口，Cashier 再确认本次覆盖；套餐详情及 Follow-up Booking 承接后续预约。页面入口不授予销售、核销或退款权限。患者选择与套餐接口共用集团患者身份目录及有效岗位校验，不额外依赖旧诊所关联表；账户列表、详情及交易仍分别按购买快照中的 Centre 范围和操作权限过滤，集团可见患者不等于其全部套餐可见／可用。
• 统一查询可同时提供 Deposit 独立区域，继续以其原账本为准；本轮以服务套餐为主，不新建另一套统一可写余额。退款／终止不得调用普通 reversal 将已退权益恢复为可用，规则见 Cashier 套餐退款。

版本与使用范围： 主档维护后生成 Draft 版本，发布前核验服务目录的稳定 ID、整数次数、覆盖费用映射和已接入的执行类型。发布版本不可直接修改；再次维护发布新版本。允许使用的 Centre 必须从当前集团有效非 Zone Centre 中明确选取并随购买快照冻结，不能因患者集团可见就默认集团通用。现场新购有效期从首次 Cashier 确认结算时计算一次；补缴不重置。外部已购沿原订单日期登记。未接入真实执行源的服务不可发布销售。 共享目录中的疫苗、Lab 服务必须使用对应原生履约类型，不能改成手工完成规避专有权限；费用映射必须是可验证的服务、药品／规格或 Offering 稳定标识，未知来源类型不能发布。

实施与验证边界： 2026-11-03 GP／SP、原订单外部登记与问诊销售／使用已通过列明的完整本地服务链、官方 Chrome 两条核心流程及 API／前端回归，具体覆盖、失败修复及构建限制见GP／SP 专项证据；本轮 PRD 发布、Git／STG、目标应用运行及业务 UAT 均单独计证。固定／任选组、销售限额及管理统计的本地执行结果与剩余边界见灵活配置专项证据。2026-11-02 发布检查、经理默认权限及 Calendar 独立时段入口的本地执行与交付边界见流程修复证据。本轮新增版本快照、Cashier 销售启用、共享查询、预约／使用与受控退款代码；实际执行结果、迁移与未覆盖项统一见本地专项证据。工程方案保留任务契约；本地实现不代表目标环境部署或业务 UAT。

7.2 现有页面、草稿与优惠边界

外部登记草稿归属当前患者及员工／诊所上下文，切换患者、页面或关闭窗口前保护未提交输入；放弃后清空原订单、日期和剩余数量，不能带到另一患者。结果未知时保留原请求并先恢复结果，不重复登记；身份／权限范围变化清除旧范围展示。问诊新销售直接绑定当前 Consultation 的患者与 Visit，待售项目及开票前取消由 Consultation维护，不再手填 Visit ID。

MD-05： Coupon 字段包括名称／Code、折扣类型与值、最低消费、可选最高减免、有效日期、次数限制、适用对象、描述及 Stackable。默认不与 Contract／Benefit 叠加，只有明确 Stackable 才允许。

同一 App 内保留 Service Packages 与 Coupons 两个业务区。Packages 提供 Setup、管理身份的销售与使用统计、外部已购登记、Patient packages 及使用记录业务入口；不再提供独立现场销售或手填 Visit ID；患者账户内的金额、履约及历史仍逐项按原权限读取，财务报表与 Lab 原生执行不作为套餐设置职责；原 Consumption／Consume 不再提供独立任意扣减按钮，使用从本次服务覆盖及真实执行进入；Coupons 独立读取 Campaign、编辑并按权限发布，不再为了打开优惠页读取 Catalogue 全套底表。

Packages 按当前有效动作与 App／Tab 配置显示入口；Setup 另受管理岗位上限及模板归属限制，护士、医生和普通前线人员不展示设置页、版本发布及服务定义入口，历史授权或深链接均不能绕过。具有 Wallet 访问权时默认 Patient Wallet；否则进入首个获授权且可见的业务页，不把 Setup 当作所有人员默认首页。有效深链接可指定对应页，无可用入口时明确显示无权限状态。Setup、销售、读取权益、核销及财务查看继续分别授权；入口调整不授予任何新增业务动作。

Sell Package、Patient Wallet 与 Consume／Reserve 共用明确的患者搜索与选择区。搜索只返回候选，人员核对后显式选择，不自动使用第一名患者；新搜索清除旧患者和权益选择。未选择患者、正在查询、没有匹配及查询失败各自显示；未选患者或账户读取失败不能显示成“没有套餐”。选中患者后，账户区域分别显示加载中、无读取权、失败可重试、成功无账户及已有账户；只有权威读取成功后才展示余额和可操作权益。账户列表用于选择账户；初次载入、切换账户及销售后刷新均须读取该账户的权威详情，展示实际权益与台账，不能用列表摘要替代详情而误报没有权益。账户切换期间清除旧详情，并拦截过期响应。更换患者、身份或任职时清除旧账户，迟到的查询或动作响应不得把旧患者账户、错误或成功提示写回新上下文。

套餐写入进行中或结果未知时，患者切换、重复写入、离开套餐工作区、关闭窗口及角色／任职切换均受保护，函数调用与界面控件执行同一检查。已确认保存与随后刷新失败分别反馈；尚未取得明确结果不能称为保存成功或通过重发同一业务动作猜测结果。新套餐命令提供按原 request_id、operation 和当前身份查询结果；结果未知时保留原请求，先回读再以同键重试，同键异内容拒绝；完整服务链及目标环境验收分别记录。

Campaign 管理不代表全部使用入口与叠加场景已闭环；优惠与套餐的读取、维护、发布权限独立；只读优惠券用户不显示编辑、发布或停用按钮及编辑弹窗。套餐销售按 §7.1 接入 Cashier，具体运行覆盖仍以专项证据为准；Coupon 实际核销须保存 Campaign／版本与撤销历史，跨套餐与优惠叠加仍需对应后端实现。套餐核销、退款与财务规则见 Cashier／Pharmacy 文档。

8. 批量导入

支持的主数据用同一流程：Bulk import → 下载模块专用模板 → 上传 Excel／CSV → 全文件预校验 → Pass／Warning／Error 逐行预览 → 选择获支持的重复处理策略 → 确认导入 → 行级结果／错误下载及审计。

• 导入仅产生 Draft，不绕过发布权限，不把警告或错误隐藏成全成功。
• Service、Test Item、Product、Coupon、Policy 可复用现有导入基础；每种字段仍按本域验证。
• Insurance Card 逐卡维护，不提供 Excel 批量新增 。
• Clinic Availability、Vendor／Cost Schedule、Consultation Pricing 及 Package Component 的正确底表未完成前，不开放模拟成功导入。

9. 变更控制与配置归属

Catalogue 移除 Other Settings。共享系统资源归 System Settings，组织／账号／权限归 Organization & Access，个人模板／布局归 Personal Settings；药品及库存仍归所属业务 App。Change History & Controls 显示本模块谁改了什么、原因、版本、发布／停用结果，不是经营报表。

验收重点：字段含义、可用范围、价格优先级、失效与历史快照、互斥来源、导入前校验、实际持久化。每个尚缺底表的功能在实现记录标 Pending，不能因前端预览完成而关闭需求。