Resolving NAV dimensions errors (part 10 of 15)

Error messages related to dimensions can be the bane of a dimension-using NAV user’s existence unless you know how to properly deal with them. The number one thing I tell my end users is, “if the error message has the word dimension in it, the error is generally something you can resolve yourself”. Let’s go through three dimension errors from my system; we’ll resolve each one as we go.

derr1This message says the end-user needs to select a dimension code for team on the first line of this invoice, where they’ve entered general ledger account number 51320. For whatever reason, NAV counts lines by the 10,000, so 10000=line 1, 20000=line 2, etc. The rest of the error message is pretty self-explanatory, but is presented in an “out-of-order” way that doesn’t quite read as well as plain English. This error has occurred because we’ve set a control on the general ledger account 51320 of code mandatory for team. The end-user needs to enter a team code for every transaction that posts against this account number.

derr2

The dimension value of 522120 on the list of dimensions for project has been blocked. You can’t use it/you don’t want to use it/you shouldn’t use it. Our company goes through annually and blocks project numbers that have not been given any budget money. If I block a project, I mean it – I really don’t want anybody posting anything against it. For this error, either the person made a typo, or they were given bad coding so the solution is to either fix the typo or get a correct project number.

derr3

This is an example of a team and project combination that has been blocked for use. We do this on purpose in order to keep from making errors and to avoid needing to make reclassifying entries. For this error, the person entering the information either needs to correct a typo or get a correct project number (or team number).

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


NAV dimension priorities (part 9 of 15)

Here’s the deal with dimension priorities. Depending on what you’ve chosen for your dimension strategy, an entry could have more than one dimension proposed at the time you post it. When this happens, NAV needs a way to break the tie, and that way is dimension priorities.

dim priorities

This handy-dandy table allows you to be in control by choosing which table will take priority over the other if NAV is forced to choose. What happens if you don’t define the priority? This is where NAV’s built-in tie-breaker comes in. If you don’t define the priority, NAV will choose the table with the lowest Table ID number.

One sure way to avoid needing to do this at all is to think through your dimension strategy really carefully before you commit to it. If you define team as a dimension on both your customer master data and your item master data, and you give a customer and item different default dimensions, what’s going to happen when you post a sales order? You’re going to get a conflict where the system has to choose. Think through your strategy and I bet you can find a way to make sure that team only corresponds to customer and you could give a different dimension designation to item. By doing so, you’ve automatically designed your system not to have a conflict in the first place.

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


NAV dimension combinations for additional accuracy (part 8 of 15)

One way to get additional accuracy out of your NAV dimensions is to assign dimension combinations. Dimension combinations are really good for two things:  1) to keep you from posting something that simply doesn’t belong where you’re putting it, and 2) to keep you from posting a combination of dimensions together that don’t belong together. Let’s go through a couple of examples.

Say that, according to your dimension strategy, you’ve designated the dimension team to go with customer master data, and the dimension edition to go with item master data. If you don’t want team to ever be allowable together with edition, set a dimension combination of blocked on the grid where the two dimensions intersect.

Another example is something we do at my company. We rely very heavily on budgeted information and budget all of our product development expenses with two dimensions assigned: team and project. Each team has their own list of assigned projects and no team should ever share a project. In order to keep ourselves from having a lot of reclassification entries, we assign a dimension combination of limited on the grid where team and project intersect. dimcomboThis setting allows us to further drill down and define which projects belong to which team. If we receive bad coding or even just enter a project number incorrectly, if that project number is not one on the “approved” list of project dimensions assigned to that team, we’ll get a message that lets us know we’ve made an invalid choice before we post it into our system permanently.

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


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.


Viewing NAV dimensions on postings: where can you see them? (part 5 of 15)

Inevitably, once you’ve dipped your toe into the world of dimensions, the next thing you’re going to want to know about is the difference between global and shortcut dimensions.

dims1Global dimensions are the two most important dimensions you can choose because global dimensions are the most accessible from anywhere in NAV. They are posted with every transaction you have attached them to, right along side the data, and you can see them on every form as an available choice without having to do anything special. You can see them right along with all your other data in forms (like a sales order or purchase invoice), in journals, in posted history, and global dimensions are even available for selection in every canned NAV report.

