由于改 UOM conversion 导致库存数量和财务上的数据错误

轻易改变 UOM conversion 会导致库存数量混乱, 也会造成财务上的数据错误. 我们这里做一个 case 来具体分析一下.

1. 开始 Carton 和 Each 的比例是 1 : 1.

2. 我们创建一个PO, ship to W1, 是一个WMS Org. Item 是 lot control 的. UOM 使用 Carton, 不用这个 item 的 Primary UOM. 

   这里我们注意单价是15,  因为在定义 item 的时候, 1 个 Each 单价是15, 再根据单位转换, 1 个 Carton 单价还是15. 之后所有的价格计算都根据这个来, 即使 Carton 和 Each 的单位转换比例变了.

3. 另外, 我们来看看税. 税也是根据税率乘以数量计算的. 这里10 个单位, 税是10.47.

4. 现在我们来到 Mobile 上面做收货的动作. 由于定义的PO 是ship 到WMS Org, 所以进入到WMS 的 Responsibility 里面.

5. 输入PO Number, LPN, 数量 10 Carton, Lot Number 等等. 确定. 

6. 等所有的 concurrent request 都跑完, 我们来看看各个表里的数据.

   a) rcv_receiving_sub_ledger, 由于我们收了10 个Carton, 每个 Carton 单价15, 所以总共要支付150. 加上10.47 的税, 所以总共 160.47. 

   b) mtl_supply, 10 Carton 10 each

   c) mtl_txn_request_lines, 这里产生了一条记录, 10 Carton, 状态是7 = Pre-Approved.

   到这里, 数据都正常.

7. 现在我们到 UOM Conversion 的界面, 去把比例改一下:

8. 然后到 Returns form 上来. 如果没有改 UOM conversion 的话, 这里的 Parent Qty 应该是10. 由于我们的EBS 只追踪 Primary UOM, 因此这里的 Parent Qty 就用 Primary Quantity 除以转换比例 20 了.

9. 我们把所有的数量都 Return 回去.

10. 等 RTP 跑完, 我们再看看数据.

   a) PO 的表的数据都是追踪PO 上的单位 Carton. 所以 po_line_locations_all 里面 quantity 10, quantity received 9.5 CARTON.

   b) rcv_receiving_sub_ledger, 总价是 8.02, 其中税 0.52, 也就是说这里的 Carton 的单价是15. 这里的单价是从 PO 里面来的, 但实际上, 1 Carton 已经改成 20 Each 了, 实际的单价应该是 300 才对. 但也有合理的一方面, 因为只 Return 了0.5 Carton, 总价不应该超过之前的总价.

   c) RCV 表追踪的单位是 item 的 Primary UOM. 因此 rcv_transactions 里面的数据开始出现 mismatch. 接受了10 Each, 返回了10 Each, 相减为 0. 但是还剩9.5 Carton. 当然, RT 作为历史记录表, 只负责记录每个transaction 的数据, 这个数据没有问题, 但是其他表的很多数据是根据RT 的数据计算的, 这样就造成了数据错误.

   d) mtl_supply 里面有两笔记录, 分别为 0.5 Carton 10 Each 和 9.5 Carton 190 Each. 这里有一点问题. 我们库存应该追踪 Primary UOM 才对, 这里数量应该都是0.

   e) mtl_txn_request_lines, 状态变为5 = Closed, 数量0. 在做 Return 之前 状态是7 = Pre Approved, 数量是 10. 这里是根据 Primary Quantity 计算得出的结果.

   f) rcv_lot_supply 里面的数据出现明显错误, Return 之前是 10 Carton 和 10 Each, Return 之后是 9.5 Carton, 0 Each. 这是怎么算出来的呢? 我猜是根据 rcv_lot_transactions 里面的两条记录做了简单的加减 10 Carton 10 Each 和 0.5 Carton 10 Each. 相减就得到lot supply 的数据了. 

11. 上面经过 Return 出现的数据问题, 我们通过 Correction 来补救一下.

      如果按照库存只追踪 Primary UOM 的原则的话, 上面 Receive 这条记录的数量应该是 0. 但是这里可能是从RT 里面取数据. 接收了10个, Return 了0.5, 所以还剩9.5.

12. 针对 Receive 的记录, 多收 0.5 Carton.

13. 做完 Correction 之后, 我们再看下数据.

   a) rcv_receiving_sub_ledger 产生的账目 8.02 和之前 Return 一样. 算是把之前 Return 产生的错误数据弥补回来了. 负负得正.

   b) mtl_supply 有 10 Carton 和 200 Each, 这个表的计算是比较聪明的. 说明以前可能常常出这样的bug. 虽然RT 的数据是错的, 但是mtl_supply 不是简单的把RT 的数据加加减减就OK 了. 

   c) 但是, rcv_lot_supply 显然没有mtl_supply 那么精心设计, 数据是错的. 10 Carton 10 Each. 因为rcv_lot_transactions 就是错的.