@windwolf
2018-04-17T01:32:57.000000Z
字数 2182
阅读 379
Sailing
目前系统中, 对于有版本控制的单据之间, 存在数据引用和校验方面存在以下缺陷或漏洞:
上游: 100(v1.生效) -> 60(v2.草稿)下游: 80(v1.生效)
此时的明细单能引用到草稿状态的v2版本, 并且会因为草稿状态而被过滤掉, 最终表现出来的结果是, 这个明细单没有对应的外销合同.
上游: 100(v1.生效) -> 60(v2.生效)下游: 80(v1.生效)-> 40(v2.生效) -> 80(v1.生效)
此时, 下游单据大于上游单据, 出现了非法错误.
以上问题的出现, 本质上是由于仅仅把版本当做一个历史数据记录工具, 除了当前最新版本(即使是草稿)以外, 其他版本数据没有参与业务数据引用和验证. 在撤销时自动返回上一个版本的功能, 本质上相当于与未经任何验证的数据修改.
从以上几个案例所暴露出来的问题的来看, 版本控制的意义并不在于记录历史数据以便于返回到之前版本, 而在于单据发生修改的过渡阶段提供一份当前有效的单据内容. 作为一个单据, 一旦签署生效后, 还需要变回从前的样子, 那就需要再次生成新版本, 将内容变更成之前的样子. 而不是简单的退回之前版本.
因此, 为了让版本真正产生作用, 需要在当前版本之外, 再引入一个有效版本的概念. 当前版本指向目前正在操作的版本, 而有效版本是指业务上目前起作用的版本.
当新产生一个单据(版本1)的时候, 当前版本为版本1, 有效版本没有, 一直到版本1审批通过后, 有效版本为版本1.
在版本1的基础上修改后产生版本2, 当前版本为版本2, 而有效版本还是版本1, 到版本2审批通过后, 有效版本改为版本2.
而对不同的单据来说, 经过什么手续才算生效的定义并不相同, 因此, 需要允许在工作流中配置生效的时机.
以上手段解决了数据引用问题. 但工作流撤回后数据校验问题还是存在. 另外, 有效版本的概念, 引入了新单据审批过程中的一个过滤阶段, 这个过渡阶段可能引起额外的数据验证问题, 例如:
上游: 100(v1.生效)-> 85(v2.草稿)-> 85(v2.待批)-> 85(v2.生效)下游: 80(v1.生效)-> 90(v2.草稿)-> 90(v2.待批)-> 90(v2.生效)
由于目前的数据验证仅发生在从草稿提交的那一刻, 而无论草稿还是待批都没有触发生效版本的变更(还都是版本1), 因此, 上下游单据均能通过验证成功提交, 进而审批通过生效. 鉴于此, 单据勾稽关系不能仅在提交时验证, 需要在每次发生工作流节点转移的时候验证.
即便如此, 在流程撤销的时候还是可能遇到勾稽关系错误的问题. 例如:
上游: 100(v1.生效) -> 50(v2.生效)下游: 80(v1.生效)-> 40(v2.生效) -> 80(v1.草稿)
在上下游单据分别调整成50, 40后, 下游单据撤销调整, 导致单据勾稽关系异常. 导致这种异常的原因是撤销的过程没有进行勾稽关系验证. 那么, 工作流在撤销的时候也进行单据验证就可避免这个问题.
此外, 对于受版本控制的单据, 生效状态意味着当前版本已经过各方确认, 那么再要修改回老版本, 也需要新开版本将内容调整成老版本, 而不是直接回溯到老版本. 也就是说, 工作流撤回时, 不允许越过生效节点.
改造方案总结如下:
引入生效标志后, 毫无疑问, 版本控制机制本身需要调整; 更重要的是, 把生效从当前版本中分离出来, 意味着对单据相关操作人来说, 需要关注的是当前版本, 而对单据的其他引用方来说, 关注的是生效版本.
因此, 所有涉及到单据引用有关的机制, 都要做相应的调整, 他们包括:
外销合同001(v1.生效), A款 100件, 出运了明细单001(v1.生效), A款 90件.
此时, 外销合同发生变更, 改为 外销合同001(v2.草稿), B款 100件.
v2提交时, 需要根据外销合同001的有效版本即v1, 来查到对方单据, 找到明细单001(v1); 随后根据明细单001(v1)反向查找所有的外销合同. 实际验证时, 还是使用当前单据, 即外销合同001(v2)来验证.