# 需求 - 统一审批中心规约

**版本**：1.2
**日期**：2026-05-11
**状态**：模块级开发规约
**上级事实源**：[海音达OA-MVP需求规格说明书](./海音达OA-MVP需求规格说明书.md)

本规约细化 `hyb-oa` 统一审批中心的产品边界、角色权限、状态模型、异常规则、留痕要求和验收场景。后续审批相关开发必须先从本规约拆分 Issue CSV，再进入技术方案和代码实现。

---

## 1. 模块目标与边界

### 1.1 目标

- `hyb-oa` 是公司唯一业务主系统和唯一正式审批中心。
- 所有正式审批在 OA 内提交、审批、留痕、归档。
- PC、移动端和企业微信入口看到的是同一批审批任务和同一套审批记录。
- 企业微信只做入口、身份、通知和 deeplink；审批动作必须回到 OA 页面完成。
- R5 已在公网验证企业微信工作台入口、免登录、个人应用消息通知和移动审批回流；R6 之后继续沿用“OA 内审批、企业微信提醒回流”的正式口径。

### 1.2 适用对象

首批及后续默认纳入 OA 审批中心的正式审批包括：

- 报销审批。
- 请假、补卡、外出、加班、出差等考勤相关审批。
- 采购审批。
- 费用审批。
- 合同审批、合同变更审批和合同归档相关审批。
- 资产领用、归还、调拨、盘点中需要正式留痕的动作。
- 后续新增业务审批，除非另有明确产品决策，否则默认接入统一审批中心。

### 1.3 暂不做范围

- 不使用企业微信原生审批作为公司正式审批流。
- 不接入飞书登录、飞书审批、飞书通知或飞书项目管理。
- 首批不做复杂 BPM 设计器、自由拖拽流程、并行会签、条件分支可视化建模。
- 首批不做跨公司多租户审批市场化配置。
- 首批不做审批动作离线处理；移动端必须在线提交动作。

---

## 2. 角色与权限

| 角色 | 典型用户 | 可做动作 | 权限边界 |
| --- | --- | --- | --- |
| 申请人 | 普通员工、主管、财务、HR | 创建草稿、提交、查看自己的单据、撤回允许撤回的单据、按退回意见修改后重提 | 只能编辑草稿、已退回、已驳回且规则允许重提的本人单据；当前不允许审批自己的待办；未来如需自审例外，必须另拆规则并强审计 |
| 审批人 | 主管、项目负责人、老板、被转审人 | 查看分配给自己的待办，通过、驳回、退回、转审、查看审批历史 | 只能处理当前分配给自己的任务；不能越权处理他人待办 |
| 财务 | 财务人员、财务主管 | 处理报销复核、付款标记、财务导出、重复发票例外审批中与财务相关的动作 | 不默认拥有系统管理权限；财务例外动作必须留痕 |
| HR/行政 | HR、行政负责人 | 处理请假、补卡、外出、加班等行政审批或复核；维护基础人员与组织配置 | 不能绕过审批流直接改业务结果，必要修正必须审计 |
| 老板/总经理 | 公司负责人 | 处理大额、高风险或最终节点审批，查看公司级待办和摘要 | 操作仍需写入审批历史和审计日志 |
| 系统管理员 | 运维或后台系统负责人 | 配置角色、权限、企业微信入口、通知、基础字典和功能开关 | `admin` 只代表系统管理权限，不自动获得业务单据审批权；直接数据修复必须另有运维流程和审计 |

权限判定以服务端为准，前端按钮显隐只是体验优化，不作为授权依据。

### 2.1 权限与数据范围矩阵

