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

审批流程设计与数据库需求文档一、 文档概述本文档旨在将审批系统的核心设计思路转化为结构化的需求涵盖业务流程设计与数据库设计两个维度。需求分析是软件开发的基石它为后续的设计与开发提供清晰的路线图 。本设计参考了金蝶软件等成熟产品的审批模式旨在构建一个灵活、可扩展、支持公司多部门协作的业务审批平台。二、 审批业务流程设计审批流程的设计遵循“定义-发起-流转-归档”的核心生命周期其关键流程与功能需求如下表所示流程阶段核心活动功能需求说明涉及角色1. 流程定义与管理管理员创建和配置审批模板。支持可视化或表单化配置审批流程包括设置流程名称、表单字段、审批节点顺序、类型、审批人规则。这是产品设计的起点需要将抽象的业务规则转化为具体的、可配置的功能模块 。系统管理员2. 流程发起用户填写并提交审批申请。用户根据业务类型选择对应的审批模板填写结构化表单数据如请假类型、时间、事由并提交申请。系统需自动生成唯一审批单号并创建流程实例。全体员工3. 流程流转与审批审批任务在节点间流转审批人进行处理。系统根据流程定义自动生成待办任务并推送通知给指定审批人。审批人可执行“同意”、“拒绝”、“转交”等操作。支持串行、并行、抄送等多种节点类型并实现条件路由如金额大于一定数额需上级审批。各级审批人4. 委托与代理审批人将审批权临时委托他人。审批人可设置委托规则被委托人、生效时间、流程范围在委托生效期内相关待办任务自动转至被委托人处理。审批人5. 流程监控与查询用户查询申请进度管理员监控全局。提供“我的申请”、“待我审批”、“我已审批”等视图支持按状态、时间、类型筛选。管理员可查看所有流程实例的状态和统计报表。全体员工、管理员6. 流程归档审批结束后记录归档。审批完成后无论通过或拒绝流程实例状态更新所有操作记录不可篡改形成完整的审批档案供后续查询。系统自动三、 数据库设计需求数据库设计需支撑上述业务流程核心在于将非结构化的流程逻辑转化为结构化的数据模型 。以下是核心实体及其关系的详细需求。1. 组织架构模块此模块是审批人选择和部门路由的基础需建立清晰的树形结构。公司(company)存储公司主体信息。部门(department)支持多层级架构记录上级部门(parent_id)和部门负责人(leader_id)。用户(user)关联所属公司和部门包含账户信息与状态。职位(job)定义职位名称和职级用于按职位指定审批人。2. 审批流程核心模块这是系统的引擎采用“流程定义”与“流程实例”分离的设计以实现模板化与灵活性。流程定义(approval_process)对应一个审批模板。关键需求包括每个流程属于特定公司。包含动态表单定义(form_schema)使用JSON结构描述表单字段、类型、校验规则以支持不同业务的差异化表单 。-- 示例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的审批人规则为“部门负责人”。发起申请员工张三提交请假申请。-- 系统创建审批实例并存储表单数据 INSERT INTO approval_instance (process_id, instance_no, applicant_id, form_data) VALUES (1, APP20241111001, 100, {leave_type:年假,days:3}); -- 假设生成的实例ID为 500任务生成系统驱动流程。-- 1. 根据流程定义和实例数据计算第一个节点部门经理审批的审批人。 -- 2. 查询张三的部门负责人假设为用户李四ID:101并创建待办任务。 INSERT INTO approval_task (instance_id, node_id, assignee_id) VALUES (500, 10, 101); -- 3. 更新实例状态为“审批中”并记录当前节点。 UPDATE approval_instance SET status1, current_node_id10 WHERE id500;审批处理李四处理任务。-- 李四同意审批 UPDATE approval_task SET task_status2, comment同意, action_timeNOW() WHERE instance_id500 AND assignee_id101 AND task_status1; -- 系统逻辑判断节点A完成后自动为节点BHR备案生成任务可能为抄送任务。流程结束所有必需节点完成后流程归档。UPDATE approval_instance SET status2, result审批通过, finish_timeNOW() WHERE id500;五、 非功能性需求性能针对“我的待办”、“我的申请”等高频查询需在approval_instance(applicant_id, status)和approval_task(assignee_id, task_status)等字段建立索引。数据完整性通过外键约束确保组织架构用户与审批记录间的引用完整性。可扩展性使用JSON字段存储动态表单结构(form_schema)和数据(form_data)使系统能快速适配新的审批业务类型而无需频繁修改数据库表结构 。安全性用户数据隔离基于company_id、操作日志审计、表单数据防篡改。此需求文档明确了从业务流程到数据存储的完整设计方案可作为后续概要设计、详细设计及开发测试的基准输入 。参考来源需求文档(PRD文档)应该怎么写需求文档软件开发流程之需求分析与文档编写需求文档(PRD文档)数据仓库模型设计(收藏版)用 AI 自动分析需求文档实体识别与关系抽取全流程