功能需求说明
支持合并审批的类型区分，分为：审批人合并、发起人合并、提交人合并，三种情况。
当前能力说明
流程设计为A-B-C，其中A为开始，C为结束。B节点为审批节点，由b1审批，且B节点设置了合并审批。
那么假如有两个不同的人员a1,a2提交审批过来时到B节点审批时，B节点会合并一条待办记录数据。
即对应的是审批人合并的能力。
期望新增的能力
提交人合并的情况，假如还是上述的流程，a1提交了2条，a2也提交了两条，到了B节点时，合并完的结果是2条数据，以用户a1为合并条件，下面有2条记录，a2也是2条。这样的情况即算是发起人合并也算是提交人合并，即当类型设置这两种的任意一种都会出现这样的效果。因为节点A即是发起人也是提交人。
评估分析这个能力，先编写当前能力的单元测试，然后再做方案增加新的能力，然后进行测试。
这个功能涉及到的地方：
- 前端需要增加相应的合并类型的设置能力。
- 后端增加合并类型的支持能力
- 后端在合并处理的时候根据类型进行处理合并
功能需求说明
支持合并审批的类型区分，分为：审批人合并、发起人合并、提交人合并，三种情况。
当前能力说明
流程设计为A-B-C，其中A为开始，C为结束。B节点为审批节点，由b1审批，且B节点设置了合并审批。
那么假如有两个不同的人员a1,a2提交审批过来时到B节点审批时，B节点会合并一条待办记录数据。
即对应的是审批人合并的能力。
期望新增的能力
提交人合并的情况，假如还是上述的流程，a1提交了2条，a2也提交了两条，到了B节点时，合并完的结果是2条数据，以用户a1为合并条件，下面有2条记录，a2也是2条。这样的情况即算是发起人合并也算是提交人合并，即当类型设置这两种的任意一种都会出现这样的效果。因为节点A即是发起人也是提交人。
评估分析这个能力，先编写当前能力的单元测试，然后再做方案增加新的能力，然后进行测试。
这个功能涉及到的地方：