| 角色 | 可查看范围 | 可审批范围 | 附件下载 | 导出 | 例外处理 |
| --- | --- | --- | --- | --- | --- |
| 申请人 | 本人发起、本人作为实际报销人、抄送给本人的单据 | 当前不可审批自己的待办；未来如需自审例外，必须另拆规则并强审计 | 草稿和本人单据附件；审批中及归档附件按业务权限展示 | 不允许批量导出 | 不允许 |
| 审批人 | 分配给自己的待办、已办和自己审批链上的单据 | 当前分配给自己的任务 | 可查看审批所需附件，下载动作需留痕 | 不允许财务级导出 | 可转审，不可财务例外 |
| 财务 | 报销、费用、付款、发票相关单据和财务导出范围 | 财务复核节点、重复发票例外节点、付款相关节点 | 可查看和下载财务复核所需附件，敏感附件下载留痕 | 可按权限导出财务台账 | 可处理重复发票、付款修正等财务例外 |
| HR/行政 | 人员、部门、请假、补卡、外出、加班等行政范围 | HR/行政复核节点 | 可查看行政审批所需附件 | 可导出行政审批统计，不能导出财务明细 | 可处理审批人停用、规则缺失等管理例外 |
| 老板/总经理 | 公司级摘要、大额或高风险审批、关键业务单据 | 最终审批节点或指定高风险节点 | 可查看决策所需附件，下载留痕 | 可查看公司级摘要，批量导出按配置控制 | 可审批高风险例外，但仍需记录原因 |
| 系统管理员 | 系统配置、日志、权限、集成状态 | 默认不具备业务审批权 | 技术排障需最小化授权并留痕 | 默认不导出业务数据 | 可做账号、规则、通知配置修复；业务数据修正需另走审计流程 |

数据范围以服务端权限和审计日志为准。任何导出、附件下载、例外处理都必须记录操作者、时间、对象和原因。

### 2.2 角色视图与动作裁剪

统一审批中心使用同一套 OA 审批数据、任务和历史记录，但 PC、移动和企业微信入口应按角色裁剪入口、摘要、动作和敏感信息。角色视图只影响展示和操作便利性，不改变服务端权限模型。

| 角色视图 | 重点入口与摘要 | 允许突出动作 | 不应展示或必须隐藏 |
| --- | --- | --- | --- |
| 员工视图 | 新建、草稿、审批中、退回修改、通知、我的申请 | 保存草稿、提交审批、撤回、按退回意见重提、查看本人状态 | 管理配置、全量人员、财务付款、他人待办审批动作 |
| 审批人视图 | 待处理、已处理、审批详情、附件/发票摘要、审批历史 | 通过、驳回、退回、转审、查看审批记录 | 无关员工列表、财务后处理、未分配给自己的审批按钮 |
| 财务视图 | PC 端财务复核、付款状态、导出、重复票据例外；移动端只保留必要复核和查看 | 财务复核、付款标记、财务导出、重复发票例外处理 | 系统管理能力、非财务业务审批权、无审计的敏感附件下载 |
| 管理员视图 | 系统配置、账号、角色、组织、通知渠道、审计日志 | 配置修复、账号启停、角色分配、通知渠道测试、审计查询 | 业务审批按钮；除非同时具备正式业务角色且不是自审，不得处理业务待办 |
| 负责人视图 / CEO 视图 | 高额、高风险、例外待办，公司级摘要，审批效率和风险概览 | 处理分配给自己的最终审批或例外审批，查看高风险摘要 | 本人单据自审、仅凭 `admin` 权限处理业务、无配置依据的全量业务操作 |

移动端也遵循上述角色视图，但不为每个角色做完全不同的页面体系：同一移动 Shell、列表卡片、详情分区、顶部返回和吸底主操作框架下，按权限显示不同内容和动作。前端隐藏无权动作只是体验优化；服务端仍必须拒绝越权、自审和状态非法操作。

### 2.3 正式审批组织与角色映射

正式运行和 R5 真机验收按以下组织口径执行；实现不得把个人姓名硬编码到业务逻辑中，应通过员工、直属上级和角色配置落地。

