反写数据检查

检查过程：

1.  最后一次反写情况得到的数据都存储在反写快照表中，通过快照表的FCId得到反写记录（FCId ="单据formId,关联实体Key,单据内码"），具体反写值以xml格式保存在Fxmlbody字段中；相关的快照表 T_bf_InstanceSnap（当前表）， 历史表和归档表 t_bf_instanceSnapHis, t_bf_SnapBackUp

2. 找到需要检查的反写字段， 反写规则，以及上下游分录内码， 根据分录内码和反写规则内码去反写快照数据中查询，检查反写情况，如果查询到了说明一定反写了，如果没有记录那也就说明没有反写。

   反写规则表：t_bf_WriteBackRule , 多语言表：t_bf_WriteBackRule_L；上下游分录内码根据具体的单据查询

3. 如果查询到反写快照中有反写记录，则上游被反写的字段没有反写数据，则只能说明反写的值被什么操作给清除掉了；这时可以查看上机操作日志，看看上下游单据有那些具体的操作，然后根据上机操作日志中的操作过程，模拟一遍，看是否能够重现。

   
   

示例1：销售出库单没有反写销售订单的可退数量

1. 用户反馈销售订单SEORD102349第323行分录的可退数量没有反写

   

2. 找到没有反写的字段和反写规则，已经上下有单据内码，分录内码

   可退数量（库存基本）  FStockBaseCanReturnQty  反写规则内码：8c14e5eb-6e2a-4568-bbba-d9e6b82bf71f

   可退数量（销售基本）  FBaseCanReturnQty  反写规则内码：3884de59-346e-42bb-ab23-b39252ea28fb

   销售出库单单据内码：121985
   

   销售订单分录内码：

   
   

   
   

3.  查询反写快照数据：更新销售出库单单据内码查询：

   select FXMLBODY from t_bf_instanceSnap where FCID='SAL_OUTSTOCK,FEntity_Link,121985'

4. 查询反写快照可以看到是反写了的：

   

  5. 反写没有问题，那说明很可能是上游单据后续的一些关联操作把可退数量给清理了，检查上机操作日志，发现有时下推后销售订单会进行变更单处理.

6. 经过询问业务之后发现销售变更单既然也会更新原销售订单的字段，并且能够重现，也就是说反写的数量在下面情况会被变更单给覆盖： 变更单得到的可退数量不是反写数量并且在反写之后生效，而且变更单是否生效无法控制跨级操作和反写。

示例2：销售订单的‘累计出库数量’反写出错

1.  用户反馈累计出库数量和累计应收数量不一致：

   
   

   2. 通过反写日志发现，审核之后有保存，并且是不同的操作人，并且保存反写-100，导致累计出库数量减少了100：

  3.  通过上机操作日志也验证了保存是在审核之后，并且别是不同的人，而且相差的时间很近：

4.  经分析第二个用户保存操作在第一个用户审核之后，说明第二个用户操作的页面状态还是新建状态，而不是审核后的状态，说明这两个用户同时操作了新建状态的单据了，单据操作都是有网控的，怎么能两个人同时操作吗？经过咨询用户，反写用户经常有清理网控的操作，所以才会产生这样的情况。 由于第二个用户操作的单据实际状态跟页面操作不一致，导致在反写的时候对审核操作进行了扣减，从而导致了数据不一致。