# 竞价系统-流程节点配置
# 概述
由于每个采购单位申购单的流程可能存在差异,因此将流程节点设计为可配置。
# 常见流程
提交 -> 发布审批 -> 竞价中 -> 初选管理 -> 用户初选 -> 一审 -> 二审 -> 发货 -> 收货 -> 验收 -> 资产登记 -> 结束
- 其中高校的个性化流程往往出现在两个地方:
- 提交之后,发布审批之前,如西安电子科技大学:提交 -> 院系审核 -> 财务审核 -> 采购办审核 -> 发布审核 -> 竞价中
- 用户初选之后,发货之前,如汕头大学:用户初选 -> 一审 -> 二审 -> 监察 -> 发布成交结果 -> 发货
- 因此,对这两个部分进行了整合,分别整合为整合发布审批,整合结果审批。 这两个流程需要在高校端“系统设置”-“流程配置”进行配置,以确定哪些节点是归属于整合发布审批、整合结果审批, 一方面用于控制整合菜单显示的节点,另一方面,供发布成交结果这样需要越过节点的操作使用 (发布成交结果需要将节点转到当前节点后面的第一个不属于结果审批的节点,通常为发货)
# 高校个性化
- 当高校需要个性化时,通常都是在整合发布审批、整合结果审批增加/删除节点。
- 此时要注意,除了修改申购单类型对应的流程配置,还要修改对应的整合发布审批节点或者整合结果审批节点。
- 如果需要删除某个节点,可以将该节点的部分删除,也可以将它的node_status设为0(无效)。
# 初始化类
操作配置由NodeData在系统启动时进行初始化,对配置信息完成解析并载入缓存。
# 常用调用方法
//获取节点完整配置信息,参数依次为高校ID,申购单类型,节点代码(对应orderMain.currentProcee)
NodeUtil.getNode(collegeId, orderType, nodeCode);
//获取上一可用节点的信息
NodeUtil.getPrevAvailableNode(collegeId, orderType, nodeCode);
//获取下一可用节点的信息
NodeUtil.getNextAvailableNode(collegeId, orderType, nodeCode);
//获取发布成交结果后的节点(当前节点后首个不是结果审批的节点,通常为发货)
NodeUtil.getFirstNodeAfterPublishResult(collegeId, orderType);
//获取此采购单位所有配置了的节点
NodeUtil.getAllNodes(collegeId);
//获取此采购单位指定申购单类型的所有节点(用于申购单详情的节点进度条)
NodeUtil.getAllNodes(orderType, collegeId);
# 配置格式
配置格式为JSON,每个节点为列表中一个一个元素
【示例】
[
{
"node_seq": 1,
"node_code": "CREATE",
"node_name": "提交",
"old_node_code": 1,
"delay_days": -1,
"delay_action": "",
"abort_reason": "",
"is_back": false,
"node_status": 1,
"parent_node_code": "",
"node_type": 0
},
...(表示省略)
]
# 配置项
node_seq 节点序号
用于决定节点的排列顺序,最好不要重复
【示例】1node_code 节点代码 【示例】CREATE
node_name 节点名称
【示例】提交old_node_code 在旧版的节点代码(数字)【已废弃】 【示例】1
hint 节点提示
此项配置后,高校端的申购单详情节点进度条下方会显示配置的文字。delay_days 节点滞留期限 【暂未实现】
delay_action 节点超期操作 【暂未实现】
abort_reason 超期操作默认理由 【暂未实现】
is_back 是否允许回退 【已废弃】
【示例】truenode_status 节点状态
0:无效;1:有效
【示例】1parent_node_code 父级节点代码 【已废弃】
node_type 节点类型 【已废弃】