3.60 HF15 I post 1,000 units on a purchase order at a total cost of 10,575. the value entries for the purchase show the ‘Cost per unit’ rounded to two decimal places as 10.58 although the ‘cost amount actual’ is correct at 10,575 I decide to right off the stock in an item journal, which rights off 1000 x 10.58 = 10,580 Couple of things: 1. Now got no stock but an inventory valuation and ledger value of 5.00 2. I could change the cost on the item journal line but surely you don’t want to input this every time?? 3. Ran adjust cost… just to be sure and got a value entry adjustment for -0.01 - so now I’ve still go no stock but an inventory value of +5.00 The nub of it seems to be that the unit cost is rounded to 2 decimal places which doesn’t seem to be sufficient. Using FIFO but that shouldn’t make any difference on a simple in-out transaction. Read many threads on here and service system but nothing seems to quite fit this problem. Thanks in advance,
Did you try to uncheck the invoice rounding box in the purchase & payables setup?
Thanks, but there is no invoice rounding on. The rounding precision on the currencies are set to .00001 and the decimal places set to 2:5 There are bucket loads of postings here and on the service system relating to costs and rounding error between 3.01 and 3.70 but nothing seems to relate to this rather obvious issue. No matter what the complex movements of an items - if you have zero inventory, it must have zero valuation - right? The hotfixes not yet applied don’t seem to relate to this either.
Hi Adam, I have just tried (Cronus UK Ltd, GB3.70) and replicated what you have described, I don’t actually think you have a problem! The reason that your value entries are rounded to £10.58 is that your G/L set up “Unit-Amount Rounding Precision” is set to 0.01. (Zoom on G/L setup to check this). Also, when you create a negative adjustment item journal line (qty 1000), the unit amount is fetched from the Item as 10.575, but if your UARP is 0.01 it will round this figure to 10.58. When you (or atleast when I) then posted this negative adjustment it produced: “Item ledger entry” with “Cost Amount (Actual)” as £-10,580.00 and a “Value entry” with “Cost amount (Actual)” £-10,580.00 and “Cost posted to G/L” £0.00. After running the adjust costs and then post costs to G/L jobs: the “Item Ledger Entry” “Cost amount (Actual)” is adjusted to £10,575.00 and there are now two “Value entries” the original entry still showing £-10,580.00 (& Cost posted to G/L £-10,580.00) but an additional corrective value entry of “Cost Amount (Actual)” = £5.(& Cost posted to G/L £5.00) The post costs to G/L report shows both these postings and the net posting is correct @ £-10,575.00 The value entry “cost per unit” on the adjustment you describe is correct @ 0.01 (this is £5 adjustment divided by 1000 units, result rounded up to two decimal places.) By the way I don’t think you should amend your Unit-Amount rounding however (based on advice from others on this forum)! In a nutshell as long as the total for the “Value Entry” adjustment is £5 everything is ok, no? Hope this helps. Jon p.s. it sounds as though you have automatic cost posting on, whereas I did not, however this should not make a difference in the long run.
Thanks for the detailed response Jon. You are spot on that the reason for is the unit amount rounding precision is set to 0.01. I never knew that was hidden there! I still think there is an issue as ultimately I have a value for zero stock qty. Anyway, I’ll work through the rest of you’re detail and let you know… thanks for now.
Actually I reported this to Navision as a “Bug” in version 3.04 (DOS) version of Navision in 1993 (wow 10 years ago[}:)]). At that time I made a simpler example, of buying 333 items at a total purchase cost of $10,000.00 and then selling the items individually to create COGS of $999.99. The response at the time was that this was not a bug, and thus there was no plan to rectify it. At least in 3.70 you can run a revaluation journal to get rid of the difference.
David, I guess selling (or perhaps writing off) all 1000 items individually could result in a difference, but as for writing off (or selling)all 1000 in one go, the postings are spot on. However that said, your scenario is more realistic! I would imagine the kind of slight differences you describe are common place in most applications? Adam, I’m glad I am not the only one tripped up by the absence of this important field from G/L set up form! I have recently had a rant about this very thing because of potential problems with an upgrade, caused by this field being zero in the pre-upgarde database, I am awaiting response from service system on subject, I hope I have a bit more success that David! Regards Jon