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.
The Good is definitely the way to go. The way I have handled this in the past (thankfully it’s the same way you suggested) is to also rename the old item that was incorrectly setup (Stick OLD_ infront of it or ZZZ to make sure it appears at the end of your list).
Doing the rename will shift all of the old transactional data to the old item and this allows you to set up the new item with the same Item No. This keeps all of the warehousing and customers happy as they never know what you did but at the same time keeps all of the financial transactions and traceability there so the bean counters and Tax man are happy too.
Yeah, great point! I’m a bit jealous now that I didn’t put it in my post, and I let you outsmart me 🙂 By renaming it you can keep the change totally transparent to your people. But blocking it is esential – because people might still use the document copying functionality and copy one of the old documents, which won’t work in case the item is blocked, but might cause new postings against these not-to-be-used items. Furthermore, you can also add a default filter to the Item List form, which would show only non-blocked items by default.
Nice post!
+1 for RENAMING the record, when you’ve got NAV installed on multiple subsdiaries, often creating a new item will not be option since all the countries share the same item list.
@Tarek: yes, it is technically possible to rename the record, however this may lead into audit issues. If you rename your old item no. into something new, there is no match between the printed documents and system information, and depending on your legislation and accounting principles, your auditors or tax authorities might dislike this.
This is about your good solution. What if a firm is not in a position to change the Item number. For example a Dell dealer who maintains inventory numbers by a specific manufacturer’s part number?
@Anantha: First, welcome to the blog, and thanks for comment. If a firm is not in a position to change the item number, then there is a solution with renaming the item – rename the old item into something like XYZ-OLD, then create a new item with the same number, and correct costing setup. But still, I find it a bad practice to match one’s own item number to vendor’s item numbers. NAV has item cross references functionality which enables keeping of vendor item numbers and using those item numbers in vendor-related processes.