Ledger account combinations - Part 3 (Structures and constraints)

Introduction

Continuing this series of blog posts, we will cover the Structures and Constraints regions highlighted in pale yellow in the model below in figure 1.

As previously stated, the Dynamics AX 2012 dimension framework expanded on the previous release by allowing unlimited dimensions. Along with this change was the new ability for the user to specify which dimensions to include in which order when entering a ledger account combination and to constrain the values that can be entered for each segment in that ledger account combination.

 

Figure 1: Structures and constraints in framework

Account structures

An example of an account structure appears below in figure 2:

Figure 2: Account structure configuration form

 This account structure, stored in the database in the DimensionHierarchy table, is set up to require the entry of a Main account as the first segment of a ledger account combination, followed by a customer and license plate number as subsequent segments. This is the hierarchical order definition and is stored in the database in the DimensionHierarchyLevel table.

 

Figure 3: Structure query results

Along with the order is the definition of constraints or the criteria that defines the valid combinations of values. In this example, all segments must have a value for the combination to be considered valid. Any existing value (already existing in the backing entity) may be entered and there are no specific restrictions on the combinations of values that are valid. This criterion is stored in the DimensionConstraintTree, DimensionConstraintNode and DimensionConstraintNodeCriteria tables.

 

Figure 4: Simple constraints query results

The above example in figure 4 shows the most basic constraint tree. Each of the 3 constraint nodes have a * (any existing value) constraint criteria (stored as % in SQL and shown as "<all values>" in the UI) associated with them. These constraints are used to both show what values may be entered for each segment using a lookup, and validate values entered in the segment. These constraints will eventually result in validation errors if improper values are entered for a ledger account combination.

The dimension framework allows for significantly more complex constraint trees where the value entered in on one segment drives the valid values allowed in the subsequent segment. An example of the versatility is shown below in figure 5: 

 

Figure 5: Constraint builder form

Thus, a more complex constraint tree is shown in the following example:

Figure 6: Advanced constraint tree expanded on form

Resulting in the following constraint definition:

Figure 7: Advanced constraint tree query results

Note that in the case of entering [ 150 - B ] for a main account and customer, that the user must enter a specific license plate number as well. However, if the user enters [ 150 - W ] for a main account and customer, then no license plate number is required. In both cases however, the user will always see 3 segments in the ledger account combination, even if one of them is left blank. Examples of the effects of these structures, segments and constraints on the entry of a ledger dimension account will be provided in a subsequent blog post where we will discuss entry of ledger account combinations and their storage.

In case the user would like to only show trailing segments when they are required to be entered, then advanced rules can be combined with the account structure to provide the additional versatility. Advanced rules will be explained in the next blog post.