Dimensions in NAV 2013 – Part 1 (Improvements)
While I have always been a strong proponent of the power of dimensions, I have only recently been able to fully embrace the execution in Microsoft Dynamics NAV. Many have endured my soapbox speech related to their value, even within the old database structures, and it seemed potentially valuable to finally create this as a brief blog series. The intent of this article (part 1) is to briefly introduce the underlying dimension changes and why those translate to improved productivity. In part 2, I will explore how dimensions are best used in Dynamics NAV. Finally, in part 3, I will explore ways to further enhance the integration of dimensions through some light customizations. There are two pieces of good news with NAV2013 related to dimensions:
- Dimensions were almost completely rewritten, in both tables and posting code
- The use of, and interaction with, dimensions will look and feel the same as in prior versions of Dynamics NAV
As you may be aware, for both documents and ledger entries, dimensions were stored in two places previously: in the two global dimension fields on each record, and in separate posted document dimension and ledger entry dimension tables. This was not an optimal design and stemmed from the evolution of NAV in the early product years. The challenge with the old design was that it required many records and a significant amount of code to maintain what would otherwise be a simple transaction. As an example, posting a one-line sales invoice with four dimension values would result in at least 20 secondary dimension records. This took up space in the database and valuable process time during posting. The new model replaces all of these secondary tables with a single field that now goes along for the ride on all entries: Dimension Set ID. This new field references a single global record representing the unique combination of dimension values on that entry. The four dimensions referenced in the above example would instead be passed as a single integer value representing that combination in a central table. As a result, the posting code is relieved of the burden of managing the dimension records and can now process much faster. Likewise, the centrally stored dimension sets don’t clutter up the database.
The processing speed gains can exceed 50% for environments which truly take advantage of this powerful tool. Likewise, the database size can be reduced by a significant amount. What’s almost equally as impressive is that all of the underlying changes were made without disrupting the user experience. Entering and accessing dimension information is performed just as it has been in previous versions. NAV is executing very different code and querying new tables, but this is all transparent to the user simply looking for the various attributes on a given record. In Part 2, I will discuss how additional dimensions are best deployed now that performance is not the primary constraint.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.