当前位置:Gxlcms > mysql > 由于改UOMconversion导致库存数量和财务上的数据错误

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

时间:2021-07-01 10:21:17 帮助过:36人阅读

轻易改变 UOM conversion 会导致库存数量混乱, 也会造成财务上的数据错误. 我们这里做一个 case 来具体分析一下. 1. 开始 Carton 和 Each 的比例是 1 : 1. 2. 我们创建一个PO, ship to W1, 是一个WMS Org. Item 是 lot control 的. UOM 使用 Carton, 不用这

轻易改变 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 等等. 确定. <喎?http://www.2cto.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+PGltZyBzcmM9"http://www.2cto.com/uploadfile/Collfiles/20140531/2014053108532928.jpg" alt="\">

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 就是错的.

人气教程排行