Central Pharmacy 内部管理产品设计

更新：2026-09-10 · 版本：v1.1 · 状态：已补齐诊所自采的 PIC 审批、直接采购与自行入库设计；全内部范围召回权限暂缓；SOP／数据核对与业务实施仍待完成。

责任：Line C / WS4；Central Pharmacy、WDL 采购、供应商和复杂库存由 Samuel 主责，NeosAI 支持；Finance、WS3、WS5、WS6、WS7 协同。

依据：AI-CLIP_CP_WDL_Requirements2Sep2026.pdf 调研、用户补充的 PO 说明、09-05/06 范围收敛，以及本次逐项确认。附件是业务来源，不自动构成交付或法规合规承诺。09-09 明确决定优先于旧文档及旧代码；本文不调整合同、报价或排期。

本版取代旧稿的单层审批、批准后原 PO 改药改价、缺批次效期仍可验收，以及 CP 保持 WDL 身份处理患者发药的口径。 CP 自身供应商 PO 为 Staff → PIC → Finance；09-09新增确认的诊所自采只需 CP PIC 审批，获批后由诊所直接向供应商下单及自行入库；患者发药在 Clinic Drug Dispensing。旧 v0.3 交互原型仅保留历史演示与验证证据，不是本版流程的可执行实现。

功能地图

Orders 管单据，Inventory 管数量与实际移动，Master Data 管可复用定义。下列功能按这一架构展开，后半部分是页面与实施参考，不另设业务规则。

1. 目标、范围和已确认决定

一个 CP 主存货地点向内部诊所供货。系统管理“申请多少、实际收到多少、存在哪里、还能使用多少、实际耗用多少、退回多少”，由人工决定与录入实际结果，系统计算数量并保留依据。

不增加独立经营看板、自动采购预测、复杂赠品计算引擎、自动付款或患者在 CP 取药流程。具体单位映射由底表和代码核对，不要求业务逐种回答包装换算。库存统一不等于所有用途按同一单价收费。

2. 功能架构和上下游全流程

保留一个 Central Pharmacy App，三个一级入口 Orders / Inventory / Master Data。Inventory 是库存业务的操作入口，Warehouse 是 CP 仓储工作的旧命名，不再建立第二套库存 App 或余额。Clinic Pharmacy 从自己的工作场景提交申请、查看授权数量；Finance 从后台处理同一张采购单及数量对账单。

flowchart TD
  M[共享药品、单位、供应商] --> P[CP 创建供应商 PO]
  P --> A[PIC 审核 → Finance 审批]
  A --> S[人工发送并登记时间、收件人]
  S --> R[分批收货：明确批次与效期]
  R --> C[CP 来源批次库存]
  Q[Clinic 向 CP 申领] --> D[CP 分配与实际发出]
  C --> D
  D --> T[在途]
  T --> K[CP 登记 Clinic 实收]
  K --> I[Clinic 来源批次库存]
  M --> DP[Clinic 创建自采 PO]
  DP --> DA[CP PIC 单级审批]
  DA --> DS[Clinic 人工向供应商下单并登记发送]
  DS --> DR[Clinic 自行验收：批次、效期、实收]
  DR --> DI[Clinic 第三方来源库存]
  DI --> U
  DI --> EX[单独退药例外：Staff → PIC]
  EX --> RT
  I --> U[Clinic 发药／实际废弃]
  U --> F[统一耗用 → 按来源纳入或排除 → Finance 数量确认]
  I --> RT[Clinic 退回：原实收或已批例外]
  RT --> C
  C --> SR[实际退供应商]
  C --> RC[PIC 批次召回／盘点审批]
  RC --> I

开账导入属于库存的授权初始化工具。日常导出放对应列表；单位映射维护在药品详情，不能把实收现场变成自由编辑主数据的表单。待处理数量作为状态筛选显示，不另设大号统计卡或第四个主模块。

2.1 Orders 单据列表与工作页

Central Pharmacy        Orders | Inventory | Master Data
Supplier POs | Clinic requests | Approvals              New PO
状态＋待处理数量 → Search / Supplier或Clinic / Date → 全宽表格
打开单据：Back → 单号／对象／状态／版本 → 明细 → 关联记录／时间线
固定任务底栏：本次处理数量或阻断原因                当前唯一主动作

Supplier POs 列表显示单号、供应商、日期、状态／当前审核层、提交人及未收行数；不同药品／单位不硬加一个总数量。详情逐行显示普通原订购／已收／未收、赠品已收、原单位、基本数量、计价单位／价格；审批时完整展示药品、数量、价格和交付信息，不从列表摘要直接点 Approve。

审批视图按任务类型和当前层级筛选：CP 采购 PIC 待审、CP 采购 Finance 待审、Clinic direct purchase、退药例外（含自采药退CP）及盘点差异。自采任务显示申请诊所、供应商、申请人及版本，打开完整明细后审批；单级通过后回到诊所待发送，不生成Finance待办。Finance 在后台打开同一 PO 提交版本；Staff按已授权CP单位／运营任务查看单据及过程，“本人提交”是列表筛选，不阻断同单位已授权人员换班接手；审核写权仍只归当前节点。批准／驳回后展示真实节点记录，不能由后一步状态倒推之前已通过。

Send record 是短表单，仅时间、收件人；操作人自动取会话。Receive goods 是单一宽任务弹窗：上方 PO 上下文，中部按批次的可编辑收货表，右侧／下方显示单位转换与本次影响，固定底栏确认。缺批次／效期／转换的行就地提示；不要用另一质量审批页面代替同屏验收。

Clinic request 详情分申请、来源分配、发出、实收／差异和记录；CP 来源批次选择器显示基本单位可用量及效期，保留人工决定。Clinic侧复用已有Drug Dispensing App容器，设计独立的 Patient dispensing / Clinic orders / Stock 工作区；订单和库存页不依赖打开某患者。Clinic orders分 Request from CP / Direct purchase 两种类型，各有列表→详情→新建：前者显示供货／分发进度，后者显示PIC审批→发送→供应商实收；表格和详情共享组件但不同类型不能混用状态按钮。Stock固定My clinic／CP范围，可从药品进入对应订单创建。Clinic Pharmacy 创建入口明确当前所属诊所，不出现其他诊所选择列表；Staff 代办入口仅列已明确授权的目标诊所，保持 Staff 身份；不恢复重复Inventory App，不把患者上下文带到采购申请。该入口为本稿前端方案，患者页面的现有权限和门禁继续生效。

自采详情固定显示所属诊所和“Clinic direct purchase”，明细列药品、普通／赠品、原单位和基本单位换算、价格及累计已收／未收；页内关联PIC审批、发送和历次收货。主动作随状态为 Submit for PIC approval／Record sent／Receive goods，Returned显示原因和修订／新单入口，未批不出现可执行的收货按钮。Receive goods复用宽收货表单，标题明确“Receive into [本诊所]”，按本次批次与效期校验，确认摘要只增加本诊所来源库存。已收来源的 Return to CP 带出原自采单／实收行，诊所提供来源与原因并向CP发起退回请求；由CP Staff打开同一例外单、正式提交PIC审批及按既有授权办理。Clinic页面查看关联进度，不因这个入口取得CP例外提交或执行权；办理后能回到该来源，不复制新库存记录。

3. CP 供应商采购、审批与收货

功能目的： 形成获批采购并将真实验收数量记入 CP 库存。

使用者与对象： Staff、PIC、后台 Finance；同一 Supplier PO 和收货批次。

操作与结果： 建单提交 → PIC 审核 → Finance 审批 → 人工发送 → 分批验收与入库。

