This blog post is brought forward from my old blog to be linked into my new book.
Ok, let’s go back to what matters. The cool stuff about NAV 2013.
At NavTechDays Antwerp I did a deep dive into the changes that are made in Dimensions. In the comming blogs I am going to share this.
What are dimensions
Dimensions are first introduced in version 3 as a replacement for project and department codes and have two main functional purposes. The first is restriction checks on posting. We can for example give a G/L account a mandatory product dimension or vice versa block a certain dimension or dimension value for posting. The second purpose of dimensions is data analysis. Using dimensions allows us to define analysis views that we can use for reporting and analysis.
The main elements in Dimensions are Master Data, Journal and Document registration, posting and analysis.
Problems & Challenges
Let’s look at the problems and challenges we have with Dimensions and the reasons for the redesigned in NAV7.
Storage Firstly we have the storage issue. Dimensions can consume up to 33% of the space in a database.
Performance Moving the data through the database takes a cut out of the performance. This is at least 30 % even if you don’t use dimensions.
Coding I think many developers here agree, to take dimensions into account when posting a journal or document you need quite a substantial piece of coding.
Let’s compare the design pattern in NAV 6 or earlier and NAV 7.
If we look at the first part, master data, we can see that there are almost no changes in the masterdata part of dimensions. A special one in this list is the Job Task Line dimensions. Microsoft considers this table master data, also because you can assign multiple dimensions.
The biggest change is in the way dimensions are assigned to journals in documents. All the tables that are designed for this in previous versions have been replaced by one new table Dimension Set Entry. In this table NAV stores all used dimension combinations. Rather than storing all separate dimensions for each record, each record is assigned to a unique set combination.
This allows us to do what I personally consider the nicest change in this new architecture, to move the dimensions through the posting routines, all you need to do is assign the correct Dimension Set ID.
To analyse the data, codeunit 410 has been changed. This codeunit has always been a bottleneck in Dynamics NAV for performance reasons. In Dynamics NAV 7 this is based on the new query object.
The Dimension Set is the biggest change in NAV 7.
Each table that contains dimension information should contain a new field Dimension Set ID. In the core product this is always field 480.
Calculating the SET ID is done in codeunit 408.
This codeunit is also been on a huge diet. Because there is no longer need for the data moving functions 50% of this codeunit has been removed. Perhaps even more because the new code for the Set handling has been added.
Each table should have a new function for showing the dimensions. This is done using the dimension set entry table as a temporary table.
— To Be Continued —