由于改UOMconversion導(dǎo)致庫存數(shù)量和財(cái)務(wù)上的數(shù)據(jù)錯(cuò)誤

輕易改變 UOM conversion 會(huì)導(dǎo)致庫存數(shù)量混亂, 也會(huì)造成財(cái)務(wù)上的數(shù)據(jù)錯(cuò)誤. 我們這里做一個(gè) case 來具體分析一下. 1. 開始 Carton 和 Each 的比例是 1 : 1. 2. 我們創(chuàng)建一個(gè)PO, ship to W1, 是一個(gè)WMS Org. Item 是 lot control 的. UOM 使用 Carton, 不用這

輕易改變 UOM conversion 會(huì)導(dǎo)致庫存數(shù)量混亂, 也會(huì)造成財(cái)務(wù)上的數(shù)據(jù)錯(cuò)誤. 我們這里做一個(gè) case 來具體分析一下.

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

2. 我們創(chuàng)建一個(gè)PO, ship to W1, 是一個(gè)WMS Org. Item 是 lot control 的. UOM 使用 Carton, 不用這個(gè) item 的 Primary UOM.

這里我們注意單價(jià)是15, 因?yàn)樵诙x item 的時(shí)候, 1 個(gè) Each 單價(jià)是15, 再根據(jù)單位轉(zhuǎn)換, 1 個(gè) Carton 單價(jià)還是15. 之后所有的價(jià)格計(jì)算都根據(jù)這個(gè)來, 即使 Carton 和 Each 的單位轉(zhuǎn)換比例變了.

3. 另外, 我們來看看稅. 稅也是根據(jù)稅率乘以數(shù)量計(jì)算的. 這里10 個(gè)單位, 稅是10.47.

4. 現(xiàn)在我們來到 Mobile 上面做收貨的動(dòng)作. 由于定義的PO 是ship 到WMS Org, 所以進(jìn)入到WMS 的 Responsibility 里面.

5. 輸入PO Number, LPN, 數(shù)量 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 都跑完, 我們來看看各個(gè)表里的數(shù)據(jù).

a) rcv_receiving_sub_ledger, 由于我們收了10 個(gè)Carton, 每個(gè) Carton 單價(jià)15, 所以總共要支付150. 加上10.47 的稅, 所以總共 160.47.

b) mtl_supply, 10 Carton 10 each

c) mtl_txn_request_lines, 這里產(chǎn)生了一條記錄, 10 Carton, 狀態(tài)是7 = Pre-Approved.

到這里, 數(shù)據(jù)都正常.

7. 現(xiàn)在我們到 UOM Conversion 的界面, 去把比例改一下:

8. 然后到 Returns form 上來. 如果沒有改 UOM conversion 的話, 這里的 Parent Qty 應(yīng)該是10. 由于我們的EBS 只追蹤 Primary UOM, 因此這里的 Parent Qty 就用 Primary Quantity 除以轉(zhuǎn)換比例 20 了.

9. 我們把所有的數(shù)量都 Return 回去.

10. 等 RTP 跑完, 我們再看看數(shù)據(jù).

a) PO 的表的數(shù)據(jù)都是追蹤PO 上的單位 Carton. 所以 po_line_locations_all 里面 quantity 10, quantity received 9.5 CARTON.

b) rcv_receiving_sub_ledger, 總價(jià)是 8.02, 其中稅 0.52, 也就是說這里的 Carton 的單價(jià)是15. 這里的單價(jià)是從 PO 里面來的, 但實(shí)際上, 1 Carton 已經(jīng)改成 20 Each 了, 實(shí)際的單價(jià)應(yīng)該是 300 才對(duì). 但也有合理的一方面, 因?yàn)橹?Return 了0.5 Carton, 總價(jià)不應(yīng)該超過之前的總價(jià).

c) RCV 表追蹤的單位是 item 的 Primary UOM. 因此 rcv_transactions 里面的數(shù)據(jù)開始出現(xiàn) mismatch. 接受了10 Each, 返回了10 Each, 相減為 0. 但是還剩9.5 Carton. 當(dāng)然, RT 作為歷史記錄表, 只負(fù)責(zé)記錄每個(gè)transaction 的數(shù)據(jù), 這個(gè)數(shù)據(jù)沒有問題, 但是其他表的很多數(shù)據(jù)是根據(jù)RT 的數(shù)據(jù)計(jì)算的, 這樣就造成了數(shù)據(jù)錯(cuò)誤.

d) mtl_supply 里面有兩筆記錄, 分別為 0.5 Carton 10 Each 和 9.5 Carton 190 Each. 這里有一點(diǎn)問題. 我們庫存應(yīng)該追蹤 Primary UOM 才對(duì), 這里數(shù)量應(yīng)該都是0.

e) mtl_txn_request_lines, 狀態(tài)變?yōu)? = Closed, 數(shù)量0. 在做 Return 之前 狀態(tài)是7 = Pre Approved, 數(shù)量是 10. 這里是根據(jù) Primary Quantity 計(jì)算得出的結(jié)果.

f) rcv_lot_supply 里面的數(shù)據(jù)出現(xiàn)明顯錯(cuò)誤, Return 之前是 10 Carton 和 10 Each, Return 之后是 9.5 Carton, 0 Each. 這是怎么算出來的呢? 我猜是根據(jù) rcv_lot_transactions 里面的兩條記錄做了簡單的加減 10 Carton 10 Each 和 0.5 Carton 10 Each. 相減就得到lot supply 的數(shù)據(jù)了.

11. 上面經(jīng)過 Return 出現(xiàn)的數(shù)據(jù)問題, 我們通過 Correction 來補(bǔ)救一下.

如果按照庫存只追蹤 Primary UOM 的原則的話, 上面 Receive 這條記錄的數(shù)量應(yīng)該是 0. 但是這里可能是從RT 里面取數(shù)據(jù). 接收了10個(gè), Return 了0.5, 所以還剩9.5.

12. 針對(duì) Receive 的記錄, 多收 0.5 Carton.

13. 做完 Correction 之后, 我們再看下數(shù)據(jù).

a) rcv_receiving_sub_ledger 產(chǎn)生的賬目 8.02 和之前 Return 一樣. 算是把之前 Return 產(chǎn)生的錯(cuò)誤數(shù)據(jù)彌補(bǔ)回來了. 負(fù)負(fù)得正.

b) mtl_supply 有 10 Carton 和 200 Each, 這個(gè)表的計(jì)算是比較聰明的. 說明以前可能常常出這樣的bug. 雖然RT 的數(shù)據(jù)是錯(cuò)的, 但是mtl_supply 不是簡單的把RT 的數(shù)據(jù)加加減減就OK 了.

c) 但是, rcv_lot_supply 顯然沒有mtl_supply 那么精心設(shè)計(jì), 數(shù)據(jù)是錯(cuò)的. 10 Carton 10 Each. 因?yàn)閞cv_lot_transactions 就是錯(cuò)的.

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com