关键边界： 提交与两级审批三人分离；实际收货必须明确批次与效期。

3.1 PO 内容与两级审批

本节仅定义 CP 向供应商采购。按调研说明，同一 CP 供应商 PO 承载 WDL Written Order 的业务信息，不复制一份独立书面订单。保存供应商、稳定药品 ID、原订购数量／单位、计价单位及单价、赠品条款、配送信息；价格、单位和药品信息按提交版本留快照。

提交者和各审核节点保存真实用户ID与有效角色／单位。09-09用户确认：同一PO提交版本的PIC审核人与Finance审批人必须是不同人员，两人也都不能是提交人；即提交、PIC审核、Finance审批由三位不同人员完成。服务端按真实人员身份核对，不能以切换角色、显示名或模拟身份满足人员分离。Finance审批时同时校验本版本提交人和PIC审核人；同一人员即使在历史配置中曾有不同角色，也不能完成两级；现行一个 User 一个角色的约束继续适用。没有符合条件的审核人时保留待审状态，由有权负责人安排合资格人员，不自动跳过节点或放行发送。具体权限点须在后端实现，现有cp.po.approve不能直接表示两个节点都完成。

Draft尚未提交时可编辑；首次提交后内容锁定。Returned仅允许对未改变药品／价格、未追加采购量的其他内容修订后提交新版本；驳回理由是药品或价格错误时同样遵守下述新PO规则，不因Returned而获得覆盖原药品／价格的例外。更换药品或改价应作废前一份 PO，关联新 PO 并重新走 PIC → Finance，不能在原批准单上覆盖。已部分收货时，保留旧单已收、库存与审计，只结束未履行部分并新建关联 PO。普通追加采购数量另建补充 PO，保留原单不变；不能把追加采购写成赠品绕开审批。旧单作废／终止的原因、替代单和保留的已履行量清楚展示。

补齐终止操作的设计如下；历史版本保留，所有动作需在当前状态及版本下校验。

审批／撤回、收货／关闭并发时以先成功提交的状态版本为准，后提交者刷新后重新处理；已经收到的实物不因关闭消失。关闭数量覆盖明确普通余量，赠品任务独立结束，避免旧单Completed仍遗留可收入口。

3.2 同屏验收与分批入库

从 PO 详情打开 Receive goods，带出各行原订购、普通已收、普通未收、已赠送量及单位。按本次到货分批次录入：正常数量、另加赠品数量、各自录入单位、批次、效期、放行结果和备注；展示换算依据及本次增加的库存基本单位数量。

• 批次或效期不明可以保留未过账草稿，但不能验收、确认入库或采用“先入不可用库存后补字段”绕过。不是所有缺值都可填备注。
• 一张 PO 可多次收货，同一行可分多个批次。正常接收量不能超过该行未履行量；超出的普通货需另走 PO。拒收／本次未接收量不增加库存、不减少原未履行量，处置备注留在收货草稿／异常记录。
• 批次效期已知但损坏、失效等货物，由人员决定拒收或接收为不可用；不可用实物接收和可用放行分别记录。过期库存不得进入可用量；具体剩余效期门槛不在本稿虚构。
• 同药赠品作为收货行的独立数量组成部分，转换后与正常数量相加一次；合计只读，避免“总量已含赠品”再加一遍。其他药品赠品是已审批PO中的独立药品行及单位，不能合并到正品数量；批准单中没有该药品时，关联新PO并审批，不临时改变原批准药品范围。
• 普通货收齐与赠品接收分开：普通履行显示Completed后，仍可在原批准药品范围内用“Receive bonus”登记后到的实际赠品，普通实收必须为0，照常填批次、效期及单位；不重开普通未收量。已知赠品待收任务单列，可记录原因后结束；作废／已关闭接收的单据不继续收货。赠品条款不自动产生库存或复杂计算。
• 09-09用户确认：原PO已批准的同一种药，未约定或超约定的实际赠品允许Staff直接登记验收，不重新审批；批次、效期及换算照常必填。界面显示约定赠品、累计实收、约定未收和超约定实收量；超约定提示是差异说明，不阻止该授权接收，也不把原条款改写成新承诺。保存本次实际赠品及原PO关联，按收货事件防重复入库；普通追加采购不能改填赠品，未批准的其他药品仍走新PO。原单关闭接收后不借此权限重开。
• Receive & confirm 只为本次选定且校验通过的行过账；未完成的行留草稿。确认前摘要清楚显示本次接受量、可用／不可用量及未接收部分。
• 每次收货生成独立收货单／行及库存来源层。保存、刷新、网络重试或重复点击不重复入库。纸质发票、PO 状态、批准事件均不直接增加库存。

4. Clinic 订单：向 CP 申领与向供应商自采

功能目的： 区分内部申领和诊所直接采购，保留各自来源。

使用者与对象： Clinic Pharmacy、CP Staff／PIC；Clinic PO、分发和实收。

操作与结果： 内部申领由 CP 分配、发出和登记实收；自采先 PIC 批准，再由诊所直接下单验收入库。

关键边界： 自采不经过 Finance 采购审批；WDL Staff 代申领保持唯一 Staff 角色，按目标诊所及具体采购动作另行授权，不取得患者发药权。

两类订单共享药品、单位和库存服务，但保留明确的订单类型、供货方、收货诊所与审批路径。向 CP 申领走分配／分发；诊所自采走 PIC 采购同意／供应商直接交货，不能因界面复用混用状态或权限。

4.1 向 CP 申领、分发与接收

诊所 Pharmacy 创建本诊所申请，保存药品、数量、单位、申请日期和备注。CP Staff 按下述限定采购授权代办，保持 Staff 角色；记录真实登录人、有效角色和目标诊所，不自动获得所有 clinic 的权限。CP 承接仍引用同一申请。

限定诊所采购代办（2026-09-10 本轮 PRD 评审确认）： 保留 Staff 代办，以角色动作＋目标诊所授权实现，取代旧稿要求同一 User 切换 Clinic Pharmacy 角色的规则。目标诊所是单据来源／受益单位，不是给 Staff 增配第二角色。

授权应明确 Staff、可代办诊所、允许的采购动作、有效期及授予依据；入口只列有效授权诊所，保存和每次后续操作独立重验。创建／编辑草稿／提交、发送登记及收货分别检查，不能因为获准下单就自动取得收货、库存调整、临床审方、标签、备药、复核、患者发药或病历读取权限。审批职责仍按原采购链和真实人员分离执行，代办不包含自批。原账号、Staff 岗位或采购授权失效后停止新操作，既有单据及作者保留，由仍有权限人员按原单接手。

界面明确显示“代 [诊所] 办理采购”、当前 Staff 身份及允许动作；订单保存目标 Clinic、实际代办人和授权依据，列表、详情、导出与提交使用同一范围。不得借患者 Drug Dispensing 页面或模拟他人身份办理采购。

实施状态：已确认目标，限定采购授权及 Staff 入口待开发／验证。 原 Clinic Pharmacy 自行下单路径保留；存量 Staff＋Pharmacy 双角色配置须结合单角色整改核对，不能直接删岗位、改历史作者或以旧切角色测试证明新方案通过。

Clinic requests 展示原申请量、未满足量、已分配未发量、累计发出、累计实收、在途、差异、已结束余量，各数量统一到该药品基本单位，原录入数量／单位同时可查。

