Business Central / NAV UG
Business Central / NAV UG
Organizer:
- Organized by
-
-
Decimal places for Unit/Standard cost
-
Decimal places for Unit/Standard cost
I am having a little trouble understanding the number of decimal places for unit cost/standard cost in BC.
I have an item that has a unit cost of 0.69$ but when I print the Inventory Valuation report I get a value that does not reflect a 2 decimal place number.6,369.80 * .69 <> 4,399.61
It is 6,369.80 *0.690698295079908 that = 4,399.61 and I can see this when I send the same report to Excel
So what is my standard/unit cost? I did a standard cost roll-up and it was for 0.69$.
At least I thought I did, but was it really for .690698295079908.
I can change the on the Gen Ledger Setup to 2:5 so that I get more decimal places to show on the inv val report, but it still isn’t 100% true. And it doesn’t change the Unit Cost on the Item Card, it stays 0.69.
So what is my standard cost .69 or 690698295079908?
How can I trust the Inventory Valuation Report if the Unit Cost is not correct? I guess I can assume that the Inventory Value is correct, but the Unit Cost will sometimes be an approximation. Do other users just send this to excel and reformat the cells to hold more decimal places?
Regards and Thanks
-
5 Replies
-
A couple of things at play here. When you roll standard costs and it calculates to $0.69, that is what any new inbound entries would be valued at. The Unit Cost field on the item card is designed to be the weighted average cost of the inventory you have on hand. This should also be the value on the Inventory Valuation report. The unit costs on the Inventory Valuation is a calculation of the Cost Amount divided by the quantity. So if you have layers in inventory that have different costs, the report will give an weighted average.
I am also tagging Kim Dallefeld on this who may have further insight. @kimd
-
Joseph,
Adding to Dave’s reply… Most user would run Inventory Valuation report to reconcile Inventory to GL, but you should not use that report as it is wrong. You should be running the Inventory to G/L Reconcile report. This will show you the starting Inventory Valuation (dollars) and then your reconciling transactions (Received Not Invoiced, Shipped Not Invoiced, and Manufacturing Output where Production Order is still open). This will also show the G/L Entries posted for each Item and reconcile to the sub-ledger report you just ran.
Try this.
Steve
-
Dave is correct in that the unit cost on the Inventory Valuation is calculated from the value divided by the quantity. However, for standard cost items, the system is ALWAYS and I mean ALWAYS going to use the standard for any transactions.
I have seen a spreadsheet used to load data into BC and though it looks like 0.69 in the Excel cell, it’s really 0.690698295079908. Since BC will store 17 significant digits that number is fine to be accepted. I would suggested exporting your items with the unit cost field and see if you have that issue. Whether you do or not, I would run a Standard Cost worksheet and true up all my costs, making sure to run the Revaluation Journal to true up any amounts that are required.
-
Thanks so much for your help Kim, Steve and Dave.
It looks like I don’t actually have a decimal issue but I still have a problem with the veracity of the Inventory Valuation report. I do think that we should run the Inventory to G/L Reconcile more as it has so much information.
So, the report does not do an on-hand * unit cost calculation to get the inventory value as I thought but does as you say a value divided by the quantity calculation.It gets the Inventory Value by summing the values in the Cost Amount (Actual) field in the value entries for that item, and then divides that by the on hand to get the unit cost.
The cost and inv value are based on the sum of Cost Amount (Actual) of the value entries at a given end date. It starts at a given begin date and calculates the value of the item’s inventory then adds the value of inventory increases and subtracts the value of inventory decreases up to a given ending date.
Regards
The discussion ‘Decimal places for Unit/Standard cost’ is closed to new replies.
