Tài liệu này có nguồn từ Oracle Support (Metalink) giải đáp về vấn đề: Giá trị hạch toán trong các tài khoản vật tư(của các giao dịch kho) được làm tròn dẫn đến chênh lệch với Giá trị tồn kho (hiểu là: chênh lệch giữa giá trị dư cuối của Tài khoản vật tư 152x với giá trị tồn kho tính theo phương pháp Số lượng * đơn giá).

Accounted value in Material Distributions is rounded leading to differences in Inventory Valuation [ID 1392775.1] To Bottom

Modified:Jan 10, 2012 Type:HOWTOStatus:MODERATED Priority:3 Comments (0)

In this Document  Goal  Solution

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

Applies to: (phiên bản hệ thống)

Oracle Cost Management - Version: 12.1.3 and later   [Release: 12.1 and later ]Information in this document applies to any platform.

Goal (Mô tả vấn đề)

Material Account Distributions Report shows non zero value on materialaccount while onhand balance is zero.

Find a rounding error in MTL_TRANSACTION_ACCOUNTS table where transactionvalues are rounded to two decimals in column BASE_TRANSACTION_VALUE.The sum of this rounded values for receiving transactions is not equal to thesum of the rounded values for issue transactions.

Following is a testcase:

1. The specific Org does not allow negative onhand, and use Average Cost2. Functional Currency is "TWD"3. Create an item PO_TEST014. Miscellaneous Receipt 1 pcs with unit cost $29.67, got Material Distribution following

Cr. Inv valuation $30Dr. Account $305. Miscellaneous Receipt 1 pcs with unit cost $29.67, got Material Distribution followingCr. Inv valuation $30Dr. Account $306. Miscellaneous Issue 2 pcs without unit cost , got Material Distribution followingCr. Account $59Dr. Inv valuation $59

We are expecting the Inv valuation total balance is ZERO, but why the Inv valuation total balance is $1?

WHY?

Solution (Giải pháp)

A big receipt followed by a series of small issues will lead to this situation, as mentioned  many bugs, Developmnet will not provide datafix, the user will need to write-off that amount.

The transaction_value in MTA itself is correct based on your currency's precision. However, regarding the rounding difference in the reconciliation report, today we show it to enable you to do manual GL adjustment.

If the sum of accounting entries in mtl_transaction_accounts matches with that of GL but does not match with onhand_quantity*unit_cost due to the above rounding issue, then it is not feasible to fix.

Please see the 11.5.10 Costing User's Guide on Period Summarization Process and Period Close Reconciliation Report. This report displays the differences between accounted value and inventory in the Discrepancy column.

One example to clarify this could be:

1. The unit cost is 0.001, you first perform a misc. receipt txn with quantity of 10. The accounted value after rounding will be 0.01 in mtl_transaction_accounts and GL.

2. Then you perform 10 separate misc. issue txns with quantity of 1. Each txn will have an accounted value of zero (0.001 after rounding) in mtl_transaction_accounts and GL.

3. Now the quantity based inventory value will be zero (quantity of zero * unit cost of 0.001). However, the GL sum will be positive 0.01 due to rounding. The balance in GL should match the subledger mtl_transaction_accounts and they reflect the facts of accounting of every transaction up to a certain precision.

As we said before, this rounding discrepancy is inevitable and shown in the period close reconciliation report between accounting based inventory value and quantity based inventory value. You can use that discrepancy to do manual GL write-off. There is nothing else we can do about it unless you consolidate quantity in transactions or increase the currency's precision.

In Averge Costing, each issue transaction non cost owned will insert a record in MCACD (MTL_CST_ACTUAL_COST_DETAILS) with the current average cost or the average cost group.

The actual inserted in MCACD (MTL_CST_ACTUAL_COST_DETAILS) for example is 0.001 in the currency USD rounding at 2 decimal digits.

The code flow:

CSTPACIN.cost_inv_txn   ->CSTPAVCP.cost_processor     ->CSTPAVCP.compute_actual_cost     ->CSTPAVCP.current_average_cost   ->CSTPACDP.cost_txn     ->inv_cost_txn       ->inventory_accounts

At the inventory_accounts the cost is pulled fron MCACD per cost element and inserted into MTA (mtl_transaction_accounts) using the currency rounding of the Set_Of_Books

USD is rounding at 2 decimal digits.Each issue transaction the test case is doing has the MCACD at 0.001 which rounded for USD to 0.00.When you are receiving 10 * 0.001 USD material into INV, you are creatingDR INV 0.01 (in the USD roounding limit)

When you are issuing per unit at 1 * 0.001 from INV, you are creatingCR INV 0.00 (rounded from 0.001 outside USD rounding limit)

I think this is a classic rounding issue in accounting. If you would like to account for an amount of 0.001, you would need to increase your accounting currency's precision. Otherwise, to minimize the situation, you can consolidate the quanitites and perform a relatively large transaction instead of many small transactions.

It is not feasible to fix the accounting issue itself. The transaction_value in MTA (mtl_transaction_accounts) itself is correct based on your currency's precision. However, regarding the rounding difference in the reconciliation report, today we show it to enable you to do manual GL adjustment.

The following example could illustrate the causes:

1. Do an intransit shipment with quantity of 1000 at a frozen cost of 1.001, the accounting entry for intransit will be: Dr. intransit account with 1001

2. Do three partial receipts for the corresponding shipment with quantities of 400, 400 and 200, the accounting entries for intransit will be: Cr. intransit account with 400 (the .4 is cut off due to the minimum accountable unit setup). Cr. intransit account with 400 Cr. intransit account with 200

Now when you sum all the above up, you would get a balance of 1. From Costing and accounting perspectives, there is nothing much wrong. The balance of 1 due to inherent rounding can be written off through an adjustment. This has to be done manually today.

Please note that the above rounding phenomenon happens not only to intransit inventory, but also to regular inventories. You could do a large miscellaneous receipt followed by a series of small issues, then the inventory valuation account would be left with a small balance.

The options would be to increase the currency's minimum accountable unit, or reduce the occurrences of partial intransit receipts, or write off the rounding amount manually.

Another example:

Intransit shipment txn: 383435597, qty: -437, standard cost: 54.349, debit intransit: 23751

There are two partial receipts for this shipment.

First Receipt txn: 384768025, qty: 198, standard cost: 54.349, credit intransit: -10761

Second Receipt txn: 384768035, qty: 239, standard cost: 54.349, credit intransit: -12989

You add the intransit debit/credit together for the above three txns, you get a balance of 1.

This rounding problem is due to setup and underlying accounting architecture and its not feasible to fix.