Planning your chart of accounts in AX 2012 (Part 5 of 7)

Organization Hierarchy Relationship with Account Structures

Part 1 of this series provided a high level overview of the components that make up the chart of accounts in Microsoft Dynamics AX 2012. Part 2 focused in on the chart of accounts components. Part 3 talked about the financial dimensions. Part 4 focused on the new account structures that were introduced in AX 2012. This posting discusses the ability to relate an organization hierarchy with an account structure. The components I will discuss in this blog are the following from the conceptual model provided in Part 1:


If the account structure has two or more segments that represent organization units, such as BusinessUnits or Departments, you don't necessarily have to build the constraints in the account structure. If you have an organization hierarchy created that represents the constraints, you can relate the account structure to the hierarchy and the system will adhere to the most restrictive between the account structure and the organization hierarchy.

A limitation of the organization hierarchy in the current release of Dynamics AX 2012 may not allow you to model your organization within a single hierarchy. The limitation is that a child node in the organization hierarchy cannot have more than one parent. So that means that if you are trying to model your organization that consists of BusinessUnits and Departments and the IT Department serves multiple business units, you will need to either create multiple Departments that represent the IT department (such as IT Department - BU1, IT Department - BU2, etc.) or create multiple organization hierarchies. If this is your scenario, I recommend you build the constraints between the segments directly in the account structure and not use the organization hierarchy for the constraints.

If you are able to model your organization in an organization hierarchy, and at least tow of the account structure segments are represented in that hierarchy, you can select to relate the account structure to the organization hierarchy. You don't need to define the constraints again in the account structure. To do this, select the Relationships button in the action pane. The Select relationships form will open displaying all the organization hierarchies that have two or more of the account structure segments represented.

The form can be a bit confusing so I will try to explain what you are seeing so that you select the correct hierarchy(s). For every pair of organization unit segments, you will see the hierarchy listed at least twice. In the screenshot above, I have BusinessUnit, Department and CostCenter all as segments in the account structure. All three are organization units. In the Select relationships form, all organization hierarchies are displayed in which BusinessUnit and Department, BusinessUnit and CostCenter, or Department and CostCenter are defined in the hierarchy. Then each segment is listed as either Party A or Party B and vice versa - thus why each hierarchy is listed at least twice. In my example, I see the Auto BusinessUnit hierarchy listed 6 times as it has all 3 of my segments in the hierarchy. The form then displays BusinessUnit as Party A with Department as Party B, then Department as Party A with BusinessUnit as Party B. Same is true for the other pairs (BusinessUnit and CostCenter; Department and CostCenter).

So which one do you select? Select the relationship that represents the order of entry in the account structure. In this example, if I want to use the hierarchy for the relationship defined between Department and CostCentter, because Department is before CostCenter in my account structure, I would select the relationship where Department is Party A and CostCenter is Party B. This tells the system how to walk the hierarchy in order to filter the values for selection in the lookup when doing entry in the account number control.

You can relate multiple organization hierarchies to the same account structure, but you should only do that if you have more than two segments. In the example above, if I have special constraints modeled in an organization hierarchy between BusinessUnit and Department or BusinessUnit and CostCenter, I could select that hierarchy as well. If you select multiple hierarchies for the same two segments, the lookup will display a union of the hierarchies so the filtering of the lookup may not be as expected.

You can set a color to display in the account structure to provide a visual that an organization hierarchy is providing the constraints as well as the account structure. During data entry and validation of the account number combinations, the system will adhere to the most restrictive rule between the account structure and the related organization hierarchy.

Another thing to note is that the organization hierarchies can only be related to account structures and not to any advanced rules. So if you want to use the organization hierarchies to provide the constraints for the account number combination, then you will need to have those segments in the account structure and not in the advanced rules.

The next post for this blog series will discuss the advanced rules functionality.