| 人员 | 正式角色口径 | 配置要求 | 审批边界 |
| --- | --- | --- | --- |
| `majianyong` | 员工可见的直属主管 / `manager` | 普通员工直属主管配置为 `majianyong` | 处理普通员工低/中额单据和日常审批；本人申请不得自审 |
| `wangshunli` | 后台公司负责人 / `ceo + admin` | 配置为 `ceo` 和 `admin`，不配置为普通 `manager` | 处理大额、高风险、例外事项和 `majianyong` 本人申请；本人申请不得自审 |
| 专用测试员工 | 普通员工 / `employee` | 直属主管配置为 `majianyong` | 用于正式链路验收，不使用真实员工日常账号跑自动化 |

正式员工必须配置直属主管。缺直属主管、主管停用、主管链断裂或审批节点解析到申请人本人时，应阻断提交或阻断审批动作，并提示管理员修正组织或审批规则。不得用 `admin` 权限解释业务审批权，也不得用无条件升级 CEO 掩盖主数据错误。

---

## 3. 入口与任务视图

### 3.1 入口

| 入口 | 路径或位置 | 用途 | 要求 |
| --- | --- | --- | --- |
| PC 审批待办 | `/workflow/tasks` | 审批人集中处理待办、已办、抄送或历史任务 | 应在 PC 主导航清晰可达 |
| 移动审批 | `/mobile/approvals` | 手机端处理待办和查看审批历史 | 应适配企业微信 WebView 和普通手机浏览器 |
| 业务详情页 | 报销、请假、采购、合同等详情页 | 从具体单据查看审批流和执行动作 | 状态、当前节点、历史记录必须与待办一致 |
| 企业微信消息 | deeplink 到 OA 页面 | 只做提醒和跳转 | 不在企业微信原生审批里完成正式审批 |
| Portal 待办摘要 | `/portal` 或首页卡片 | 提醒当前待处理数量 | 点击后进入 `/workflow/tasks` 或对应详情页 |

### 3.2 任务列表要求

- 待办列表至少展示：业务类型、业务编号、标题或摘要、申请人、金额或天数等关键值、当前节点、到达时间、状态。
- 移动端列表应优先展示业务类型、编号、申请人、状态和主要金额/天数，不展示桌面宽表。
- 已办或历史列表应能查看处理结果和处理时间，但首批不要求复杂筛选。
- 待办数量、单据详情状态、审批历史必须一致。

---

## 4. 审批对象与字段

统一审批中心对所有业务单据抽象以下通用字段，具体业务可扩展自己的字段。

| 字段 | 含义 | 要求 |
| --- | --- | --- |
| `business_type` | 业务类型，如报销、请假、采购、合同 | 必填，用于路由、权限和列表展示 |
| `business_id` | 业务单据主键 | 必填，与业务表关联 |
| `business_no` | 业务编号，如报销单号、采购单号 | 必填，OA 生成或校验唯一 |
| `title` | 审批摘要标题 | 必填，用于待办和通知 |
| `applicant_id` | 申请人 | 必填 |
| `department_id` | 申请人所属部门 | 可空但推荐保留 |
| `project_id` | 关联项目 | 业务需要时填写 |
| `amount` | 金额类摘要 | 报销、采购、费用、合同等需要 |
| `current_status` | 当前业务状态 | 必须与工作流状态同步 |
| `current_task_id` | 当前待办任务 | 审批中必须存在 |
| `submitted_at` | 提交时间 | 提交后必填 |
| `completed_at` | 审批完成时间 | 通过、驳回终止、撤回终止或完成时填写 |

---

## 4.5 审批规则配置矩阵

以下金额和天数是 10 人以下公司试运行建议值，不等于最终公司财务制度。正式上线前可由管理员按公司制度配置，后续实现不得把这些阈值硬编码在业务逻辑中。