1. CP 人员选申请和来源批次，决定本次供应量。系统可按有效期先后建议候选，人员最终选定；不可用／召回／已过期或已被其他任务预留的量不可发出。
2. 形成分配时仅预留 CP 现存量，不减现存。实际发出时扣 CP 对应来源层并释放本次预留，转入该分发行在途量。
3. CP 人员录入 clinic 实收，按同一分发来源增加 clinic 库存、减少在途。一次可以同时登记发出与实收，仍保留两条关联数量变化。在途期间过期、召回或发现损坏的实物仍可登记真实接收，但进入不可用量并继承冻结／失效原因；不能因到达新地点恢复可用。
4. 实收不得超过该分发行剩余在途；发 10 收 9 时，1 保留在途差异。经核实再登记补收、原货退回 CP 或实际运输损耗；补发是新的发货，不能用补发抹掉原来的在途 1。
5. 申请部分满足后可继续供应或记录结束未发余量，理由必填。结束申请不自动结束在途、撤销实收或取消已耗用记录。后续退药／换货关联原履行记录，不自动重开原已结束申请。

未满足量＝原申请量－有效累计发出量－已结束未发余量；已分配未发量属于其中一部分，不再次相减。本次可新增分配≤未满足量－其他有效未发分配，实际发出≤本次有效分配，两项与来源可用量在同一事务校验。实收差异另按分发行处理，防止混成“申请还欠多少”。源记录已发生更正时从有效流水重算，不手工覆盖累计数。

申请状态与实物履行分别展示：Draft → Submitted → Partially fulfilled → Fulfilled／Closed remainder；Draft可编辑或取消。提交后药品及原申请量保留，追加需求另建关联申请。Clinic提出减量／取消剩余需求，由CP在同一申请确认关闭未发量；该确认与分发互斥校验，并同时释放所关闭部分的分配。尚待CP确认时明确显示“取消待处理”，不能假装已取消。全部未发且全量关闭显示Cancelled；部分已发只关闭未发余量，旧在途和实收任务继续。返回的货和替换发货各走关联记录，不抵消原发货事实。

Fulfilled表示申请量已全部实际发出，不表示clinic收齐；实收进度及在途差异继续单列。例：申请20、已分配15未发，CP确认全部取消后释放15、关闭20，不产生库存移动；若已实际发出5，最多关闭剩余15，已发5继续实收／差异处理。该操作是供货安排，不增设采购审批。

4.2 诊所自采：PIC 同意后直接采购、自行验收入库

09-09用户新增确认：诊所自采必须先获得 CP 同意，审批由 CP PIC 单独完成即可；通过后由诊所直接向供应商发起采购，自行收货入库，之后也可能退回 CP。 Finance 不增加采购审批节点；§3 的 CP 自身两级审批不变。本节是新交易流程，既有第三方历史库存仍按开账／来源核对处理，不伪造历史审批。

采用同一张 Clinic direct purchase PO 贯穿申请、PIC 审批、供应商发送和收货，不让人员再抄一份独立采购申请。保存所属诊所、供应商、药品、普通数量／单位、计价单位／单价、赠品条款、交货信息及申请备注。审批的是本单提交版本，不是对该诊所／药品的长期无限采购许可；供应商及价格为本单授权人员可见的业务快照，不因使用共享目录开放其他单位商业资料。

复用 §3 的版本、驳回／撤回、终止及关联新单原则，但审核链固定为 PIC 单级，操作归所属诊所。Draft 可改；Pending 可撤回，当前审批任务结束。首次提交后更换供应商、药品或改价时终止旧单未履行部分，关联新 PO 重走 PIC；普通追加采购另建补充 PO，不能改写已批上限。其他允许修订的新版本也重新送 PIC，不沿用旧批准。批准未发送的单可作废；关闭后到货保留未过账异常，拒收或关联新的已批并登记发送的有效单，不重开旧批准额度。审批、撤回、接收和关闭按同一状态版本互斥校验。

诊所自行收货是本次新增的明确职责：不再要求 CP 人员代录这一采购支线的实收。每次确认都生成本诊所独立收货行及第三方采购来源层，关联原自采 PO 行、批准版本和供应商。一单可多次收货、一行可分多个批次；复用 §3.2 的批次／效期强制校验、正常量不得超未履行量、可用／不可用判断、普通／赠品分列及 §7 单位转换，不继承 CP Staff 专属的额外赠品接收权限。缺批次／效期或转换依据只能留未过账草稿；批准、发送或纸质发票均不增加库存。没有有效批准却已到货同样保留异常，不用手工调账或历史导入绕过本流程。

库存按 供应商 → 本诊所 直接增加，无 CP 出库、CP 分配或内部在途；采购未交货量仅是 PO 待收，不计内部现存。收货单位绑定订单所属诊所，服务端不得接受任意目标地点。实际货在错误地点时保留异常，不先记到原诊所再虚构调拨。CP Staff 只有获得该诊所对应采购及收货动作授权后，才可保持 Staff 角色执行获授动作；下单授权本身不包含收货，真实用户与目标诊所分别留痕，见 §4.1。

自采直接在诊所发药、浪费／销毁进入统一库存与耗用流水，按 §5.3 单列并排除 CP 结算。后续交回 CP，选择本自采实收行发起第三方退药流程，由 Staff 另提本次例外、PIC 单独批准，再登记实物移动和接受结果；采购批准不等于退药批准，不保证 CP 将来接受退药。已经纳管的自采库存必须从诊所对应来源扣减，不能当成无记录外部货只给 CP 加库。CP 接受后再实际供给诊所，才对对应再次供货后的耗用生成 CP 结算资格；待处理／拒绝后原物退回原诊所保留原自采性质，不冒充再次供货。

5. 库存完整逻辑：数量、状态、来源及结算

功能目的： 由同一数量流水解释余额及可结算耗用。

使用者与对象： Staff／PIC／Finance；地点、药品、批次、来源及 Movement。

操作与结果： 业务确认产生数量变动 → 查询余额及来源 → 汇总实际耗用 → Finance 数量核对。

关键边界： 审批不直接移动库存；诊所第三方直接自购耗用与经 CP 供货耗用分别计算。

5.1 一个余额来源，保留四个维度

库存基本对象为 药品＋地点＋批次＋来源实收层，数量统一为该药品基本库存单位。内部转移新建目标地点实收层并保留父来源层、原供应商实收根和来源性质；退回也保留新的实际接收事实，不删除来回路径。相同批次从两张 PO 收到，可以按批次汇总展示，但退药额度、耗用与转移必须仍能分到原实收层；名称或自由文本单号不足以追溯。

每一来源层的 H＝A＋R＋B，均不得为负。库存状态改变不等于实物增减；批次、效期不是药品主档的单一日期。页面允许同药跨批次汇总，不能把不同药品的 TAB、ML 或 BOX 相加成“库存总数量”。

有效预留遭遇过期／召回时，对应实物转不可用，原任务标记需重新分配并保留失效的预留历史；该数量不能同时算进 R 和 B。过期检查须在查询和实际分配／发药确认时生效，不能只依赖一个可能延迟的后台任务。人工判断可以选择可用来源，不能把系统已知过期或冻结数量当作可用发出。

5.2 何时增减：所有确认动作进入同一流水

表内 Q 均为转换后的基本单位量；“确认”指实际业务确认及服务端成功过账，不是仅保存表单。

内部转移满足 CP 现存＋各 clinic 现存＋内部在途 守恒。外部采购／外部来源首次纳管／外部换货实收、实际耗用／损耗、外部退货及盘点调整分别解释总量变化。供应商退换过程中若已记出库，后续处理结果不得再次减量；实际回货才增加。

5.3 统一耗用与数量对账

