Changing UOMconversion results in inventory quantity and financial data errors.

Changing UOMconversion easily will lead to chaotic inventory quantity and financial data errors. here we will make a case for specific analysis. 1. the ratio of Carton to Each is. 2. we create a PO, shiptoW1, which is a WMSOrg. item is lotcontrol. UOM uses Carton.

Changing the UOM conversion will lead to chaotic inventory and financial data errors. here we will make a case for specific analysis. 1. the ratio of Carton to Each is 1: 1. 2. we create a PO, ship to W1, which is a WMS Org. item is controlled by lot. UOM uses Carton.

Changing the UOM conversion easily will lead to confusion in the inventory quantity and financial data errors. Here we will make a case for specific analysis.

1. The ratio of Carton to Each is 1: 1.

2. We create a PO, ship to W1, which is a WMS Org. Item that is controlled by lot. UOM uses Carton instead of the Primary UOM of this item.

Here we pay attention to the unit price of 15, because when defining an item, the unit price of one Each is 15, and then according to the unit conversion, the unit price of one Carton is still 15. all subsequent price calculations are based on this, even if the unit conversion ratio of Carton and Each has changed.

3. In addition, let's take a look at the tax. The tax is also calculated based on the tax rate multiplied by the number. Here there are 10 units, and the tax amount is 10.47.

4. Now we come to Mobile to perform the shipping action. Because the defined PO is ship to WMS Org, we enter the Responsibility of WMS.

5. Enter PO Number, LPN, Number 10 Carton, Lot Number, and so on. OK. <喎?http: www.2cto.com kf ware vc " target="_blank" class="keylink"> VcD4KPHA + pgltzybzcm9 "http://www.2cto.com/uploadfile/Collfiles/20140531/2014053108532928.jpg" alt = "\">

6. When all the concurrent requests are completed, let's take a look at the data in each table.

A) rcv_receiving_sub_ledger. Since we have received 10 Carton instances and each Carton has a unit price of 15, we have to pay 150 RMB in total. Plus 10.47 RMB in tax, we have a total of 160.47 RMB.

B) mtl_supply, 10 Carton 10 each

C) mtl_txn_request_lines. A record is generated, 10 Carton, And the status is 7 = Pre-Approved.

At this point, the data is normal.

7. Now let's go to the UOM Conversion interface and change the ratio:

8. go to Returns form. if the UOM conversion is not changed, the Parent Qty here should be 10. because our EBS only tracks Primary UOM, the Parent Qty here uses Primary Quantity divided by the conversion ratio of 20.

9. We will Return all the numbers back.

10. When RTP is finished, let's look at the data.

A) the data in the PO table is tracked by Carton on the PO. Therefore, quantity 10, quantity discounted ed 9.5 CARTON in po_line_locations_all.

B) rcv_receiving_sub_ledger. The total price is 8.02, with a tax of 0.52. That is to say, the unit price of Carton is 15. the unit price here is from the PO, but in fact, 1 Carton has been changed to 20 Each, and the actual unit price should be 300. but there is also a reasonable one, because only 0.5 Carton is returned, the total price should not exceed the previous total price.

C) The unit of RCV table tracing is the item's Primary UOM. therefore, the data in rcv_transactions begins to show mismatch. 10 Each is accepted, 10 Each is returned, and the subtraction is 0. but 9.5 Carton is left. of course, as a history record table, RT is only responsible for recording the data of each transaction. This data is correct, but a lot of data in other tables is calculated based on RT Data, this results in a data error.

D) There are two records in mtl_supply: 0.5 Carton 10 Each and 9.5 Carton 190 Each. There is a problem here. We should track the Primary UOM, and the quantity here should be 0.

E) mtl_txn_request_lines. The status changes to 5 = Closed. The number is 0. The status is 7 = Pre Approved before Return, and the number is 10. The result is calculated based on Primary Quantity.

F) the data in rcv_lot_supply has a significant error. Before Return, there are 10 Carton and 10 Each. after Return, there are 9.5 Carton and 0 Each. How is this calculated? I guess the two records in rcv_lot_transactions are used to add or subtract 10 Carton 10 Each and 0.5 Carton 10 Each. Then we get the data of lot supply.

11. We can use Correction to remedy the data problem that occurs after Return.

If only the Primary UOM is tracked in the inventory, the number of Receive records above should be 0. however, data may be retrieved from RT. received 10 and returned 0.5, so 9.5 is left.

12. For Receive records, 0.5 Carton is collected more.

13. After finishing Correction, let's look at the data again.

A) The account 8.02 generated by rcv_receiving_sub_ledger is the same as that generated by the previous Return statement. It makes up for the error data generated by the previous Return statement. a negative result is returned.

B) mtl_supply has 10 Carton and 200 Each. The calculation of this table is clever. it indicates that such a bug may have occurred before. although the RT data is incorrect, mtl_supply does not simply add, subtract, and delete the RT Data.

C) But rcv_lot_supply is obviously not as well designed as mtl_supply, and the data is wrong. 10 Carton 10 Each. Because rcv_lot_transactions is wrong.