13 KiB
13 KiB
需求 - 统一审批中心规约
版本:1.0 日期:2026-05-09 状态:模块级开发规约 上级事实源:海音达OA-MVP需求规格说明书
本规约细化 hyb-oa 统一审批中心的产品边界、角色权限、状态模型、异常规则、留痕要求和验收场景。后续审批相关开发必须先从本规约拆分 Issue CSV,再进入技术方案和代码实现。
1. 模块目标与边界
1.1 目标
hyb-oa是公司唯一业务主系统和唯一正式审批中心。- 所有正式审批在 OA 内提交、审批、留痕、归档。
- PC、移动端和企业微信入口看到的是同一批审批任务和同一套审批记录。
- 企业微信只做入口、身份、通知和 deeplink;审批动作必须回到 OA 页面完成。
1.2 适用对象
首批及后续默认纳入 OA 审批中心的正式审批包括:
- 报销审批。
- 请假、补卡、外出、加班、出差等考勤相关审批。
- 采购审批。
- 费用审批。
- 合同审批、合同变更审批和合同归档相关审批。
- 资产领用、归还、调拨、盘点中需要正式留痕的动作。
- 后续新增业务审批,除非另有明确产品决策,否则默认接入统一审批中心。
1.3 暂不做范围
- 不使用企业微信原生审批作为公司正式审批流。
- 不接入飞书登录、飞书审批、飞书通知或飞书项目管理。
- 首批不做复杂 BPM 设计器、自由拖拽流程、并行会签、条件分支可视化建模。
- 首批不做跨公司多租户审批市场化配置。
- 首批不做审批动作离线处理;移动端必须在线提交动作。
2. 角色与权限
| 角色 | 典型用户 | 可做动作 | 权限边界 |
|---|---|---|---|
| 申请人 | 普通员工、主管、财务、HR | 创建草稿、提交、查看自己的单据、撤回允许撤回的单据、按退回意见修改后重提 | 只能编辑草稿、已退回、已驳回且规则允许重提的本人单据;不能审批自己的待办,除非后续明确自审例外规则 |
| 审批人 | 主管、项目负责人、老板、被转审人 | 查看分配给自己的待办,通过、驳回、退回、转审、查看审批历史 | 只能处理当前分配给自己的任务;不能越权处理他人待办 |
| 财务 | 财务人员、财务主管 | 处理报销复核、付款标记、财务导出、重复发票例外审批中与财务相关的动作 | 不默认拥有系统管理权限;财务例外动作必须留痕 |
| HR/管理员 | HR、行政管理员 | 处理请假、补卡、外出、加班等行政审批或复核;维护基础人员与组织配置 | 不能绕过审批流直接改业务结果,必要修正必须审计 |
| 老板/总经理 | 公司负责人 | 处理大额、高风险或最终节点审批,查看公司级待办和摘要 | 操作仍需写入审批历史和审计日志 |
| 系统管理员 | 运维或系统负责人 | 配置角色、权限、企业微信入口、通知、基础字典和功能开关 | 不自动获得业务单据审批权;直接数据修复必须另有运维流程和审计 |
权限判定以服务端为准,前端按钮显隐只是体验优化,不作为授权依据。
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 |
审批完成时间 | 通过、驳回终止、撤回终止或完成时填写 |
5. 状态模型
5.1 通用状态
| 状态 | 含义 | 允许的主要动作 |
|---|---|---|
| 草稿 | 申请人正在编辑,未进入审批 | 保存、提交、删除草稿 |
| 审批中 | 已提交,存在当前审批任务 | 审批人通过、驳回、退回、转审;申请人在规则允许时撤回 |
| 已通过 | 所有审批节点通过,进入业务后处理 | 财务付款、合同归档、考勤生效等业务动作 |
| 已驳回 | 审批人否决,流程终止或允许复制重提 | 查看历史、按业务规则重新发起 |
| 已退回 | 审批人要求申请人修改 | 申请人修改后重提、撤回 |
| 已撤回 | 申请人撤回,流程终止 | 查看历史、按业务规则复制重提 |
| 已完成 | 审批通过后的业务处理完成 | 查看、归档、导出 |
| 已付款 | 报销或费用类单据已付款 | 查看、导出;普通用户不可修改 |
已付款 是报销、费用等财务类业务的完成状态之一;非财务业务可使用 已完成。
5.2 状态转换规则
- 草稿只能由申请人或授权代填人提交。
- 提交成功后生成工作流实例、当前节点和第一条待办。
- 当前审批人通过后,系统按规则推进到下一节点;无下一节点时进入
已通过。 - 驳回默认终止当前流程,是否允许复制重提由业务模块决定。
- 退回回到申请人修改态,重提后应保留同一业务单号和完整历史。
- 撤回只允许在流程未完成且规则允许时发生。
- 转审只改变当前任务处理人,不改变业务单据申请人。
- 已完成、已付款、已归档类状态原则上不允许普通用户修改核心字段。
6. 审批动作
| 动作 | 发起人 | 前置条件 | 结果与留痕 |
|---|---|---|---|
| 保存草稿 | 申请人 | 有创建权限 | 写入业务草稿,不生成审批任务 |
| 提交 | 申请人 | 必填字段、附件、金额、发票等业务校验通过 | 生成工作流实例、待办、提交历史和通知 |
| 通过 | 当前审批人 | 任务未处理且权限匹配 | 当前任务完成,进入下一节点或业务通过 |
| 驳回 | 当前审批人 | 必填驳回原因 | 流程终止或进入业务定义的驳回态 |
| 退回 | 当前审批人 | 必填退回原因 | 任务回到申请人修改态,保留历史 |
| 撤回 | 申请人 | 流程未完成且业务允许撤回 | 流程终止或回到草稿,写入撤回原因 |
| 转审 | 当前审批人 | 目标人具备处理资格,未超过转审限制 | 当前任务转给目标人,记录转审链路和原因 |
| 批量审批 | 审批人 | 多个任务均可被当前人处理 | 每个任务独立校验、独立成功或失败 |
| 查看历史 | 相关人员 | 对单据有查看权限 | 展示提交、审批、退回、转审、通知和关键业务动作 |
批量审批不得绕过单条任务的权限、状态和业务校验。
7. 异常规则
| 异常 | 处理规则 | 用户提示 |
|---|---|---|
| 无审批人 | 提交时阻断,不生成半截流程;管理员可修正规则后重试 | “当前审批规则未找到审批人,请联系管理员” |
| 权限不足 | 服务端拒绝,记录必要安全日志 | “无权处理该审批任务” |
| 任务已处理 | 并发点击或重复提交时返回当前最新状态 | “该任务已处理,请刷新查看最新结果” |
| 并发审批 | 以服务端事务和任务版本为准,只允许一个处理结果生效 | “处理失败,任务状态已变化” |
| 转审超限 | 超过次数、转给无权限人员或形成循环时阻断 | “无法转审给该人员,请选择具备审批权限的人” |
| 审批人离职或停用 | 待办不能继续由停用账号处理;管理员按规则改派或转审 | “当前审批人不可用,请联系管理员处理” |
| 业务单据被删除或归档 | 不允许继续处理孤立待办 | “关联单据不可处理,请刷新或联系管理员” |
| 通知发送失败 | 不阻断主业务,进入可重试状态 | 业务页面不报错;管理员可在通知日志查看 |
8. 留痕与一致性
8.1 必须留痕的记录
- 工作流历史:提交、通过、驳回、退回、撤回、转审、批量审批结果。
- 审计日志:权限变更、审批规则变更、管理员改派、敏感附件查看、财务例外动作。
- 通知记录:发送渠道、接收人、发送状态、失败原因、重试次数、deeplink。
- 业务状态记录:业务单据状态与工作流状态变更必须能追溯。
8.2 一致性要求
- 审批动作成功后,业务单据状态、当前任务、审批历史必须在同一事务或等效一致性边界内更新。
- 通知失败不回滚审批动作,但必须可重试。
- 同一任务不能出现两个最终处理结果。
- 业务详情页展示的审批历史与
/workflow/tasks的任务状态必须一致。
9. 企业微信边界
- 企业微信自建应用只作为
海音达工作台手机入口。 - 企业微信消息只发送脱敏提醒:标题、业务编号、状态、处理入口。
- 企业微信 deeplink 必须指向 OA 审批页或业务详情页。
- 用户点击消息后,在 OA 内查看详情并执行审批动作。
- 企业微信原生审批不参与正式审批流,不生成公司认可的正式审批记录。
10. 验收场景
| 场景 | 步骤 | 预期结果 |
|---|---|---|
| 正常审批通过 | 申请人提交报销或请假;审批人在 PC 通过;查看业务详情 | 单据从草稿到审批中再到已通过;历史、当前状态、通知记录一致 |
| 移动端审批 | 申请人提交单据;审批人从 /mobile/approvals 打开待办并通过 |
移动端可完成审批;PC 待办同步消失或进入已办 |
| 企业微信通知回 OA | 待办产生后发送企业微信提醒;审批人点击 deeplink | 打开 OA 对应审批页;不能在企业微信原生审批完成动作 |
| 驳回重提 | 审批人填写原因驳回;申请人查看原因后复制或重建申请 | 原流程留痕完整;新流程有新的提交记录 |
| 退回修改 | 审批人退回;申请人修改后重提 | 保留同一业务单号和退回历史;重新进入审批中 |
| 撤回 | 申请人在未完成前撤回 | 流程终止或回到草稿;审批人待办失效 |
| 转审 | 当前审批人填写原因并转给有权限人员 | 原审批人待办关闭;目标审批人产生新待办;历史显示转审链路 |
| 无审批人阻断 | 提交时审批规则找不到审批人 | 提交失败,无半截流程,提示联系管理员 |
| 并发处理 | 两个窗口同时处理同一任务 | 只有一个结果生效,另一个提示任务已变化 |
| 通知失败不阻断 | 模拟企业微信通知发送失败 | 审批提交或处理成功,通知记录进入失败可重试 |
11. 后续开发拆分建议
后续实现时建议按以下 Issue 拆分,不直接跳到大改代码:
- A1:审批任务列表与入口收口,覆盖 PC
/workflow/tasks、移动/mobile/approvals和 Portal 待办摘要。 - A2:通用状态转换与并发保护,覆盖提交、通过、驳回、退回、撤回、转审。
- A3:审批权限与当前处理人校验,覆盖越权、自审、停用账号和角色待办。
- A4:审批历史、审计日志和通知记录一致性。
- A5:企业微信通知 deeplink 回 OA 验证,不新增企业微信原生审批。
- A6:报销、请假、采购等业务模块逐个接入统一审批验收。
- A7:审批回归脚本与 Playwright PC/移动/企业微信 UA 验证。
涉及状态机、权限模型、数据库迁移或审批规则调整的 Issue,必须在技术方案中写明回滚策略和回归范围。