mirror of
https://gitee.com/dotnetchina/OpenAuth.Net.git
synced 2025-09-20 18:47:55 +08:00
feat: #IBYEGX 业务系统增加送审功能
This commit is contained in:
@@ -1,59 +1,21 @@
|
||||
# 概念
|
||||
# 工作流介绍
|
||||
|
||||
## 会签
|
||||
OpenAuth.Net工作流基于国际标准的BPMN2.0规范,并在此基础上做了一些扩展,以满足国内各种需求。系统工作流分为两个大类:
|
||||
|
||||
会签又称为联名签署,指需要得到两个或多个相关参与者的签名批准。目前支持两种模式:全部通过和至少一个通过,在【会签开始】节点进行配置。如下:
|
||||

|
||||
1. 无业务关联流程,如请假、报销等。
|
||||
|
||||
全部通过:会签中的所有人员都通过,节点审批通过。
|
||||
2. 有业务关联流程,如采购、销售等。
|
||||
|
||||
至少一个通过:会签中任何一个人通过,节点即审批通过。
|
||||
这两种流程的差异有以下几点:
|
||||
|
||||
具体的会签人员或角色,需要在【会签开始】和【会签结束】之间的节点配置,如上图中的admin、test。
|
||||
| 对比维度 | 无业务关联流程 | 有业务关联流程 |
|
||||
|---------|--------------|--------------|
|
||||
| 适用场景 | 请假、报销等日常办公 | 采购、销售、入库等业务操作 |
|
||||
| 发起方式 | 流程中心 -> 我的流程 -> 新的申请 | 直接在业务模块中发起(如:仓储中心 -> 入库订单 -> 送审) |
|
||||
| 表单类型 | 简单表单,适用拖拽表单设计器 | 复杂表单,需要自定义表单或URL表单 |
|
||||
| 审批结束处理 | 仅更新流程状态 | 需要修改业务数据状态 |
|
||||
|
||||
::: warning 特别注意
|
||||
|
||||
【会签开始】【会签结束】执行权限配置为所有人
|
||||
|
||||
会签不能在分支上加判断条件
|
||||
:::
|
||||
|
||||
## 加签
|
||||
|
||||
有时需要在原有审批流程中**临时**增加一个或多个审批节点,这时就需要用到加签的功能。它通常有以下特性:
|
||||
|
||||
* 临时性:加签是在流程执行过程中临时增加的,并非流程设计时就已经固定的审批节点。
|
||||
|
||||
* 发起主体:加签通常由当前审批人发起,他们认为需要额外的人员进行审核或批准。
|
||||
|
||||
* 新增审批节点:加签会在当前审批节点之后,插入一个或多个新的审批节点,这些节点需要审批通过后,原流程才能继续执行。
|
||||
|
||||
* 不改变流程结构:加签不会改变原有流程的整体逻辑或终点,只是插入临时节点,完成后流程继续按原定路径执行。
|
||||
|
||||
|
||||
#### 与会签的区别:
|
||||
|
||||
* 加签:在已有审批流程上临时添加审批人,原审批人仍有审批权。
|
||||
|
||||
* 会签:多个审批人同时审批,所有会签人均需审批,才能通过节点。
|
||||
|
||||
加签功能常用在遇到不明确的情况时,需要其他人协助处理。
|
||||
|
||||
|
||||

|
||||
|
||||
## 条件分支
|
||||
|
||||
有时需要根据提交数据不同(如报销金额、请假天数等)流程转向不同的审批者。这时需要在连线上面配置分支条件,如下图:
|
||||
|
||||

|
||||
|
||||
|
||||
## 知会
|
||||
|
||||
知会指的是在流程执行过程中,将审批结果通知给指定人员,但这些人员不参与实际审批或决策过程。知会的目的是确保相关人员知晓流程的进展或结果,但他们不会影响流程的走向。如下图:
|
||||
|
||||

|
||||
表中提到的表单类型差异可以查看:[表单设计](./form.md)
|
||||
|
||||
|
||||
# 基本操作
|
||||
|
Reference in New Issue
Block a user