患者实际发药在 Clinic Drug Dispensing 完成；库存使用其实际发出数量与单位，不使用医嘱剂量或仅已备药状态。库存服务需接受统一来源键（来源类型、来源记录、版本、行及动作），无论从业务接口还是人工补录进入，同一事实只计一次。

一个药品执行行可有多条实际批次／来源分摊，各子行保存原数量、单位、换算及基本量；子行基本量之和须等于签署的实际应发基本量。最终仍按处方整单领取，各来源同一确认事件只扣一次；改变已备药分摊需重新实物核对。付款后原批次过期／召回／盘亏导致预留失效时，药房可按授权进行同药同量的来源重分配，重新备药和复核；处方与价格未变不重收费，无有效替代来源保持阻断。完整操作门禁见Pharmacy／V-Lab。

人工补录历史发药必须在 clinic 的授权流程关联来源；CP 的耗用页面可查看、登记真实废弃及处理经授权的补记，不提供绕开药房门禁的患者发药按钮。已由其他模块过账的记录只展示；取消未发药只释放预留，已发药后的患者退药／退款遵循药房与 Cashier 原流程，不等同于 clinic 向 CP 退库存。

数量对账按 clinic、药品、期间生成，列示发药量、实际浪费／废弃量、患者实际回收量、错误更正量和净耗用量，单位为基本单位，能下钻每笔来源。CP 自身损耗、运输损耗、地点转移、失效标记和未分类盘点差异不直接记成 clinic 发药或 clinic 耗用。

Finance 查看授权范围的同一对账单，核对后登记确认／退回及备注；记录操作者、时间、汇总版本及所含流水。确认不再扣库存、不自动收款、不生成患者发票或擅定收费价格。确认后发现补录／纠错，保留原版并生成明确取代旧版的新版本待重核，不静默重写已确认结果。具体结算期间由筛选选择，不预设必须月结。

查询与正式确认分开。 任意日期范围可查询；正式确认单按真实耗用来源分摊纳入明细，同一分摊只能归属一个有效确认结果。重叠查询可以展示已确认量，但生成待确认单时必须排除或明确引用已归属明细；不能因换一个期间筛选又确认一次。期间以经营单位配置时区的实际业务发生时间计算，使用起点包含、终点不包含的边界，同时保留登记／过账时间。

本稿采用可追溯的替代版本设计：确认后补录或纠错，生成待核新版本，展示与旧版差异；Finance确认后新版本显式取代旧版，旧版仅作历史。不得同时另生成一份独立差额单重复归属。纠错沿用原分摊的确认单归属；尚无归属的新迟录事实先进入未确认明细，由人员选定唯一符合诊所／业务日期范围的确认单接收并生成替代版本，或纳入独立待确认单。多个重叠期间均符合时不能自动同时吸收。迟录事实保留真实发生日期，不为方便改成登记日耗用。并发生成／确认／替代须校验明细归属和版本，已经更正的源事实不能继续按旧快照新确认。这里只替代数量核对结果，不自动逆转财务系统的付款。

一套库存事实，保留结算来源。 所有耗用按实际来源分摊，至少区分CP普通供货、CP赠品、诊所第三方自购、第三方经CP接收后再供货、历史来源待核。同一药品混合来源必须拆分；目录的CP／clinic_direct优选、当前药品价格或零单价不能代替实际来源。09-09用户逐项确认的结算归属如下；这些是数量口径，不自动确定采购成本、结算单价或患者退款金额。未知来源单列待核，不能默认按普通CP供货确认，也不影响来源已明确的正常库存登记。

患者实际退回由Clinic Drug Dispensing受理。目标库存接口须关联原发药及来源分摊，记录真实接收的数量、单位和当前处置状态；保留原发药事实，不能把真实退回当作原发药错误直接删除。每个原发药分摊的累计有效回收不得超过其原实际发出量，含不同退单、在办占用及回收更正，并发在提交点校验；不能借其他批次的发药量或把不明来源硬挂已发记录。未能确认药品／批次等来源时保留待核记录，不能伪造来源入库。退款不移动库存，后续实际销毁再关联该回收实物扣一次。可否重新放行遵循药房质量规则，不能默认恢复可用。

09-09用户确认：患者实际回收时扣减对应CP结算耗用量，后续实际销毁再计入；例如CP来源发药10、实际回收3、再销毁3，累计结算耗用量为10−3＋3＝10。结算资格继承原发药的实际来源，第三方直接自购且原本排除CP结算的回收／销毁，在未发生后续CP实际接收再供之前继续排除，不产生无依据的CP结算负数；若之后走完CP接收再供，新的耗用按该次供货来源计入，此前排除记录不追改。仅申请退药、退款或标记失效均不触发该数量变化。

真实回收和之后销毁按各自实际发生日期进入相应期间；它们不是原发药录错，不改原发药日期或旧事实。跨期回收可使当期净结算数量为负，清楚显示并交Finance核对，不能强行归零、与另一药品抵消或自动退钱。原事件确属录错时才按前述归属及替代版本规则更正。

5.4 盘点、开账与更正

• 盘点： Staff 按地点、药品、批次登记实盘数和差异原因；PIC 审批前库存不变。保存盘点时的账面版本、时间和范围；期间发生收发时需重新核对并更新差异基准，不能拿旧差额直接覆盖新余额。批次跨多个来源层时明确差异分摊，无法确定的历史来源保留例外来源层，不能伪造普通可退额度。确认同时核对A／R／B及包装实物分段；盘亏侵入有效预留时，列出受影响任务，原子释放／失效不足的预留并要求重新分配，不能一律从A扣成负数。不可用量同样按真实实物核对，调账不自动解冻剩余实物。
• 开账： 采用预览 → 校验 → Staff 核对确认。行保存原始来源标识、源数量／单位、基本单位量、地点、批次、效期及可用性。以“药品＋地点”为一个开账范围，导入行可分批补齐，但范围内全部已知批次与数量核对完整后才一次确认并切换；不同完整范围可分别确认。身份／单位／批次／效期未明的范围显示“期初待完成”，不将部分数值或未知伪装成完整库存／零余额。已有有效账本的范围不再次开账；晚发现的漏项通过带原因的盘点调整及PIC审批处理。
• 切换权威来源： 按地点和药品记录完整开账集合及启用流水的切换时点；切换中的交易先核对到同一时点，不能同时进入期初和新流水。未切换范围不得在新账本过账或展示可供量。期初覆盖切换前存量，之后所有业务按流水入账。同步／Excel 导入可继续维护允许的主档字段，不能覆盖已启用账本的 H、R、批次或单位。切换前的历史发药不能再作为切换后新耗用扣一次。
• 更正： 已生效库存记录不删除、不改原数量；使用原业务关联的反向／补充流水，保存原因和前后关系。存在后续发出／耗用的收货不能直接整笔撤销，先校验实际来源余量并处理下游影响。普通录入差异回到原业务更正，盘盈亏走 PIC 审批，不提供一个任意改余额的通用入口。
• 幂等与并发： 状态版本、来源余额、换算、授权和剩余额度在提交时再次校验；业务单、流水、余额、预留和审计在同一事务生效。超量或冲突整体失败并保留输入，重试同一确认请求只返回既有结果。

5.5 库存查询与操作界面

Stock 表按授权地点显示药品、基本单位、现存、可用、有效预留、不可用；在途独立，不混在现存。批次详情显示批号、效期、来源性质（CP供货／诊所自采／CP再供）、来源收货、各状态量、已占用任务及已发未收记录。物理数量和状态用文字区分，不只用颜色。

Movements 显示业务日期、登记时间、类型、来源／目标、原数量单位、换算摘要、基本数量、关联单据和操作者。查看详情可回到同一收货／分发／耗用／退药对象，不创建第二张同义操作单。更正展示原记录与反向记录，不修改历史明细。