| 业务类型 | 试运行阈值 | 默认审批链 | 财务/HR 复核 | 兜底审批人 | 撤回 | 转审 |
| --- | --- | --- | --- | --- | --- | --- |
| 报销/费用 | `<=500` 元 | 直属主管 | 无财务节点，财务可事后抽查 | 老板/总经理 | 审批完成前允许撤回 | 允许转给同级或上级审批人 |
| 报销/费用 | `500-3000` 元 | 直属主管 | 财务复核 | 老板/总经理 | 财务复核前允许撤回 | 允许转给具备审批或财务权限的人 |
| 报销/费用 | `>3000` 元 | 直属主管 -> 老板/总经理 | 财务复核 | 老板/总经理 | 老板审批前允许撤回 | 允许转审但不得绕过老板或财务节点 |
| 采购 | `<=1000` 元 | 直属主管 | 视费用类型抽查 | 老板/总经理 | 审批完成前允许撤回 | 允许转给项目负责人或上级 |
| 采购 | `1000-5000` 元 | 直属主管 -> 老板/总经理 | 视付款方式财务复核 | 老板/总经理 | 老板审批前允许撤回 | 允许转审但不得绕过老板节点 |
| 采购 | `>5000` 元 | 直属主管 -> 老板/总经理 | 财务复核，建议关联合同或附件 | 老板/总经理 | 老板审批前允许撤回 | 允许转审但必须保留原因 |
| 请假 | `<=1` 天 | 直属主管 | 无 | HR/行政 | 开始时间前允许撤回 | 允许转给上级或 HR/行政 |
| 请假 | `>1` 天 | 直属主管 | HR/行政复核 | 老板/总经理 | HR 复核前允许撤回 | 允许转给上级或 HR/行政 |
| 补卡 | 所有 | 直属主管 | HR/行政复核 | HR/行政 | 审批完成前允许撤回 | 允许转给 HR/行政 |
| 外出 | 所有 | 直属主管 | HR/行政按需复核 | HR/行政 | 审批完成前允许撤回 | 允许转给上级或 HR/行政 |
| 加班 | 所有 | 直属主管 | HR/行政复核 | HR/行政 | 审批完成前允许撤回 | 允许转给上级或 HR/行政 |
| 合同 | 所有 | 负责人主管 -> 老板/总经理 | 财务按金额或付款条款复核 | 老板/总经理 | 老板审批前允许撤回 | 允许转审但不得绕过老板节点 |

规则匹配优先级为：业务类型 -> 金额或天数阈值 -> 项目/部门特殊规则 -> 默认规则。若找不到审批人、缺直属主管、主管链断裂、审批人停用或节点解析为申请人本人，提交必须阻断并提示管理员修正组织或审批规则，不得生成半截流程。

大额、高风险或例外事项默认进入老板/总经理节点；当前试运行最小集合包括：重复发票例外、预算或费用标准超限、缺必要附件仍需例外处理、涉密或重点项目、合同/采购高金额事项。具体阈值和例外条件必须通过审批规则配置，不得硬编码到个人或前端按钮。

---

## 5. 状态模型

### 5.1 通用状态

| 状态 | 含义 | 允许的主要动作 |
| --- | --- | --- |
| 草稿 | 申请人正在编辑，未进入审批 | 保存、提交、删除草稿 |
| 审批中 | 已提交，存在当前审批任务 | 审批人通过、驳回、退回、转审；申请人在规则允许时撤回 |
| 已通过 | 所有审批节点通过，进入业务后处理 | 财务付款、合同归档、考勤生效等业务动作 |
| 已驳回 | 审批人否决，流程终止或允许复制重提 | 查看历史、按业务规则重新发起 |
| 已退回 | 审批人要求申请人修改 | 申请人修改后重提、撤回 |
| 已撤回 | 申请人撤回，流程终止 | 查看历史、按业务规则复制重提 |
| 已完成 | 审批通过后的业务处理完成 | 查看、归档、导出 |
| 已付款 | 报销或费用类单据已付款 | 查看、导出；普通用户不可修改 |

`已付款` 是报销、费用等财务类业务的完成状态之一；非财务业务可使用 `已完成`。

### 5.2 状态转换规则

- 草稿只能由申请人或授权代填人提交。
- 提交成功后生成工作流实例、当前节点和第一条待办。
- 当前审批人通过后，系统按规则推进到下一节点；无下一节点时进入 `已通过`。
- 驳回默认终止当前流程，是否允许复制重提由业务模块决定。
- 退回回到申请人修改态，重提后应保留同一业务单号和完整历史。
- 撤回只允许在流程未完成且规则允许时发生。
- 转审只改变当前任务处理人，不改变业务单据申请人。
- 已完成、已付款、已归档类状态原则上不允许普通用户修改核心字段。

