View Convergence 2013 session on Microsoft Dynamics NAV dimensions here

If you’ve enjoyed this month’s 15 days of NAV dimensions series, and would like to hear me speaking about dimensions, there is now a recording out on the Convergence website as well as on the Virtual Convergence website.

If you were a registered Microsoft Dynamics Convergence 2013 attendee, log in to the Convergence site and bring up the Schedule Builder. From here you can view a recording of any session that was listed as a concurrent or deep dive session, and you can even re watch the keynote and general sessions! You can search by any number of methods for my session, which was called Tips & tricks for working with dimensions in Microsoft Dynamics NAV, and ran on Thursday, March 21st at 2:30. Click the link to watch the session video.

virtualconvIf you were not able to attend Convergence this year, there is a Virtual Convergence that is available to the public. You’ll need to log in to register, but once there, you’ll have the same access as Convergence attendees to concurrent, deep dive, keynote, and general sessions. In order to find my session, search under the sessions menu, then Microsoft Dynamics NAV, then scroll down until you see the box that contains Tips & tricks for working with dimensions in Micro . . .dims virtual

There are a lot of great sessions out there available for one year past the close of Convergence 2013, so I bet these will only be out there until the end of February 2014. Take some time to explore what else is out there and share with your coworkers! This is a great way to get information into your company about the ERP you have all chosen to run your businesses.

Enjoy!


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.


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.


NAVUG spotter at Convergence: Where will you find finance users?

navug with nameThis year, the NAVUG (NAV user group) is more active at Microsoft Dynamics Convergence than ever before, offering 19 sessions given by end users who use the software every day at their companies! There are plenty of opportunities to attend sessions on finance topics and to meet other finance end users.

On Monday, there is a session offered by Robb Delprado, President of Western Data Systems, on fixed assets, and a session on account schedules being offered by Kerry Rosvold (me!).

Robb and Kerry join Dave Wiser, Controller at Tillamook Cheese, and Lee Weiner, Chief Financial Officer at The Bradshaw Group, Inc. as peer experts for two sessions of Ask Your Peers: Finance Professionals, on Tuesday and again on Wednesday.

On Thursday, Kerry returns to do a session on dimensions, and Andy Snook, President of FastPath, offers a session on audit compliance.

All of these sessions are made possible by the NAVUG and the participation of their users!  Don’t forget about the roundtable discussions on Monday as well.  There are tables planned for CFO/Controllers and Cost Accountants where free discussion will be facilitated by user group leaders.  These are great opportunities to meet other end users who use NAV every day, just like you do!


The finance professional’s perspective on NAV dimensions (part 3 of 15)

As the finance person for your company who will make decisions about dimensions, you bring a unique perspective to how dimensions can be valuable in your accounting department. Some of the concerns you have will surround reporting requirements, some will pertain to consistency and control, and others will relate to efficiency. Let’s go through each of those concerns.dimsfinance

Efficiency

As a corporate controller, I’m concerned that my staff work in an efficient manner. In regard to coding invoices or general ledger entries, this means they shouldn’t need to look up a lot of information and they don’t engage in any more data entry than they absolutely have to. When choosing how dimensions will be set up in NAV, you can make some specific choices regarding how data can be populated. Do you want the coding to come in as a default value? Are your coding relationships rule-based enough to make that possible? Are there some things you can populate to always default so the coding appears as if by magic 100% of the time and an employee never needs to be responsible for making a coding decision?

Consistency and Control

In the same way that I’m a stickler about operating efficiently, I’m even more so about having consistency and control. If you ever work with me, at some point you will hear me say, “we do not allow optional data”. This means we don’t gather dimensions for some data and not for others. I use the default value code mandatory a lot in my system. This setting will force a dimension to be populated whether it is through a default value or by a person, but it will never allow the data to come through with a blank value, creating holes and reduced value data in my reporting.

Reporting Requirements

Ultimately, you’re using dimensions in your ERP system so you can get great reporting out of it to make important business decisions. As your company’s finance professional, you know what you’re reporting on now. Take a minute to think about that. Is what you’re reporting on still relevant or is it what you’ve always reported on? Has your business changed? Does your reporting need to change too? Think about what your business really needs to see in its reporting and structure your dimension choices to match.

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