dims2

A common misconception about global dimensions is that they must be department and project. This simply isn’t so, and in my opinion, is an old holdover from thousands and thousands of NAV demos that use the CRONUS database, where the globals they have used as their demo example are department and project.

The global dimensions your company chooses should be the two most important things your company needs to report on when looking at your financial data. If your company is very customer-centric, maybe one of those globals should be customer related. As an example, if your company groups their customers by wholesale or retail, and uses this designation as a major reporting category when looking at your sales each month (or each day!), you may want to choose this “customergroup” as one of your global dimensions.

If your company is very inventory-centric, maybe one of those globals should be item related. My company has a large number of SKUS, so we find it absolutely essential to relate our global dimensions to our inventory items in order to make sense out of our sales data. We’ve designated a global dimension called PGC or product group category to allow us to group our large list of items into smaller groupings that are easier to digest when we produce reports. In addition, we also use a global dimension called edition that has a one to one relationship with each item we sell. With these two global dimensions, we can look at our sales by large group of items as well as item by item. This comes in mighty handy when it’s time to evaluate gross margin. We can get a macro and a micro view of what’s going on with our gross margin without having to do a lot of digging into the data.

You may have an even different emphasis on what your company needs to monitor. I’ve seen lots of companies who depend heavily on their dimension reporting to allow them to monitor what is going on per salesperson or territory or region. Spend a good amount of time talking this over with your company stakeholders. What really matters? What should you be looking at? Remember too, that just because you are reporting on one measure right now doesn’t mean it’s the right measure to be reporting on in the future. Figure out what those two most important things are, and designate them as your global dimensions.

Shortcut dimensions are what you’ll begin to use once you realize that two dimensions simply aren’t enough! The single largest limitation to shortcut dimensions is that they are not as readily available as global dimensions. They do not have those two designated always there fields that the globals hold. Technically, you can have an unlimited number of dimensions in total, but shortcut dimensions are special because they are more reachable. By designating a dimension as a shortcut dimension, you are making that dimension available as a choice on your forms ((like a sales order or purchase invoice), in journals, in posted history, and in every canned NAV report. The trick is that they don’t show up automatically, and you’ll need to go to the show column area on your forms and purposefully choose them for use the first time.

When you’re looking at posted history, you’ll need to use a new trick to see shortcut dimensions. As an example, choose some transactions from your chart of accounts. You’ll be on the general ledger entry table. Now choose entry and g/l dimension overview. You’ll now get a view that looks like what I’ve pasted below, showing all your shortcut dimensions as well as the global dimensions.

dims3

Another perspective on shortcut dimensions is one of efficiency. You will always want to set up a dimension as a shortcut if your end users need to access the field in order to enter or change data on a regular basis. An example of this from my company is our shortcut dimension, team. For all expense accounts, we designate a team in order to track who incurred that expense. My accounts payable person must enter that information for every expense related invoice because the computer simply can’t be trained to make all the decisions she must make in order to determine whose team gets the expense. Team is a shortcut dimension for us because she can set that field up on every form she uses so it is available for her to use for data entry right on the form, keeping her from having to go anywhere else to enter that information.

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


Why finance and IT need to work in partnership on a NAV dimension strategy (part 4 of 15)

Business Colleagues Working with LaptopWho’s responsible for determining which dimensions are used, keeping the database clean, and trouble shooting dimension problems – IT or Finance?  The answer really should be BOTH!

While your company’s finance NAV expert has a perspective on dimensions related to financial reporting outcomes, control and consistency of data, and accounting staff efficiency, your company’s IT NAV expert will have a different perspective.  Many times, the task of resolving dimension errors, data collection disconnects, and database size and speed fall on the shoulders of your IT team.

By working together on establishing what your company’s strategy is on how dimensions are implemented, used, added, and changed, you can blend the best of both worlds and make sure everyone’s interests are represented. Everyone on the team, no matter what their role, should understand why you’ve chosen to use code mandatory instead of same code and how dimension use for items differs from dimension use for customers. Knowing what your global dimensions are, why they have high priority and visibility in your reporting structure, and how to get your hands on data related to shortcut dimensions is useful to both groups as they formulate new reports for the company.

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