B审批流程与数据库设计要点

审批流程设计与数据库需求文档

一、文档概述

本文档旨在将审批系统的核心设计思路转化为结构化的需求，涵盖业务流程设计与数据库设计两个维度。需求分析是软件开发的基石，它为后续的设计与开发提供清晰的路线图。本设计参考了金蝶软件等成熟产品的审批模式，旨在构建一个灵活、可扩展、支持公司多部门协作的业务审批平台。

二、审批业务流程设计

审批流程的设计遵循"定义-发起-流转-归档"的核心生命周期，其关键流程与功能需求如下表所示：

流程阶段	核心活动	功能需求说明	涉及角色
1. 流程定义与管理	管理员创建和配置审批模板。	支持可视化或表单化配置审批流程，包括设置流程名称、表单字段、审批节点（顺序、类型、审批人规则）。这是产品设计的起点，需要将抽象的业务规则转化为具体的、可配置的功能模块。	系统管理员
2. 流程发起	用户填写并提交审批申请。	用户根据业务类型选择对应的审批模板，填写结构化表单数据（如请假类型、时间、事由），并提交申请。系统需自动生成唯一审批单号并创建流程实例。	全体员工
3. 流程流转与审批	审批任务在节点间流转，审批人进行处理。	系统根据流程定义，自动生成待办任务并推送通知给指定审批人。审批人可执行"同意"、"拒绝"、"转交"等操作。支持串行、并行、抄送等多种节点类型，并实现条件路由（如金额大于一定数额需上级审批）。	各级审批人
4. 委托与代理	审批人将审批权临时委托他人。	审批人可设置委托规则（被委托人、生效时间、流程范围），在委托生效期内，相关待办任务自动转至被委托人处理。	审批人
5. 流程监控与查询	用户查询申请进度，管理员监控全局。	提供"我的申请"、"待我审批"、"我已审批"等视图，支持按状态、时间、类型筛选。管理员可查看所有流程实例的状态和统计报表。	全体员工、管理员
6. 流程归档	审批结束后，记录归档。	审批完成后（无论通过或拒绝），流程实例状态更新，所有操作记录不可篡改，形成完整的审批档案供后续查询。	系统自动

三、数据库设计需求

数据库设计需支撑上述业务流程，核心在于将非结构化的流程逻辑转化为结构化的数据模型。以下是核心实体及其关系的详细需求。

1. 组织架构模块

此模块是审批人选择和部门路由的基础，需建立清晰的树形结构。

公司(company)：存储公司主体信息。
部门(department) ：支持多层级架构，记录上级部门(parent_id)和部门负责人(leader_id)。
用户(user)：关联所属公司和部门，包含账户信息与状态。
职位(job)：定义职位名称和职级，用于按职位指定审批人。

2. 审批流程核心模块

这是系统的引擎，采用"流程定义"与"流程实例"分离的设计，以实现模板化与灵活性。

流程定义(approval_process) ：对应一个审批模板。关键需求包括：

每个流程属于特定公司。
包含动态表单定义(form_schema)，使用JSON结构描述表单字段、类型、校验规则，以支持不同业务的差异化表单。

sql 复制代码

-- 示例：form_schema JSON结构示意
{
  "fields": [
    {"name": "leave_type", "label": "请假类型", "type": "select", "options": ["年假", "病假", "事假"], "required": true},
    {"name": "start_date", "label": "开始日期", "type": "date", "required": true},
    {"name": "days", "label": "天数", "type": "number", "min": 0.5, "max": 15}
  ]
}

节点定义(approval_node) ：定义一个流程中的具体步骤。关键需求包括：
- 支持多种node_type（如审批、抄送）。
- 审批人规则(approver_type)需高度灵活，支持"指定用户"、"指定角色/职位"、"申请人部门负责人"、"发起人自选"等多种模式。
- 通过sort_order控制节点执行顺序。
流程实例(approval_instance) ：员工发起的每一次具体审批单。关键需求包括：
- 关联流程定义，并快照存储申请人及部门信息。
- 使用JSON类型的form_data字段，存储根据form_schema填写的实际表单值。
- 记录当前状态(status)和正在处理的节点(current_node_id)。
审批任务(approval_task) ：流程实例流转过程中产生的具体待办事项。关键需求包括：
- 记录每个节点分配到的实际处理人(assignee_id)。
- 跟踪任务状态（待处理、已同意、已拒绝等）和审批意见(comment)。

3. 支持与扩展模块

审批委托(approval_delegate)：支持用户设置临时委托规则，系统在生成任务时需根据生效中的委托规则，将任务自动指派给被委托人。
（扩展）流程版本 ：为approval_process表增加版本号字段，使流程模板可迭代更新，新发起的申请使用新版本，历史进行中的申请仍沿用旧版本。
（扩展）条件路由 ：在approval_node中增加条件表达式字段，实现基于表单数据的动态路由（例如：报销金额>5000元时，自动增加财务总监审批节点）。

四、数据关系与流程推演

以下通过"员工请假"场景，说明数据在各表间的流转逻辑：

数据准备 ：公司、部门、用户、职位信息已录入。管理员在后台配置了一个code为LEAVE的请假流程(approval_process)，并定义了"部门经理审批"（节点A）和"HR备案"（节点B）两个节点(approval_node)，其中节点A的审批人规则为"部门负责人"。

发起申请：员工张三提交请假申请。

sql 复制代码

-- 系统创建审批实例，并存储表单数据
INSERT INTO `approval_instance` (`process_id`, `instance_no`, `applicant_id`, `form_data`) 
VALUES (1, 'APP20241111001', 100, '{"leave_type":"年假","days":3}');
-- 假设生成的实例ID为 500

任务生成：系统驱动流程。

sql 复制代码

-- 1. 根据流程定义和实例数据，计算第一个节点（部门经理审批）的审批人。
-- 2. 查询张三的部门负责人（假设为用户李四，ID:101），并创建待办任务。
INSERT INTO `approval_task` (`instance_id`, `node_id`, `assignee_id`) VALUES (500, 10, 101);
-- 3. 更新实例状态为"审批中"，并记录当前节点。
UPDATE `approval_instance` SET `status`=1, `current_node_id`=10 WHERE `id`=500;

审批处理：李四处理任务。

sql 复制代码

-- 李四同意审批
UPDATE `approval_task` 
SET `task_status`=2, `comment`='同意', `action_time`=NOW() 
WHERE `instance_id`=500 AND `assignee_id`=101 AND `task_status`=1;
-- 系统逻辑判断节点A完成后，自动为节点B（HR备案）生成任务（可能为抄送任务）。

流程结束：所有必需节点完成后，流程归档。

sql 复制代码

UPDATE `approval_instance` 
SET `status`=2, `result`='审批通过', `finish_time`=NOW() 
WHERE `id`=500;

五、非功能性需求

性能：针对"我的待办"、"我的申请"等高频查询，需在approval_instance(applicant_id, status)和approval_task(assignee_id, task_status)等字段建立索引。
数据完整性：通过外键约束确保组织架构用户与审批记录间的引用完整性。
可扩展性 ：使用JSON字段存储动态表单结构(form_schema)和数据(form_data)，使系统能快速适配新的审批业务类型，而无需频繁修改数据库表结构。
安全性 ：用户数据隔离（基于company_id）、操作日志审计、表单数据防篡改。

此需求文档明确了从业务流程到数据存储的完整设计方案，可作为后续概要设计、详细设计及开发测试的基准输入。

B审批流程与数据库设计要点

审批流程设计与数据库需求文档

参考来源