NAV default dimensions and value postings applied to master data (part 6 of 15)

You’ve decided you want to use dimensions, you’ve picked a strategy, you have people in both finance and IT on board with the plan, and you even have two global dimensions and a few shortcut dimensions all planned out. Now what?

Now you need to go through the process of applying your dimension strategy to all of your master data using value postings.

Master data are all the things in NAV that have a “card”.  When you think about the sales process in NAV, what might have a card? How about the customer card, the item card, or even the salesperson/purchaser card? Where else are there cards in NAV? How about the vendor card, the bank account card, or the fixed asset card? All of this is master data you will use when applying dimensions to your system.

Value postings are the requirements you set on your master data when defining dimensions.  For the sake of an example, lets say we’re going to focus our dimensions on the item card. You have four choices:

4choices1)  Leave the value posting blank. This will impose no requirement for the dimension to be filled out and is the same as not defining a dimension.

2)  Choose code mandatory. This option can act in two different ways and is highly useful. If you leave the dimension value code empty, setting the value posting to code mandatory will require the end-user to fill in a dimension value code from the defined dimension code listing before the transaction can be posted to the system. If you fill in the dimension value code with a selection from the list, essentially a default value, any transaction using this item card will populate the dimension value code with the code you have pre-selected as a default. However, if necessary, the end-user can change the value to a different selection.

3) Choose same code. You might think this would be a fantastic option, offering the highest level of control. It is true that choosing same code is the most restrictive. By choosing same code, any transaction must use the code defined in the dimension value code. This can become problematic when your company changes and you need to redefine your default values. Dimensions can be pretty pervasive, getting into places you just didn’t think about when you set them up. For the most part, they’re harmless, just little pieces of data hanging out waiting to be accessed for reporting. But sometimes, when used together with same code, they become vicious nasty little roadblocks. I’ve heard many a horror story of accountants struggling with adjust cost or inventory adjustments or even trying to get sales order postings to finalize because they’re using same code and have needed to make a necessary change.

4) Choose no code. This is the option you choose if you want to tell NAV to never assign a particular code to the item. You could do this if you wanted to reduce the possibility of error from someone trying to apply a dimension that belongs to your customer card to your item card accidentally.

dimdefaultAs you can probably tell, my recommendation is to use code mandatory in most situations. It offers the most control over your data while also allowing for necessary flexibility as your business changes. Using code mandatory avoids the problem of “optional” data by requiring some type of data to show up in the dimension value code, whether you put it there as a default to be automatically populated or whether you’ve left it blank so someone down the line can populate it when it is time to make that decision before posting. Using code mandatory can also be a great source of efficiency if you can choose to use default values. If you can decide how to make your dimension postings as automatic as possible, this really can run completely in the background, populating your system with luscious data to be reported on later, with no effort or decision-making required by you. By using default values, you also gain accuracy in your postings since the computer is making the decision the same way every time, whereas you might not be that consistent if you had to define the values manually all year.

Keep reading this month as we continue our series, 15 Days of NAV Dimensions.

4 questions to ask when deciding how to use NAV dimensions in your business (part 1 of 15)

If you’re just getting started with Microsoft Dynamics NAV for your business, you’ve probably heard the term dimensions, but you don’t really know what that means yet. You may be someone in the finance area for your company, or you may be an IT person. Eventually, at some point in your planning process, your partner is going to have “the talk” with you. This is an important talk, and it can be a little scary or even a little bit embarrassing, but it is absolutely necessary. The talk will probably start with,  “have you thought about how you’ll clean up your chart of accounts”, or “we need to discuss how you will restructure your chart of accounts”, or “you could realize some serious efficiencies in your posting processes by reducing your chart of accounts”, or “holy cow, 4000 accounts is a whole lot, how do you remember all that?”.

Here are the four questions you should be asking yourself when deciding if you need to use dimensions at your company:

1)  How long is your chart of accounts?

2)  Do you recognize a number that looks like this?  01-810-51320-627539

3)  How often do you answer this question?  How do I code .  .  .

4)  How many reclassifying entries are you making every month?

You might get the idea by now that using dimensions allows you to clean up your chart of accounts, reduce it in size, and increase your efficiency by doing so, and you would be exactly right. At its most basic, using dimensions will allow you to replace your old multi-segmented account numbers


with something that looks a little bit more like this.

dimensions grid

Keep reading this month as we continue our series, 15 Days of NAV Dimensions.