文件
hyb-oa/docs/需求-统一审批中心规约.md
T

25 KiB
原始文件 Blame 文件历史

需求 - 统一审批中心规约

版本:1.2 日期:2026-05-11 状态:模块级开发规约 上级事实源:海音达OA-MVP需求规格说明书

本规约细化 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 正式审批组织与角色映射

正式运行和 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,必须在技术方案中写明回滚策略和回归范围。