Returns 先选方向及来源实收；可退量为零的行说明原因。第三方／缺原 CP 实收切换为 Request exception，批准前不能 Confirm return。详情显示原单或批准版本、原始／基本数量、成功／失败、实际位置、库存影响和剩余替换额度。

Recalls 以批次任务为对象：原因与冻结范围 → 各地点影响／在途／已耗用 → Staff 联系与回收结果。PIC 发起操作与 Staff 跟进操作分开；数量回收打开同一退药表单，不能点“联系完成”自动移库。

Stock counts显示盘点基准、当前账面、实盘、差异、包装状态及原因；PIC看到期间变化和受影响预留任务并重核后批准，不能只审一个总差额。Opening import 复用授权导入框架，只在初始化工具显示；逐行预览单位解析、批次、来源及可确认／待补原因。

Consumption reconciliation显示诊所、期间、药品基本单位、各用途数量、来源分类、总耗用、可结算数量、排除／待核数量及Finance状态；提供查询报表／正式确认单区分、已归属明细提示和替代版本差异，下钻来源而非手改总量。只提供当前明确范围的导出，不加入付款、成本或 NetSuite 状态控件。

6. 回收退换、例外与批次召回

功能目的： 记录退药依据、接收决定和真实移动，并追踪批次问题。

使用者与对象： Staff／PIC 及接收方；原实收、Return、Exception、Recall。

操作与结果： 关联原单或先批例外 → 接收方决定 → 登记实际移动／替换 → 保留后续处置。

关键边界： 接收方接受才算成功；全内部范围召回／冻结权限暂缓。

6.1 正常退药的来源和上限

退药申请／审批状态与实际成功／失败结果分开。备注可以描述拆封、近效期、错订、损坏等原因，但不能代替药品、数量、单位、批次、效期和有效实收关联。

可退上限＝min(原实收量－该来源累计成功退量，当前地点该来源批次可转出实物量)。实存已扣过耗用，不再次减耗用；未实收的 PO 量不能退。不可用实物可按实际退回，但不得占用其他有效预留、借另一 PO 的来源层或用例外绕开已知数量上限。已有待办理退单须占用本次额度，取消／失败释放业务申请额度；但实物已送出则仍须真正收回后才能再次转出，不能把额度释放当成实存恢复。退药处理还须锁定对应实物分段，避免同一批可用或不可用实物同时被另一退单／供应任务占用；不可用退药占用不伪装成可正常供应的R。

内部往返保持采购根来源：供应商实收S10 → clinic实收C10 → 实际退CP4生成返回层R4，R保留C及S。之后向原供应商退这4时，按S的采购根核算额度、从CP当前R层扣实物。Clinic→CP与CP→供应商的退药额度分方向计算，前者的成功4不扣掉后者的可退采购量。既不能丢失新返回事实，也不能凭返回层重新生成一份独立采购额度。

6.2 成功、失败与替换货

09-09用户确认：接收方（CP或供应商）接受退药才算成功，仅已发出／送到不能自动成功或生成替换额度；被拒绝则按拒绝量失败。实际转出、接收、退药结果三者独立留痕，已登记对应出库／入库的环节不重复执行。成功退回CP的失效药保留实物数量但不增加可用量。失败不自动加回、扣除、销毁或恢复有效；“不支持退换”与“药品已失效”分开记录。

部分处理按数量分段，例如申请 10、成功 6、失败 4；终局仍为成功／失败，未处理量单列。失败量不占原实收的累计成功退量；实际销毁另登记耗用。实物已经在 CP 或供应商处时，失败结果必须显示真实位置与后续任务，不能按状态猜测位置。

成功量需有对应实际交付和接收方接受事实；提前同意办理属于待执行，不能凭口头同意先产生替换额度。申请量＝成功量＋失败量＋未处理量，已移动量另行展示，不与三者重复相加。实物已到CP但尚待判断或被拒绝的部分保留在不可用／待处理状态；后续实际退回clinic同样登记对应移动，不虚构“未收到”。原物退回发送诊所与CP实际再次供货分别保存移动目的；前者保留原来源结算性质，不能因药物经过CP地点便改记CP供货。

替换货单独关联原成功退单，记录新的实收／发出／clinic 实收和新批次，不以净额覆盖旧退药。同药换货的数量上限为成功退量－有效累计替换量；它不是对方已承诺换货，必须由人员选择本次办理换货并登记实际结果。clinic 换货发出时占额度，实收不再占一次；供应商换货在替换货实收时占额度。对同药、已验证可换算单位，按基本单位比对；不同药品不能按数量等价替换，改药／改价按 §3 新 PO 或关联新 clinic 申请办理，已实际履行部分保留。

6.3 缺 CP 原实收、历史来源和第三方采购例外

Staff 提交 → PIC 单独审批 → Staff 登记实际结果，不经过 Finance。诊所向第三方采购的药品交回 CP 必须走此例外，即使有第三方 PO，也不能当作原 CP 供货。§4.2的自采采购批准与本次退回例外分别保存；前者不代替后者，也不预先保证退药成功。新自采交易已有完整实收来源，例外仍需引用它，不能把“没有 CP 原单”误当成“没有任何库存记录”。

例外绑定方向、来源／目标单位、稳定药品 ID、录入单位与基本单位、批次／效期、数量上限、原因、第三方／历史来源、系统是否已跟踪该来源余额。Submitted 锁定版本；Approved／Rejected 保留审核人和原因；关键对象或上限变化重新申请。审批不移动库存。

批准只供本次不超过上限的实际处理一次，部分执行后的剩余授权结束；不得跨药品、跨诊所或重复套用。系统已跟踪的第三方clinic库存，按实际离开clinic／到达CP分别登记；在CP待处理或被拒绝但仍由CP保管的实物保留为不可用，结果不控制移动。未纳管的历史来源只记录外部来源首次进入CP，不制造虚假的clinic负库存。必须区分“没有跟踪来源”和“已跟踪但不足”，后者不能用例外跳过数量控制。

“一次”指批准绑定一个实际退药处理对象及其确认办理量，不是只允许一个按钮调用。该对象的发出、在途、分次实收、成功／失败及失败后真实回流可继续完成，各动作不重复消耗例外额度；不得另开第二张退单套用剩余授权。

6.4 批次召回

PIC选择稳定药品、受影响批次和已知供应来源，在已授权操作范围内填写原因、范围并发起。09-09用户决定：PIC覆盖CP、所有内部clinic及在途的全范围召回／冻结权限先不考虑，作为后续扩展暂缓；本期不新增全范围冻结开关、权限申请或跨范围自动审批／任务编排。此前已确认的基础召回、人工跟进和实物回收设计保留。

页面只呈现获授权资料，并明确本次实际可执行范围；权限外情况不能显示为零影响，也不能把局部处理标为“全集团已冻结／已回收”。范围外协调仍由人员线下处理，系统不自动越权写入或开放病历／其他业务资料。已按业务规则及授权标记的不可用状态仍按§5控制，不因暂缓扩展而清除。

冻结使受影响现存不可用并阻止继续分配／发药；保留受影响预留任务，提示重新分配。系统按来源与流水列出 CP 现存、各 clinic 实存、在途、已耗用及已回收量；只有真实收到才计为回收，不把联系成功当回收成功。

Staff 人工联系诊所、记录进展、实际回收成功／失败数量和原因；实物回收复用退药与库存路径，不建立第二个扣减接口。有原实收走正常关联，无原 CP 实收／第三方来源仍遵守例外审批。已被患者领走的药仅交由 clinic Drug Dispensing／临床团队后续处理，CP 不因此新增患者发药或跨诊所病历访问权限。

