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

輕易改變 UOM conversion 會導致庫存數(shù)量混亂, 也會造成財務上的數(shù)據(jù)錯誤. 我們這里做一個 case 來具體分析一下.

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

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

這里我們注意單價是15, 因為在定義 item 的時候, 1 個 Each 單價是15, 再根據(jù)單位轉換, 1 個 Carton 單價還是15. 之后所有的價格計算都根據(jù)這個來, 即使 Carton 和 Each 的單位轉換比例變了.

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

4. 現(xiàn)在我們來到 Mobile 上面做收貨的動作. 由于定義的PO 是ship 到WMS Org, 所以進入到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 都跑完, 我們來看看各個表里的數(shù)據(jù).

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, 這里產(chǎn)生了一條記錄, 10 Carton, 狀態(tài)是7 = Pre-Approved.

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

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

8. 然后到 Returns form 上來. 如果沒有改 UOM conversion 的話, 這里的 Parent Qty 應該是10. 由于我們的EBS 只追蹤 Primary UOM, 因此這里的 Parent Qty 就用 Primary Quantity 除以轉換比例 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, 總價是 8.02, 其中稅 0.52, 也就是說這里的 Carton 的單價是15. 這里的單價是從 PO 里面來的, 但實際上, 1 Carton 已經(jīng)改成 20 Each 了, 實際的單價應該是 300 才對. 但也有合理的一方面, 因為只 Return 了0.5 Carton, 總價不應該超過之前的總價.

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

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

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

f) rcv_lot_supply 里面的數(shù)據(jù)出現(xiàn)明顯錯誤, 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 來補救一下.

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

12. 針對 Receive 的記錄, 多收 0.5 Carton.

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

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

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

c) 但是, rcv_lot_supply 顯然沒有mtl_supply 那么精心設計, 數(shù)據(jù)是錯的. 10 Carton 10 Each. 因為rcv_lot_transactions 就是錯的.

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