They say the only constant is change. I’d say that the only other constant is error. We humans tend to err. Give a repeatable task to a human, and they’ll mess it up every once in a while. Some call it the human factor.
One of the many repeatable tasks in Microsoft Dynamics NAV is setting up items. If you remember my rant about mandatory fields, and how I said they were baaad, there might be an even more baaad kind of fields: the default value fields. Because the system simply inserts a value into these fields without asking for your say, and if anything is easy, it’s only so easy to overlook these. Yep, you have a chance to voice your oppinion on these, but having got to hurry for a cup of coffe with Mary from accounting, admit it, you’re gonna leave that default FIFO costing method for an item every once in a while, even though it should really have been Average. Then you’ll start posting. Then your phone rings and starts screaming at you about a moron who screwed up items again.
So, what to do when you have set up your items with default costing method of FIFO, which should have really been something else? Or what you do in general when you choose a wrong costing method by accident? You might try going there and changing it to the correct value, which will work only if you haven’t ever posted anything against this item. Otherwise, you’ll get this:
I’ve heared people ask about fixing this mess, and what they can do about it. And unfortunately, the only correct answer is: not much, really.
The problem is that costing method is not just a value in the item card. It’s a gremlin. It consists of all sorts of other gremlins affecting your accounting information contained in your general ledger. When you keep your records about items according to one costing method, you can’t just decide to switch over to another, because it has potential to make all of your figures in your inventory accounts simply incorrect. Accountants won’t like it. Management surely won’t like it. Tax people probably won’t like it either.
If you google it, oops sorry, if you live it (doesn’t sound nearly as groovy, does it, eh?), you might stumble upon three advices. The Good, the Bad, and the Ugly. Let’s start from the back.
- The Ugly: If you licensed a Solution Developer granule, whaddaheck, just design the Table 27 Item, and comment out the problem maker code in Costing Method OnValidate trigger. It’ll make the error go away. Well, this kind of solution really reminds me of Douglas Adams’s The Hitchhiker Guide to the Galaxy, where the technology was so smart that any device was so smart too, so they had smart sunglasses which would go totally black in face of any danger, to prevent you from panicking. This costing method “solution” pretty much compares to how these sunglasses handle the crit-sit.
- The Bad: Go and close the inventory balance for the item with wrong costing method. You are sure you did so when you filter the Item Ledger Entry table by the Item No. equal to the problematic item Item No., and Open equal to No. If it gives you an empty list, you are good to proceed. What you do to proceed is simply go and do The Ugly. Because if your inventory balance is zero, and all the item entries are closed, theoretically The Ugly won’t be so ugly. There are two other uglies to this, however. First, this is only theory. NAV isn’t really going to cope with this if you start posting a lot of later item charges, returns, cancellations and so. I’ve seen all-closed zero-balance non-zero-value inventory, and it was a bitch. Second, your tax authorities won’t like this too much, and within an accounting period, or a fiscal year, or depending on your local accounting practices, you might either be required to explain this decision to tax authorities, or might even be prohibited from doing so. So, please check before proceeding, because it’s really not that simple, and not at all that innocent.
- The Good: Go and open a new item. Make sure you don’t miss to set up the correct costing method this once again. Then post a full negative adjustment to the old (wrong) item and a matching positive adjustment to the new (correct) item, make sure the costs are correct. Then go and make sure the old item is really closed (i.e. all of its item ledger entries are closed), then block it and forget it. Your sales, purchases, warehouse and manufacturing people are probably going to complain for a while, maybe a few of your customers might ask a question a few times, but then everybody will just get used to the fact that that item now goes under a different Item No.
I have personally had problems with customers messing up with their Solution Developer granule and doing The Ugly. I’ve seen them try The Bad, too. And I’ve had a customer who simply asked about how to fix the problem, then went with The Good, and it sorted everything out. Not so long a go, I’ve seen a support request asking exactly about how to handle this situation, so it made me make a note in my blog to-do-list, and here it goes. I hope you find this helpful. And I’d really like to hear about your experiences with these, and if anyone could also please say for sure whether The Good might cause you troubles with tax authorities much the same way The Bad can.