召回任务可结束跟进，但未回收量及原因必须保留；结束任务不自动解除冻结、恢复失效药或冲销库存。误选范围的更正由 PIC 留痕处理；是否可重新放行依实际质量判断，不把“已关闭召回”作为恢复依据。

7. 单位转换与登记契约

7.1 一个药品一个基本库存单位，多种可录入单位

基本库存单位是该药品在 CP 与 clinic 间共同记账的单位，不强制所有药品用片或盒。录入单位是本次下单、收货、发出、实收、耗用或退药使用的单位。剂量单位和药品含量属于临床语义，不能直接替代库存计数。

换算公式：基本数量＝录入数量 × 比例分子 ÷ 比例分母。多层包装解析为一个直接到基本单位的有效比例，禁止循环或同一版本存在冲突结果；只改展示单位时余额不变。原始单位代码与规范名称都保留，UUID／unit 未解析时显示待补映射，不能悄悄按片处理。

同一药品在 CP 用 BOX、clinic 用 TAB 时，先验证药品身份和包装关系再统一记账；未明确前不能把两个单位的数量直接相加。不同规格／含量／不可互换包装应保留独立库存商品身份，不只凭相同成分或名称合并。批次内可有不同来源的包装快照，来源分摊不丢失。

7.2 每次登记的交互

1. 选药品后带出基本单位和允许单位；优先选择来源单据单位，不再默认所有药品 box。
2. 输入本次实际数量，旁边即时显示“2 BOX × 30＝60 TAB”及来源／版本。正常量、赠品量分别转换，基本量合计只读。
3. 每个批次单独填实际数量和效期；表格列出原输入、换算后的库存量、可处理余量及确认后的增减摘要。
4. 缺关系时阻止该行按未知单位过账，提示主档维护人员补映射；若基本单位已可靠确定，可让人员直接按实物确认后的基本单位录入，保留原包装描述为备注，不伪装已存在自动换算。其他已验证药品不受影响。
5. 退药／更正从来源单据取得历史换算快照及当时基本量；不能用今天的包装比例重新计算过去一盒的数量。任何从既有库存发出／耗用的交易均按实际所选来源包装转换；旧30片盒与新28片盒可同时存在。新包装的采购／收货采用其有效映射，已提交PO保留对应版本；不是所有今天新建的交易都套今天最新比例。混合来源包装分别拆行，或按已核实基本单位录入。

拆包不是新增库存。 账上 60 TAB 的两盒拆开后仍是 60 TAB，登记拆封状态及需要的实际信息；发出 7 TAB 后才余 53 TAB。混合包装录入可表达 1 BOX＋7 TAB＝37 TAB，但不得把 37 TAB 默认显示为完整未拆封的一盒加七片而丢失实际包装状态。

来源层下至少区分未拆整包装数与已拆基本单位量；拆包按实际数量将一个完整包装转成已拆数量分段，基本总量不变。只有未拆包装实物足够，才能承诺按整包装发出；基本量除以换算系数只是等值量，不是完整包装数量。两瓶100 ML均拆封且各剩60 ML时，共120 ML但完整瓶为0，不能以足够100 ML就发出“1未拆BOT”。不默认建立逐瓶序列号；须按实际包装状态及适用质量期限区分必要分段，避免将不同有效期的已拆量混合。

对于液体，若药品已验证 1 BOT＝100 ML，则收到 2 BOT 入 200 ML、实际发出 15 ML 后余 185 ML；没有该商品容积依据，BOT 与 ML 不可互换。mg／dose 与 TAB／ML 的临床转换不是通用库存换算；库存接收药房已经确定的实际发药数量，不按处方剂量自动推导。

7.3 精度、变更与价格

• 产品设计以现有库存 4 位小数的数量精度为统一起点，采购、发药、收发、预留、退换、导入及接口全链无损。金额独立采用其价格／金额精度，不能用金额四舍五入函数处理数量。
• 比例使用精确十进制或分数，服务端 Decimal／数据库 NUMERIC 为最终结果；API 传递十进制字符串避免浏览器浮点误差。结果超过允许精度／范围或不符合商品步长时明确拒绝并要求有效单位／准确数量，不静默截断、凑整或记隐藏尾差。实际底表需要更多精度时，应统一扩展链路再纳入该商品，不由某一页面单独放宽。
• 已有交易／存量后不允许直接覆盖基本单位。名称标准化不改数量；包装比例变更形成新版本，只影响之后的交易。基本单位确需变更时走受控资料迁移和库存核对，不能用主档 Edit 触发隐含全账重算。
• PO服务端先计算计价数量＝普通订购基本数量÷每计价单位的基本数量，再按有效价格精度计算行金额＝计价数量×单价，汇总为单据金额。客户端金额只作比对，不能成为权威；审批和人工发送展示同一提交版本计算值。例2 BOX、30 TAB/BOX、10/ TAB应为600，不能直接用2×10得20。不同单位或货币不可直接混算，同一PO金额采用明确单一币种，不默认为跨币种自动换汇。PO按明确计价单位核算采购金额；库存增加实际正常量＋赠品量。零价格赠品仍有库存数量，不由金额除以单价倒推数量；本稿不定义加权成本、赠品成本摊销或 clinic 自动结算价格。

7.4 底表证据的使用边界

09-06 读取仓库 scripts/sql/2026-08-31-182736-database-postgres-backup.sql：CP 972 条、19 种单位，TAB 371、ML 116、CAP 102、VIAL 97、BOT 53、G 44、SYG 37、BOX 33、其余 119；clinic 15,782 条中 7,450 个单位值为 UUID、4,738 为 unit。单位字典及旧 from_unit_id/to_unit/to_qty 路径存在，但没有完整转换入账链。

这是历史导出，不是当前库存。CP 全部最后同步于 2026-07-28，971 条库存为 0，仅 5 条有有效期；当时未取得实时库存。PO、行及审批事件在该导出为 0 行，不提供真实交易样本。无专用赠品数量／关联字段的发现也限定于当时核对范围。本次代码证据见 §12，不能把历史样例比例、库存数或日期用于生产默认值。

7.5 药品单位配置界面

Drugs 复用 canonical 药品和 CP／clinic 来源映射，展示编码、名称、规格、基本单位及状态；详情分基本资料、允许单位／包装、来源映射和历史版本。单位行显示“1 BOX＝30 TAB”、来源、有效版本和步长；冲突标为不可用于新交易，不以猜测默认值填平。

Suppliers 维护稳定供应商身份、名称、联系人、订购联系资料和启用状态。现有供应商文字字段／performance 报表不能代替这一主档。新药品经基本单位与必要映射验证后方可用于交易；停用停止新选择，已发生的单据和库存仍可追溯处理，不清零历史。

共享价格维护回到权威 Catalogue／价格入口，PO 保留交易快照；CP不另建第二份集团价格。低频设置入口位于标题右侧，只有有真实配置对象及权限才显示，不放占位齿轮。

8. 设计验算与后续验收场景

以下为合成场景和目标断言，未执行的应用验收清单；旧 v0.3 演示通过不表示本版已实现。

后续应用验收按项目规定使用本地完整服务链、Docker 内 Playwright 与官方完整 Chrome，保留实际版本、截图／录像／trace、控制台和接口错误证据。文档构建、交互演示、真实账本联调、部署及 UAT 分开计证。

9. 设计状态和本期边界