### 5.3 状态流转表

| 当前状态 | 动作 | 操作者 | 目标状态 | 是否保留单号 | 是否生成新版本 | 是否通知 |
| --- | --- | --- | --- | --- | --- | --- |
| 草稿 | 保存 | 申请人 | 草稿 | 是 | 否 | 否 |
| 草稿 | 提交 | 申请人 | 审批中 | 是 | 是，记录提交版本 | 是，通知首个审批人 |
| 审批中 | 通过但还有下一节点 | 当前审批人 | 审批中 | 是 | 否 | 是，通知下一审批人 |
| 审批中 | 最终通过 | 当前审批人 | 已通过 | 是 | 否 | 是，通知申请人和后处理角色 |
| 审批中 | 驳回 | 当前审批人 | 已驳回 | 是 | 否 | 是，通知申请人 |
| 审批中 | 退回 | 当前审批人 | 已退回 | 是 | 是，等待申请人修改 | 是，通知申请人 |
| 已退回 | 修改后重提 | 申请人 | 审批中 | 是 | 是，记录重提版本 | 是，通知首个审批人 |
| 审批中 | 撤回 | 申请人 | 已撤回 | 是 | 否 | 是，通知当前审批人 |
| 审批中 | 转审 | 当前审批人 | 审批中 | 是 | 否 | 是，通知被转审人 |
| 已通过 | 财务付款或业务归档 | 财务或业务负责人 | 已付款或已完成 | 是 | 否 | 是，通知申请人 |
| 已完成/已付款 | 管理修正 | 授权管理员或财务主管 | 保持已完成/已付款并追加修正记录 | 是 | 是，记录修正版本 | 按敏感级别通知 |

撤回、退回、驳回后的重新发起策略由业务模块决定；报销场景默认保留原单号用于退回重提，驳回后复制新单据时应生成新流程并关联原单据。

---

## 6. 审批动作

| 动作 | 发起人 | 前置条件 | 结果与留痕 |
| --- | --- | --- | --- |
| 保存草稿 | 申请人 | 有创建权限 | 写入业务草稿，不生成审批任务 |
| 提交 | 申请人 | 必填字段、附件、金额、发票等业务校验通过 | 生成工作流实例、待办、提交历史和通知 |
| 通过 | 当前审批人 | 任务未处理且权限匹配 | 当前任务完成，进入下一节点或业务通过 |
| 驳回 | 当前审批人 | 必填驳回原因 | 流程终止或进入业务定义的驳回态 |
| 退回 | 当前审批人 | 必填退回原因 | 任务回到申请人修改态，保留历史 |
| 撤回 | 申请人 | 流程未完成且业务允许撤回 | 流程终止或回到草稿，写入撤回原因 |
| 转审 | 当前审批人 | 目标人具备处理资格，未超过转审限制 | 当前任务转给目标人，记录转审链路和原因 |
| 批量审批 | 审批人 | 多个任务均可被当前人处理 | 每个任务独立校验、独立成功或失败 |
| 查看历史 | 相关人员 | 对单据有查看权限 | 展示提交、审批、退回、转审、通知和关键业务动作 |

批量审批不得绕过单条任务的权限、状态和业务校验。

### 6.1 自审与转审约束

- 自审默认禁止，不因申请人同时拥有 `admin`、`manager`、`ceo`、`finance` 或其他角色而放开。
- 自审识别至少覆盖：工作流提交人、报销实际报销人、报销提交人、请假人、采购申请人、采购提交人、差旅申请人和差旅提交人。
- 批量审批必须逐条执行自审校验；自审任务失败不应影响其他合法任务处理。
- 转审目标必须具备对应业务审批权限，不能是申请人本人，不能是仅具备 `admin` 的系统管理员。
- 转审不能绕过规则定义的必经老板/总经理、财务或 HR/行政节点；需要例外时必须另走明确改派或规则调整流程并留痕。
- 若老板/总经理本人提交的单据触发老板/总经理节点，默认阻断或进入明确配置的非本人兜底审批人；本规约不开放自审例外。

