Dimensions in NAV 2013 – Part 3 (Extension)
In this final entry on dimensions, I am going to explore some of the ways you might modify Microsoft Dynamics NAV 2013 to better utilize the existing dimension functionality. While I always make the case for stock functionality first, some light customizations to the dimension interactions can be well worth the small impact on the database. These include:
- Code-enforced integration between parent record and matching dimension (ex: customer numbers matching “customer” dimension values)
- Direct views and edits of shortcut dimensions (i.e. 3 through 8) on records
- A user-interface to change dimension history for one dimension based on another dimension (ex: change all posted departments from X to Y where the customer dimension is Z)
- A GL/dimension tool that allows you to define invalid combinations of G/L Accounts and dimension values - similar to how Dimension Combinations allows you to prohibit invalid dimension-to-dimension combinations
Code-Enforced Integration
This change allows a one-to-one relationship between a parent entity (ex’s: Customer, Vendor, Salesperson, Item, etc…) and a matching dimension. It can be enforced in a two-way manner (updates to either the parent or the dimension value are validated against the other) or one-way (only a modification to the parent will modify the dimension value, but not the other way around). In either case, the entry of a parent entity will create the related dimension and assign it as a ‘Same Code’ dimension on the record. This allows users to be 100% hands-off the dimension from initial creation to use throughout NAV.
Direct Views and Edits of Shortcut Dimensions
The two dimensions deemed most appropriate through setup (i.e. “global” dimensions) are available on main records (customers, etc…), headers (ex: purchase order), on posted records, and everywhere else in NAV. Sometimes, this visibility is also valuable for additional dimensions. While you will always want to be selective in the extension of this visibility, it can be employed almost anywhere. As an example, if a company defined a number of dimensions on purchase order headers and wanted the user to be able to quickly enter these on the card as well as sort open orders by the values, this change might be justified. On the other hand, I would usually recommend against a request to add all six shortcut dimensions to all posted document and ledger entries. That is better handled through user training and possibly other pages/views.
History Change Utility
Despite the best intentions of any accounting department, some things can be created and used before they are really ready. As an example, sales might need a customer created in order to create a quote. The customer is created quickly and soon the quote becomes an order and an invoice, the customer places more orders and, before you know it, a moderate amount of history is in place. If the time sensitivity on the customer creation did not allow for adequate reflection on what dimensions should be assigned, you could have an inconsistent bit of history. Sometimes setup requirements cannot be implemented to prevent such a scenario because of other business requirements. In these situations, a tool to update one dimension value in history based on another may prove valuable. In this example, if the missing piece of information was the department value, the utility could be run to assign department SALES to all postings with customer XYZ.
General Ledger / Dimension Combination Exclusions
NAV provides a tool with which one is able to define invalid relationships. As an example, Department ADMIN may be invalid when Region EAST is used. This works very well, but does not allow for more complicated dimension rules based on G/L accounts. A table, page and some hooks back into the G/L Account table and posting code can allow you to define prohibited GL / Dimension combinations. As a final example, G/L account 5200 may be acceptable for all postings except those for Departments PRODUCTION and WAREHOUSE. This interface allows you to define that rule and prohibit these combinations from being posted.
There are innumerable light modifications possible to improve an environment for specific business requirements. You will always first want to ensure all stock options have been explored and exhausted. Once that’s been established, you may want to consider a minor customization specific to your business that strikes the right balance of database footprint and improved workflow.
For more on Dimensions in NAV series, check out Part 1 - Improvements and Part 2 - Deployment.
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.