主流程、审批归属、必填收货信息、召回责任、数量对账及权限可见范围已经确认；09-09随后新增确认诊所自采须先由CP PIC单级同意、诊所直接下单并自行入库，已补入§4.2和对应界面／库存契约。这项采购批准不替代未来退药例外。上述业务决定不再放入“待用户确认”清单。09-09反例检视及随后逐项确认：第三方直接自购耗用排除CP结算，CP赠品和第三方经CP再供后的耗用计入；患者实际回收扣减、之后销毁计入；接收方接受退药才成功；原批准药品的额外赠品可由Staff直接验收；CP采购PO提交人、PIC审核人及Finance审批人必须三人分离。§3–§7、§10–§13的状态恢复、来源层、事务、精度、版本、入口和字段契约，是为实现这些决定提出的产品／工程设计，不宣称用户逐个确认了字段名或实际代码已有功能。

本轮复核提出的六项业务取舍已完成处理：耗用归属、患者实际回收、额外赠品接收及审批人员分离的确认已归入正文；最后一项全内部范围召回／冻结权限由用户明确暂缓，见§6.4，不再列为本期阻塞问题或继续追问。暂缓不代表已授权，也不删除已确认的基础召回设计。

本次直接补齐的逻辑包括：PO撤回／终止和关闭后到货出口、clinic取消释放分配、按单位接手、盘亏处理预留、采购根来源往返、整包装校验、跨单位核价、多批次发药及付款后来源恢复、对账唯一归属与更正版本。它们是设计闭合，不是新增已上线功能。

本稿完善产品方案与页面定义，不修改业务代码、真实角色授权或库存数据。仍有少量 SOP／资料待补：供应商资格资料、COA／冷链证明的适用条件与必填范围；最低剩余效期、拆封后的质量处理规则；实际销毁的留证及操作要求。这些没有已确认数值，不预设附件必传、自动放行或额外审批人；按当前严格的批次／效期及不可用控制设计，实施前由业务提供适用标准。

真实药品转换、机构映射、期初批次完整性属于实施数据核对工作，不再要求用户逐药解释；未明行显式阻断，其余可继续。NetSuite 实际打通、OCR 自动过账、自动补货、复杂财务成本与多仓库仍不在本版设计范围。

10. 角色、可见范围和动作权限

10.1 目标操作矩阵

现有角色沿用 wdl-pharmacy-staff、wdl-pharmacist-pic、后台 Finance 和 Clinic Pharmacy；具体动作授权须按此目标补齐，不能仅靠 App 可见性。

普通CP收发及有原单退药不额外插入采购审批；PIC、Finance的采购决策与退药例外／盘点审批是不同任务。所有审核必须校验当前节点、版本及真实审核用户。CP自身采购PO按§3.1校验提交人、PIC和Finance三人分离，不能用切角色绕过；诊所自采按§4.2仅PIC单审，普通收货／分发不增加三人审批流程。CP PIC可查看被路由到其授权任务范围的诊所自采单据和采购快照，不由此获得诊所患者资料或自行修改收货权。

10.2 Clinic 库存数量展示

Clinic Pharmacy 的库存视图固定显示 My clinic 和 Central Pharmacy 两个范围，CP 展示实际数值、明确单位与更新时间，建议并列 On hand／Available，避免把预留和不可用数当作可供量。不得退化为只有“有货／无货”。本诊所可下钻获授权来源与自身流水；CP 数量是用于申领的只读供货信息。

CP 数量接口只返回许可的药品和数量投影，不返回其他诊所分项、其他诊所库存合计、占用者／患者、采购价格、供应商合同或他所流水。搜索建议、筛选计数、导出、直链和接口也遵守相同范围；不能先把全量数据传到浏览器再隐藏列。查询失败／尚未建立账本显示未知和原因，不显示为零。

WDL 人员按获授权内部供货范围看 CP 及相关 clinic 库存；Finance 只看其已授权来源范围的 PO／对账。库存读取不是患者资料访问许可，也不是扩大后台到全集团范围的理由。

10.3 会话和只读

工作区持续显示有效单位与角色；切换清除旧范围数据、选择和未授权动作，保护未保存输入。所有详情、选择器、写入及导出在服务端用真实会话检查集团／单位和动作，不能相信请求中的 operating_unit_id 或客户端筛选。

Restricted support 优先禁止业务写入，包括已打开表单、价格快照写入、导入、审批及库存动作。read_only_clinical 不是 CP 全只读；unrestricted 功能测试的成功不能当作真实 Staff／PIC 权限证据。旧独立原型的角色开关仅为演示，不接入生产权限。历史 Membership 的后台兼容与账户治理遵循平台规范，不在 CP 另建账号体系。

11. 共用交互与反馈

11.1 共用反馈与显示

遵循 Desktop UI Design System §4、§8、§9：复用 AppWindow、Element Plus 表格／表单、AppDialog、Iconify、Tailwind 和共享主题；文案默认英文，正文14px、数量右对齐且单位清楚。白底紧凑标题和工作面板，6／8／12px语义圆角，不复制旧 CP 的局部装饰样式。

状态筛选与搜索紧邻列表；New 在标题动作区，Save／Confirm 在所属任务底栏，一个区域一个主动作。长药名、单位、效期和确认按钮在1280px、1366×768及窄窗口可读可达；表头／底栏固定时只滚主体。错误、未知、无权、无匹配和真实零库存分别显示。

前端预测数量不代替服务端结果。提交前摘要、冲突原因、输入保留、未保存保护、键盘焦点和完成后的来源记录均需具备；权限或版本变化后禁止使用旧表单继续写入。

12. 结合当前代码结构的实施差距

代码核对：2026-09-09已fetch origin/dev/theron-li与origin/stg；本稿业务代码基线为8080158，包含当时STG b01f6fc。本次另只读复核最新STG 99421d2，本次新增自采所依赖的CP采购服务、Clinic目录来源及API相关语义相对8080158未变；clinic_direct仍是目录优选，尚无采购／收货流程。下表其他库存链差距沿用此前af72fb2只读核对证据，引用行号仍基于8080158（最新STG的db_init后段+32、clinic_workflow相关段+144）。下列为代码事实，非实时数据库、部署或UAT证明；不宣称本工作树已合入后续STG。

12.1 能复用什么、缺什么

初始化权限只是代码默认，部署数据库可能有历史／人工授权，必须用实际会话验证。现有价格 approval-records、临床 return-to-doctor 都不能当作本版实物退药例外审批。临床批号文本和效期记录也不等于已经关联真实批次库存。

12.2 按现有分层落地

• Vue： 保留 CPWarehouseWorkspace.vue 作为 App 入口，将本版三个工作区拆成业务组件；API 继续通过 varclip_vue/src/api/cpWarehouse.js，按钮读取真实会话权限与任务状态。复用单一数量／单位输入组件与来源批次选择器，前端不独立维护权威余额。
• Flask： 沿用 blueprints/central_pharmacy/routes.py 注册路由、service承接校验和事务；采购审批、库存过账、单位解析／快照和查询投影分清责任。CP采购与诊所自采的类型、审批链和收货单位由服务端确定；单级旧API不可让客户端任选审批链绕过CP Finance。创建／读取／写入均校验当前业务单位，不只在列表使用客户端过滤条件。
• 数据库： 在 db_init.py 补bootstrap定义，并提供既有数据的可重复执行迁移／校验；不能只有新库schema。保留canonical映射、来源稳定ID、PO原行与版本，新增实体按§13关联，不删除被引用历史行。
• 跨模块： 药房执行把实际数量与来源键交统一库存服务；Finance查询同一版本对账／PO；主档同步有字段白名单与账本切换控制。跨服务消息需有持久的去重与失败状态，不能“发药成功但库存失败”静默丢单或重复补扣。
• 实施顺序： 先稳定药品／来源／单位及精度，再开账与统一过账；并行补PO双审和单据详情；然后接CP收货→分发→clinic实收及诊所自采PIC审批→本诊所直接实收，两条来源再汇合真实耗用，再完成退换／召回／盘点／数量核对及范围验证。任何尚未接入真实台账的页面继续明确数据来源，不将旧stock查询伪装成新账本。

