Communicating to IT about NAV dimensions and NAV2013 dimension sets (part 13 of 15)

Today I’ve got some old news and some new news for you regarding dimensions, but first I need to re-emphasize that finance and IT must be of one mind when it comes to dimensions. As a finance professional, you’ll definitely have your perspective on how dimensions will help you to efficiently produce financial reports with control and consistency. But remember that finance and IT need to work in partnership on a NAV dimension strategy in order to be really successful. One way these two roles must work together is regarding how to get your hands on posted dimension data in NAV. If you’re using NAV only tools to get your data, you won’t need this information, but once you progress to using outside reporting tool packages, you need to know a little bit more to get your collective hands on that data.

Here’s the old news: if you are using any version of NAV prior to NAV2013, dimensions are kept in a separate table behind your main data. You can see this, though it may not be obvious to you, when you populate dimensions using Ctrl-Alt-D or when you view dimensions through the dimensions button from master data. This table is actually called the default dimensions table (table #352). If you’re using something like SQL for reporting, you’ll need to perform a join between this table and the table(s) to which the data are related. As of today, the large majority of NAV users are using versions prior to NAV2013, so this is important information to have if you’re to get all the data you want into your reports now.

Here’s the new news: With NAV2013, dimension sets are turning dimensions upside down, treating them in an entirely different way, in order to make the way dimensions are stored in NAV more efficient. We’ve all heard the horror stories of ginormous databases with performance problems due to overuse of dimensions. Those stories have always been frustrating to me because it seems we should be able to use dimensions in as robust a manner as we can handle. Well, Microsoft has made a great improvement with the creation of dimension sets. I’ll admit that explaining the mechanics of exactly how dimension sets work is beyond my technical capability, so I’ll hand that off to experts more talented than I. I did get to see a presentation by Jesper Lachance where he showed an example (which he allowed me to share in my recent Dimensions presentation at Microsoft Dynamics Convergence 2013) that shows a twenty fold decrease in number of data items stored by using dimension sets instead of the pre-NAV2013 method.

Faithie Robertson of Archerpoint has a fantastic article A Better Mousetrap! Dimension Sets in Dynamics NAV 2013 (Navision) which does a really great job of explaining exactly what a dimension set does differently.

If you’re looking for a textbook explanation, visit MSDN on their page Dimension Set Entries Overview.

Encore Business Solutions has an illustrated guide NAV 2013 – Dimension Sets.

You can see why, with dimensions being stored in a separate table, and with dimension sets showing up as a new improvement, everybody on the team needs to understand how dimensions work, where they’re kept, what your particular company conventions are, and how you’ll report against them accurately and effectively. I haven’t heard a lot of feedback yet from end users about how working with dimension sets is working for them and whether it is making reporting better or challenging in different ways. But, the feedback from programmers, developers, and database administrators has been a resounding: THANK YOU MICROSOFT!!!

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