---

## 7. 异常规则

| 异常 | 处理规则 | 用户提示 |
| --- | --- | --- |
| 无审批人 | 提交时阻断，不生成半截流程；管理员可修正规则后重试 | “当前审批规则未找到审批人，请联系管理员” |
| 自审 | 申请人、实际报销人或提交人命中当前审批人时阻断；管理员身份不能绕过 | “自己的申请不能审批，请等待下一审批人处理” |
| 系统管理员无业务审批角色 | 仅有 `admin` 权限时不能处理业务审批；需配置 `manager`、`ceo`、`finance`、`hr` 等正式业务角色 | “系统管理员不自动获得业务审批权，请配置正式审批角色后处理” |
| 权限不足 | 服务端拒绝，记录必要安全日志 | “无权处理该审批任务” |
| 任务已处理 | 并发点击或重复提交时返回当前最新状态 | “该任务已处理，请刷新查看最新结果” |
| 并发审批 | 以服务端事务和任务版本为准，只允许一个处理结果生效 | “处理失败，任务状态已变化” |
| 转审超限 | 超过次数、转给无权限人员或形成循环时阻断 | “无法转审给该人员，请选择具备审批权限的人” |
| 审批人离职或停用 | 待办不能继续由停用账号处理；管理员按规则改派或转审 | “当前审批人不可用，请联系管理员处理” |
| 业务单据被删除或归档 | 不允许继续处理孤立待办 | “关联单据不可处理，请刷新或联系管理员” |
| 通知发送失败 | 不阻断主业务，进入可重试状态 | 业务页面不报错；管理员可在通知日志查看 |

---

## 8. 留痕与一致性

### 8.1 必须留痕的记录

- 工作流历史：提交、通过、驳回、退回、撤回、转审、批量审批结果。
- 审计日志：权限变更、审批规则变更、管理员改派、敏感附件查看、财务例外动作。
- 通知记录：发送渠道、接收人、发送状态、失败原因、重试次数、deeplink。
- 业务状态记录：业务单据状态与工作流状态变更必须能追溯。

### 8.2 一致性要求

- 审批动作成功后，业务单据状态、当前任务、审批历史必须在同一事务或等效一致性边界内更新。
- 通知失败不回滚审批动作，但必须可重试。
- 同一任务不能出现两个最终处理结果。
- 业务详情页展示的审批历史与 `/workflow/tasks` 的任务状态必须一致。

---

## 9. 企业微信边界

- 企业微信自建应用只作为 `海音达工作台` 手机入口。
- 企业微信个人应用消息是正式审批待办提醒的首选 IM 通道；群机器人和 mock 只允许作为运维或自动化补充证据。
- 企业微信消息只发送脱敏提醒：标题、业务编号、状态、处理入口。
- 企业微信 deeplink 必须指向 OA 审批页或业务详情页。
- 用户点击消息后，在 OA 内查看详情并执行审批动作。
- 企业微信原生审批不参与正式审批流，不生成公司认可的正式审批记录。
- 若企业微信返回 `invaliduser`、`unlicenseduser`、不可见范围或权限类错误，业务提交和审批动作不应回滚，但通知记录必须可审计、可重试，并提示管理员修正企业微信应用可见范围或账号绑定。
- 真机验收以企业微信手机端收到应用消息并可点击回流为准；系统级弹窗是否出现受客户端通知权限影响，不作为 OA 通知链路硬门槛。

---

## 10. 验收场景