13. 数据对象、来源链与历史依据

以下为需要满足的逻辑契约，字段名及表名由工程在既有结构中实现，非已经存在的完整schema。

OUT／IN或调用重试共享业务关联，但每个合法动作有各自唯一过账标识。原请求相同内容重试返回既有结果；同一幂等键换内容应拒绝。导入来源行ID、正常实收来源和例外首次纳管来源分开，不能为了建立FK伪造一张历史采购单。

13.1 已核对的历史药品与机构样本

以下仅为09-06核对的历史导出和原型取材证据，不是本次实时库；数值ID不跨环境硬编码。

药品业务身份以 cp_drug_master.id 为 CP 本地键，保留 legacy_drug_id、drug_master_id 和供应目录映射；clinic_drug_code 是展示／来源编码。972 条均有关联映射，但名称存在重名，不能用名称 join，也不能把页面显示码当作所有环境中的全局 ID。

名称含 CAP、mg、500ML 或 21'S 不构成换算规则。最后一项按 BOX 计数；第三项按 ML 计数。库存录入支持源数据的小数精度，显示明确单位；赠品按§3、§7独立记录并转换到对应商品的基本单位。实际生产实现应统一数量精度，不以前端浮点运算作为账务最终依据。

机构来源为 clinic_operating_units：快照共 25 条，含 23 个 clinic、一个 CP、一个 Group Admin。原型选择下列真实机构样本，不使用无主档依据的“Kowloon Clinic”。

单据保存集团与 operating_unit_id，选择器只显示当前有权操作的内部机构，不让管理员机构进入临床收货目的地。跨环境迁移使用集团＋unit_code 或经核对的 legacy UUID 映射；ID 数值和名称均不能跨环境直接假定一致。CP 同步源 UUID 与 OperatingUnit 的 legacy 字段尚无直接对应证据，不假装已有自动 join。

14. 单据关联与端到端核对

flowchart TD
  P[CP供应商 PO 稳定行＋版本] --> A[PIC事件＋Finance事件]
  A --> S[人工发送记录]
  S --> R[CP实收行＋单位快照]
  R --> C[CP来源批次层]
  Q[Clinic申请行] --> D[实际分发行]
  C --> D
  D --> I[Clinic实际实收行]
  I --> K[Clinic来源批次层]
  DP[诊所自采PO行＋版本] --> PA[PIC单级采购批准]
  PA --> PS[诊所人工发送记录]
  PS --> PR[本诊所供应商实收行＋单位快照]
  PR --> DK[诊所第三方来源层]
  DK --> U
  PR --> X
  K --> U[实际发药／废弃来源分摊]
  U --> F[数量对账版本＋Finance确认]
  I --> T[Clinic退药行]
  R --> TS[供应商退药行]
  E[无CP原实收／第三方来源] --> X[Staff例外版本 → PIC审批]
  X --> T
  X --> TS
  T --> L[关联库存流水]
  TS --> L
  L --> H[余额、在途与审计]

订单详情的 Create return 和 Inventory → Returns 打开同一张表单；更改机构、药品或单位关系时，清除不再匹配的来源选择。只有有效实收及尚可办理来源可选，文本单号不替代关联。审批完成返回原单；实际办理后显示过账结果与可追溯记录。

核对的重点是原数量和实际结果能否一路追溯：CP PO原行 → 实收 → CP来源 → 分发／clinic实收 → 耗用或退药；另一条为自采PO行 → PIC批准 → 供应商发送 → 本诊所直接实收 → 自采耗用或单独例外退CP。每笔都保留实际来源及审批用途。任意环节出现重复来源、未知单位、变更版本或过期授权，均在提交点阻断并解释恢复步骤。

15. 文档、原型与验收的边界

本文件是唯一CP日常产品规范。代码／底表精确位置以本稿§12所注明提交为准；后续实施需重新fetch核对。领域之外的权限、临床门禁、财务工作台和共享UI通过链接引用，不逐轮复制完整正文。

历史原型及说明保留v0.3当时的模拟资料、演示步骤和实际验证。它仅在浏览器会话内算数，不读写真实库存、不发邮件、不连接NetSuite；旧CP自身采购PIC单审、旧权限演示及部分交互不符合本版全部要求。旧验证结果不重写成本版已通过。

本轮仅文档构建／链接及规则一致性核对；应用开发、完整本地链路测试、开发分支发布、App预览、PRD发布、STG／UAT分别记录。发布方法见 PRD preview README。本稿不以文档发布证明收货、来源台账或Finance双审已经上线。

16. App入口收敛及现有工作台边界

09-06已按用户要求，将CP Warehouse、Pharmacy (WDL)、重复Inventory及WDL规划壳收敛为 Central Pharmacy，沿用canonical ID central-pharmacy-warehouse；旧布局迁移到同一入口。后续桌面分类以 组织与权限产品方案 为准，不恢复重复App。

现有 CPWarehouseWorkspace 的 Stock catalogue 是CP同步目录和汇总字段查询；其他查询／采购标签不等于本版 Orders／Inventory／Master Data 已完整落地。Staff／PIC读取当前会话动作权限、没有权限不请求数据及清除旧角色数据属于已有基础；新的细粒度操作与数量视图仍需后端验证。

Drug Dispensing保留患者药房工作区，并以独立Clinic orders／Stock标签承接§11.1的诊所供货需求；Clinic只查看CP数量不会获得Central Pharmacy管理入口，也不新增另一个Inventory维护同一余额。

17. WDL、Clinic Pharmacy、Finance与其他领域交接

WDL承载CP仓储、自身供应商采购及供货执行，并由PIC审批获授权的诊所自采申请；Clinic Pharmacy承载本诊所向CP申领、获批后向供应商自采／自行收货和患者药房工作。CP Staff代诊所提交PO时保持Staff角色，按§4.1明确的目标诊所及采购动作授权执行；不获得患者发药权限，真实登录身份始终保留。这取代旧稿“业务来自clinic也始终留WDL操作患者处方”的泛化规则，不改变WDL仓储归属。

Finance仍统一在后台，按授权来源打开CP自身采购PO的第二级审批和耗用数量对账；诊所自采PIC通过后即可执行，不纳入该第二级审批，价格维护遵循共享Catalogue授权。Finance不会自动继承收发、盘点、召回或临床写权限；完整双审动作与数量对账界面属于本版待实现目标。患者附件、Day-end Revenue Report及后台Membership兼容采用其canonical规则，本稿不重定义其范围。

• Pharmacy／V-Lab：审方、真实库存预留、结算门禁、备药复核、患者发药与取消／退回；CP供货及数量服务接入同一来源。
• Catalogue：稳定药品／商品与价格权威；CP记录实际库存和单位版本，不建第二套价格主档。
• Cashier：患者收费／付款和已确认收入报告；CP数量对账不自动产生这些财务动作。
• 组织与权限产品方案：单位／角色／动作、患者与商业资料最小授权和审计；供应目录可见不能替代库存数量权限。
• NetSuite仅保留稳定业务ID、来源和未来映射所需的接口边界，不展示虚构的连接成功、同步状态或本期自动对账按钮。