Add NAV dimensions as your business changes (part 14 of 15)

compassSetting up dimensions should not be something we exclusively do when we implement NAV for the first time at our businesses. Change is the norm in business, and I would be genuinely surprised to hear from anyone at this point that their business has not changed significantly in the last five years. So for finance and IT professionals, what changes when the business changes? Reporting requirements!

For NAV, that means opportunity for using dimensions differently or to add new dimensions. Hopefully you are happy with your global dimensions, the two most important dimensions for your company, and you’re ready to add some shortcut dimensions so you can expand your reporting capabilities. There are four main things you should keep in mind when adding a shortcut dimension.

1) Keep in mind timing and financial cutoff. If you choose to start collecting data on a new dimension today and today falls in the middle of a fiscal period, you’re going to create a disconnect in your financial data where you have data with the new dimension value and data with the blank dimension value in the same period. Don’t do it. Find out when the end of the fiscal period is, and start gathering the new data starting with the start of the new fiscal period. This doesn’t have to be the year-end, it could be a month, or whatever period you have at your company, but do take the time to plan this out, your finance department will thank you later.

2) Know that collecting a new dimension will not magically attach to your historic data. Assigning dimension data to your item or customer or vendor only begins the collection of that data on any new transactions generated since you assigned the dimension data. There is nothing out there that will magically attach this new requirement to old historic data. There are ways to go back and change the historic data, but this is generally beyond what you want to do manually. Involve someone experienced in SQL or call your partner for some help with this. And for goodness sakes, try this in a test system first. It’s always good to do a practice run on this kind of change, and should be mandatory if you’re planning to change a large amount of data. Remember that in many cases, it is perfectly ok to collect new data without catching up the history. Only you can decide what you need for your reporting.

3) Don’t abandon your pending data. Don’t forget there are things out there you created prior to assigning that new shortcut dimension. Sales orders, purchase orders, transfer orders and any other type of form that may be in process at the time you defined that new dimension will need to be caught up to the new requirements. If you forget this, NAV will remind you by throwing a dimension error when you, or your colleagues, try to post those documents to the system.

4) Consistency is the key. Make sure you set up this new dimension with the same level of consistency you’ve used with your other dimensions. Start with your master data, but follow through by adding the safety net of the chart of accounts, and remember to incorporate your choice of value postings.

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.