文档中心8.3合并流程模型配置
合并流程模型配置分为合并设置和审批设置，我们会逐一进行讲解
1合并设置
合并设置定义合并流程中基本操作动作（比如合并的计算、折算、贡献等计算动作）的执行逻辑，权限，以及校验等内容，需要说明的是，系统预置了7个合并的基本操作动作，暂不支持新建自定义动作。
1.1基础设置
-
元素信息：编码及名称，同其他组件
-
合并模型：选择合并对应财务模型，合并场景约定为main_cub
-
流程数据表：涉及到的流程数据表，此处可跳转到对应的数据表元素，暂不支持修改
-
合并单元：以
year、period、scenario、version+entity为最小管理单位记录公司计算、阶段审批状态的记录表 -
单元对父贡献：对于合并单元，对不同父级实体操作[折算]与[贡献]的记录表
-
单元日志：针对单元的操作记录日志
-
审批日志：针对单元的审批记录日志
-
-
权限：合并动作及审批动作关联的权限方案
ℹ️需要注意的是，关联的权限方案：
-
有且仅有一个多版本实体维；
-
权限方案的实体维必须与关联的财务模型实体维一致
1.2合并动作
-
系统预置了【开启】及【查询】，此两项为标准逻辑，不可进行自定义
-
我们可以开关除【开启】及【查询】动作以外的按钮，并配置他们对应的执行逻辑
-
可调整动作名称
ℹ️合并动作上预置了些合并场景常见的校验策略：
点击 【折算】时，同单元计算状态必须为已完成
点击【贡献（抵消）】时，同单元计算状态和折算状态必须为已完成
~~点击【强制合并】时，同单元的【计算状态】必须为~~~~已完成~~
动作说明
|
动作类型 |
动作 |
动作说明 |
备注 |
|---|---|---|---|
|
流程动作（全局） |
开启 |
流程数据初始化 |
该按钮不可关闭 |
|
单元动作 |
查询 |
流程单元查询 |
该按钮不可关闭 |
|
强制合并 |
无论下级公司是否已计算，均执行层层向上的计算 |
执行py脚本2.0【consolidation_all】 | |
|
合并 |
跳过下级已计算的步骤，层层向上计算 |
执行py脚本2.0【consolidation】 | |
|
合并下级（202404新增） |
合并children节点到当前合并节点 |
执行py脚本2.0【consolidate_subordinate】 | |
|
计算 |
计算实体自己的数据 |
执行py脚本2.0【calculation】 | |
|
折算 |
计算实体对父的数据 |
执行py脚本2.0【translation】 | |
|
贡献（抵消） |
计算实体对父的数据 |
执行py脚本2.0【contribute】 |
合并计算python的存放路径必须要和config文件中配置一致
1.3动作权限
动作权限即配置每个动作的执行策略，也就是定义每个动作的权限方案是怎么样的。
ℹ️使用动作权限的前提是：我们合并动作关联的权限是打开的
预置策略
-
单体（base节点）不允许执行【强制合并】、【合并】
-
无父级信息的实体（上级节点是#root或无父级实体）不允许执行【折算】、【贡献】
-
合并节点（非base节点）不允许执行【计算】
新建策略
此时我们可以来配置之前开启的合并动作的具体权限了
-
新建策略分类
-
流程动作权限：全局操作权限
-
单元动作权限：by到行的动作权限
-
-
策略条件配置要素
-
先验条件：满足执行的先行条件，目前仅可选择权限方案
-
谓语：配置【允许】或【不允许】策略
-
允许即在满足先验条件的情况下，允许执行勾选的资源动作按钮；
-
不允许即在满足先验条件的情况下，不允许执行勾选的资源动作按钮；
-
-
资源与动作：合并动作开启的按钮，此处不在说明用途
-
-
目前自定义策略的上限为15个（含）
策略详情配置案例
配置如上图所示时的具体策略：单体录入/单体审核角色岗允许操作【查询】、【计算】、【折算】动作按钮，其他按钮则没有相应的执行权限。
2审批设置
我们已经在合并设置中进行了基础配置和合并计算相关的配置，在审批配置中，我们需要进行合并审批流程相关的配置，比如定义从哪些维度去校验，定义合并流程的阶段，设置企业内部多层级的审批流
2.1通用设置
通用配置用于所有阶段的通用逻辑，目前仅做关键逻辑的只读展示；
-
校验的预置逻辑，通过校验配置的pov去查询合并财务模型的每个合并单元，取到的多行数据聚合计算：
-
未校验：所有校验值均为空（null）
-
异常：至少1个有值，且存在校验值 != 0
-
正常：至少1个有值，且所有校验值 == 0
-
如果校验没有启用，或者部分如折算没有启用，对应的校验值
视为「未校验」
-
-
自定义校验，暂未支持
2.2阶段管理
初始有三个阶段，可自行配置开启与关闭。
-
预置阶段：
-
phase1-阶段1
-
phase2-阶段2
-
phase3-阶段3
-
-
描述不可改，可在UX里配置
合并校验
校验面板可通过配置财务模型的维度表达式组合，以及每一类固定合并校验对应的value和account组合。用于在使用态展示校验，以及在审批时强制校验计算状态。
-
合并校验默认关闭，用户有需求可打开校验；
-
校验打开后【计算校验】不可关闭，【折算】、【贡献】校验可被关闭；
-
配置by 1.entity2.year; 3period; 4.scenario; 5.version维度的检验，以上5个pov为页面筛选固定单个维度，行列为value，account组合，可配置多个成员表达式
进度与动作
流程进度
用户可以按照企业合并的实际情况配置合并流程的审批状态
流程动作
我们可以配置流程审批动作的流转逻辑，即当前进度和目标进度分别是什么
-
当前进度与目标进度不得重复
-
当前进度目前版本暂时只支持一个状态
ℹ️预置审批校验逻辑：
-
前进类审批，即目标的进度序号大于当前进度序号；
-
当前单元审批作业状态为空闲
-
当前单元计算校验状态为校验通过
-
前进的目标节点，不大于任意下级实体单元的审批进度
-
-
后退类审批，即目标的进度序号小于当前进度序号；
-
后退的目标节点，不小于上级实体单元的审批进度
-
流程动作前置自定义逻辑
为满足合并流程审批复杂业务场景，我们可以在审批动作上关联自定义逻辑：
-
支持PY自定义逻辑，如回调财务模型等
-
支持工作流，审批后发站内信、通知邮件等
a.PY脚本
- 执行方式为同步执行，根据is_success的返回值（布尔值）判断是否执行后续逻辑，当is_success=True时才会往下执行。
- 提示配置
* 成功后提示：开启后，根据python返回结果is_success=True进行弹窗提示
* 失败后提示：开启后，根据python返回结果is_success=False进行弹窗提示
- python按指定格式返回，可参考下面案例
{
"is_success": False,
# 布尔值，表示业务逻辑运行成功失败
"notification": {
"success": {
"title": "成功标题",
"description": "成功文案"
},
"info": {
"title": "提示标题",
"description": "提示文案"
},
"warning": {
"title": "警告标题",
"description": "警告文案"
},
"error": {
"title": "错误标题",
"description": "错误文案"
}
}
}
b.工作流
- 审批动作会按指定的参数去调用工作流，结果返回的节点可在工作流中进行定义
- 选择的工作流元素启动参数存在于启动参数，否则会导致启动工作流失败
- 工作流的启动参数可以比这个少，比如只设置<str>unit_id，其他不配置也可以
启动参数
{
"year": "2022",
"period": "12",
"scenario": "Actual",
"version": "Working",
"entity":"AC",
"parent":"MC",
"unit_id":"2022_12_Actual_Working_AC",
"action_code": "approve01",
#操作范围：self-实体本身，idescendant-实体本身和后代，ichildren-实体本身和子代
"scope"："idescendant",
"origin_state":"state_2",
"target_state": "state_5"
"origin_num":"2",
"target_num": "5"
"batch_entities": [
"AC",
"A",
"B"
],
"batch_parents": [
"MC",
"AC",
"AC"
],
"unit_ids": [
"2022_12_Actual_Working_AC",
"2022_12_Actual_Working_A",
"2022_12_Actual_Working_B"
]
}
{
"year": "2022",
"period": "12",
"scenario": "Actual",
"version": "Working",
"entity": "A",
"parent": "AC",
"unit_id": "2022_12_Actual_Working_A",
"action_code": "approve01",
#操作范围：self-实体本身，idescendant-实体本身和后代，ichildren-实体本身和子代
"scope"："idescendant",
"origin_state": "state_1",
"target_state": "state_5",
"origin_num": "1",
"target_num": "5"
"unit_ids": [
{
"entity":"A",
"parent":"AC",
"unit_id":"2022_12_Actual_Working_A"
},
{
"entity":"B",
"parent":"AC",
"unit_id":"2022_12_Actual_Working_B"
}
]
}
允许对实体后代操作
勾选后，操作审批动作时可选择操作实体后代（含实体本身）或者实体本身
自定义动作
标准的审批动作定义了「当前进度」到「目标进度」，但实际业务场景有从「当前进度」到「自定义目标进度」的需求，中间可能包含些外围系统校验等特殊判定，目前只有前置动作挂工作流去异步轮询的方式去实现一些审批动作后置逻辑，我们可以选择添加「自定义动作」按钮，使用方法可参考前置逻辑
审批流转配置案例
流程进度【原】
|
进度序号 |
编码 |
描述 |
操作 |
|---|---|---|---|
|
0 |
no_started |
未开始 |
移动排序 |
|
1 |
started |
已开始 |
移动排序 |
|
2 |
submitted |
已提交 |
移动排序 |
|
3 |
approved01 |
一级审批通过 |
移动排序 |
|
4 |
approved02 |
二级审批通过 |
移动排序 |
|
5 |
approved03 |
加签审批通过 |
移动排序 |
|
99 |
locked |
已锁定 |
移动排序 |
|
➕ |
流程进度【新】
|
进度序号 |
编码 |
描述 |
操作 |
|---|---|---|---|
|
0 |
no_started |
未开始 |
移动排序 |
|
1 |
started |
已开始 |
移动排序 |
|
2 |
submitted |
已提交 |
移动排序 |
|
3 |
approved01 |
一级审批通过 |
移动排序 |
|
~~5~~->4 |
approved03 |
加签审批通过 |
移动排序 |
|
~~4-~~>5 |
approved02 |
二级审批通过 |
移动排序 |
|
99 |
locked |
已锁定 |
移动排序 |
|
➕ |
流程动作【原】
|
动作编码 |
编码 |
描述 |
执行逻辑（当前进度->目标进度） |
|---|---|---|---|
|
1_2 |
submit |
提交 |
started(已开始)->submitted(已提交) |
|
2_3 |
approve01 |
审批 |
submitted(已提交)->approved01(一级审批通过) |
|
2_1 |
reject01 |
拒绝 |
submitted(已提交)->started(已开始） |
|
3_4 |
approve02 |
审批 |
approved01(一级审批通过3)->approved02(二级审批通过4) |
|
3_1 |
reject02 |
拒绝 |
approved01(一级审批通过3)->starte(已开始1） |
|
4_5 |
approve03 |
审批 |
approved02(二级审批通过4)->approved03(加签审批通过5) |
|
4_1 |
reject03 |
拒绝 |
approved02(二级审批通过4)->started(已开始1） |
|
5_99 |
lock |
已锁定 |
approved03(加签审批通过5)->locked(锁定99) |
|
99_1 |
unlock |
解锁 |
locked(锁定99)-started(已开始1) |
|
➕ |
流程动作配置按编码
|
动作编码 |
编码 |
描述 |
执行逻辑（当前进度->目标进度） |
|---|---|---|---|
|
1_2 |
submit |
提交 |
started(已开始)->submitted(已提交) |
|
2_3 |
approve01 |
审批 |
submitted(已提交)->approved01(一级审批通过) |
|
2_1 |
reject01 |
拒绝 |
submitted(已提交)->starte(已开始） |
|
3_4 |
approve02 |
审批 |
approved01(一级审批通过3)->approved02(二级审批通过4) |
|
3_1 |
reject02 |
拒绝 |
approved01(一级审批通过3)->starte(已开始1） |
|
5_4 |
approve03 |
审批 |
approved02(二级审批通过~~4~~5)->approved03(加签审批通过~~5~~4) |
|
5_1 |
reject03 |
拒绝 |
approved02(二级审批通过~~4~~5)->starte(已开始1） |
|
4_99 |
lock |
已锁定 |
approved03(加签审批通过~~5~~4)->locked(锁定99) |
|
99_1 |
unlock |
解锁 |
locked(锁定99)-started(已开始1) |
|
➕ |
流程动作系统不会按**
|
动作编码 |
编码 |
描述 |
执行逻辑（当前进度->目标进度） |
|---|---|---|---|
|
1_2 |
submit |
提交 |
started(已开始)->submitted(已提交) |
|
2_3 |
approve01 |
审批通过 |
submitted(已提交)->approved01(一级审批通过) |
|
2_1 |
reject01 |
拒绝 |
submitted(已提交)->started(已开始） |
|
3_4 |
approve02 |
审批通过 |
approved01(一级审批通过3)->approved02(二级审批通过4) |
|
3_1 |
reject02 |
拒绝 |
approved01(一级审批通过3)->starte(已开始1） |
|
4_5 |
approve03 |
审批通过 |
approved0~~2~~3(二级审批通过4)->approved0~~3~~2(加签审批通过5) |
|
4_1 |
reject03 |
拒绝 |
approved0~~2~~3(二级审批通过4)->started(已开始1） |
|
5_99 |
lock |
已锁定 |
approved0~~3~~2(加签审批通过5)->locked(锁定99) |
|
99_1 |
unlock |
解锁 |
locked(锁定99)-started(已开始1) |
|
➕ |
❗通过上述案例，我们可以看出流程进度的序号调整后，流程动作记录的是审批进度编码，不是审批进度序号，需要及时检查审批动作的配置。
回到顶部
咨询热线
400-821-9199
