轻易改变 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 就是错的.