（问题分析）供应链单据单位精度的详细拆解分析

      供应链物料单位精度的设置的要求

       供应链中对物料单位和精度的设置最好遵循如下两个原则：

      1.  基本单位是最小单位，吨和千克，一般千克为基本单位

      2.  通常计量单位的精度高，即吨如果是3位精度，而单位千克的精度可以 < 3

      理由显而易见，数量的转换方向一般为计量单位-->基本单位，如果反过来，基本单位为吨，计量单位为千克，用户界面录入0.001kg，则需要转换成基本单位存成0.000001吨，数字越小越容易因为精度问题而导致数据尾差，产生丢失精度等问题。此时基本单位精度就必须远大于计量单位的精度才能保证数据不丢失，假设吨的精度也为3位，经过四舍五入基本单位数量就成0了，数值越小则对精度的要求越高。

      但是实际应用中可能就存在违反上述原则的设置，导致了如下问题：

      问题的提出

       直观的看，销售订单下推了4000.000000000千克到销售出库单，但是下游销售出库审核反写后为什么成了4000.020571168千克了呢？ 所以直观感受是反写错了。

       原因的解析：

       首先单位和精度设置存在问题，导致了销售订单上的基本数量4.5611就已经存在精度丢失的情况了，下推后的基本数量同样丢失了精度。

       现有的反写方案为：基本数量的反写是直接根据下游单据字段原值反写，而在数量反写规则中的公式是使用倍比法的原理：

                                                           基本数量原值反写

                                                          倍比法反写数量

计算公式为：累计出库数量 = 累计出库基本数量 * 数量 / 基本数量，先执行乘法是传统的减少精度损失的做法，但是此处未处理精度。

所以上述反写数量问题很容易解释：数量=4561.123456789*4.0000/4.5611=4000.020571168

所以可以看出一个不恰当的精度设置导致了这个问题。

在这里提及一下数量数值字段的存储现状：【数量】字段后台按(23,10)存10位精度值，前端格式化为计量单位精度显示；【基本数量】字段严格按照精度格式化存储。

        在这里看客们应该有个疑问： 为什么数量字段不按照基本数量的方式来反写呢？ 按原值反写不好吗？

当然一定是有理由的：

       1. 不恰当的精度设置可能导致【基本数量】=0 且【数量】<>0，这是精度设置不佳的最极端体现，早期库存单据提交只校验数量>0，导致一些潜在的【基本数量】=0的场景发生。如果照直反写，会导致出现一个基本数量值反写不上的情况，且不易被察觉，使用倍比法公式，基本数量为0，则按照公式数量也必定按照0反写，用户才容易察觉出基本数量可能存在的精度设置不当的问题。

       2. 下游可能调整出入库计量单位，库存单位与上游销售单位可能对不上，无从反写，所以必须锚定基本数量做中介计算，倍比法无需考虑单位换算，只考虑数值比，减少单位之间的换算从而减少性能开销。

         注意我们锚定的是【基本数量】，原因是可能存在第三种单位，如辅助单位，辅助单位数量的调整也会导致数量和基本数量的变化，如：

        所以以【基本数量】作为精确的锚定标准就成了必然的选择。   

        那为什么这个倍比法计算公式不考虑数量的精度呢？

        理由是基本数量是准确的按精度格式化存储和取值，而数量计算后每一次取精度的四舍五入，则每一次反写计算都可能会因为每一次的精度积累更大的误差，可能会导致最终出库完毕后，页面中可见的【累计出库数量】字段和【数量】字段对不上，让用户困惑。故这里放大精度到标准的10位，再格式化显示，以求可以尽可能的减少误差。

       总结一下：所以看出目前反写公式方案的考量就是：

       以精确的【基本数量】为锚，来界定【数量】字段的值，同时放大数量精度减少误差。 当然这一切少不了合理的单位设置和精度设置的配合。如果合理的设置了单位和精度，则可以较为完美的解决尾差和误差的问题。

       综上所述，现在的方案是一个适应大部分数据场景的均衡的策略。

回顾上述问题，它真的是一个问题吗？

        这个问题在现有反写策略下是否真的无法避免？ 答案为：是。因为不恰当的单位和精度设置，目前出现这个问题是必然的，但是这个问题可能真的不是一个问题，还是那句话：实施人员应该优先考虑符合实际的恰当的单位和精度设置，这样就可以规避后期的各种精度和误差问题。

      当然也可以有潜在的改进方案：

      在现有方案的基础上，额外考量如果上下游单据计量单位一致的时候，可以考虑直接反写下游单据字段原值，这个策略可以解决上述问题。

     但是现有产品不考虑执行，如果必要，现场二次开发可以酌情处理。

完。