| 场景 | 步骤 | 预期结果 |
| --- | --- | --- |
| 正常审批通过 | 申请人提交报销或请假；审批人在 PC 通过；查看业务详情 | 单据从草稿到审批中再到已通过；历史、当前状态、通知记录一致 |
| 移动端审批 | 申请人提交单据；审批人从 `/mobile/approvals` 打开待办并通过 | 移动端可完成审批；PC 待办同步消失或进入已办 |
| 企业微信通知回 OA | 待办产生后发送企业微信提醒；审批人点击 deeplink | 打开 OA 对应审批页；不能在企业微信原生审批完成动作 |
| 企业微信个人应用消息 | 触发待办后向绑定企业微信成员发送个人应用消息 | delivery 为成功且无 `invaliduser`；手机端可收到消息并点击回到 OA 移动审批 |
| 驳回重提 | 审批人填写原因驳回；申请人查看原因后复制或重建申请 | 原流程留痕完整；新流程有新的提交记录 |
| 退回修改 | 审批人退回；申请人修改后重提 | 保留同一业务单号和退回历史；重新进入审批中 |
| 撤回 | 申请人在未完成前撤回 | 流程终止或回到草稿；审批人待办失效 |
| 转审 | 当前审批人填写原因并转给有权限人员 | 原审批人待办关闭；目标审批人产生新待办；历史显示转审链路 |
| 无审批人阻断 | 提交时审批规则找不到审批人 | 提交失败，无半截流程，提示联系管理员 |
| 正式主管链路 | 专用员工提交普通低/中额单据；`majianyong` 处理待办 | 待办分配给员工直属主管，审批历史显示 `majianyong` 处理 |
| 公司负责人二审 | 专用员工提交高额、高风险或例外单据；`majianyong` 通过后进入 `wangshunli` | 串行节点完整，`wangshunli(ceo)` 作为老板/总经理节点处理 |
| 主管本人申请 | `majianyong` 提交单据 | 主管本人不能自审，按组织链进入 `wangshunli(ceo)` 或明确非本人兜底节点 |
| 公司负责人本人申请 | `wangshunli` 提交并触发老板/总经理节点 | 不允许自审；若无非本人兜底审批人，应阻断并提示管理员修正规则 |
| 系统管理员无业务审批权 | 仅 `admin` 角色账号尝试审批业务单据 | 服务端拒绝，不因 `admin` 权限生成审批历史 |
| 并发处理 | 两个窗口同时处理同一任务 | 只有一个结果生效，另一个提示任务已变化 |
| 通知失败不阻断 | 模拟企业微信通知发送失败 | 审批提交或处理成功，通知记录进入失败可重试 |

---

## 11. 后续开发拆分建议

后续实现时建议按以下 Issue 拆分，不直接跳到大改代码：

- A1：审批任务列表与入口收口，覆盖 PC `/workflow/tasks`、移动 `/mobile/approvals` 和 Portal 待办摘要。
- A2：通用状态转换与并发保护，覆盖提交、通过、驳回、退回、撤回、转审。
- A3：审批权限与当前处理人校验，覆盖越权、自审、停用账号和角色待办。
- A4：审批历史、审计日志和通知记录一致性。
- A5：企业微信通知 deeplink 回 OA 验证，不新增企业微信原生审批。
- A6：报销、请假、采购等业务模块逐个接入统一审批验收。
- A7：审批回归脚本与 Playwright PC/移动/企业微信 UA 验证。
- A8：审批规则配置矩阵落地，覆盖金额阈值、天数阈值、兜底审批人、转审和撤回。
- A9：权限与数据范围矩阵落地，覆盖附件下载、导出、例外处理和系统管理员最小授权。

R6 首轮试运行只验证已有审批主链路稳定性，不新增复杂审批能力。R6 后续优化可单独拆分：

- 待办聚合：PC 和移动统一展示待办、已办、抄送和通知入口。
- 催办与超时提醒：按业务类型、金额或天数配置提醒策略，催办动作必须留痕。
- 审批效率统计：按节点、角色和业务类型统计平均处理时长、超时数量和积压数量。
- 流程配置治理：把金额阈值、兜底审批人、转审规则和通知路由纳入管理员可理解的配置页。

涉及状态机、权限模型、数据库迁移或审批规则调整的 Issue，必须在技术方案中写明回滚策略和回归范围。