Modify the IT Chart of Accounts hierarchy

You can modify the IT Chart of Accounts in the Chart of Accounts stage of the workbench.

Before you begin

Role required: cost_transparency_admin or cost_transparency_analyst

About this task

The IT chart of accounts hierarchy defines how accounts are related to each other. Expenses assigned to lower-level accounts can roll up to higher-level accounts by using rollup rules that you configure.

Procedure

  1. On the Chart of Accounts stage, click Edit next to Hierarchy.
  2. Drag one of the segments to a different level or drag a segment from the Segment Definition section to a level in the hierarchy.
  3. If you need to remove a segment, drag it to the trash can.
  4. When you are finished making changes, click Save Changes.
    Figure 1. Adding a segment

Result

The application creates:

  • An allocation rule for each relationship in the hierarchy. Any rules that existed for the relationship are deleted.
  • A filter condition for each rule. The filter condition runs on the Cost Allocation table, meaning that it determines which allocated expenses, not unallocated expenses in the general ledger, the rule looks at for matches.
  • A method for each rule. The method specifies that 100% of the allocation should roll up to the parent segment.
  • A read-only metric for the method. The metric is in the form of a script that tells the application how to process the rollup.

These rules and their corresponding filter conditions, methods, and metrics are not necessarily used in actual rollup calculations from specific accounts in a segment to accounts in a parent segment. In the allocation setup stage, you will establish rollup relationships between specific accounts in different segments. It is at this time that you can specify exactly how much of any given bucket of expenses is allocated to a child segment and how much is rolled up to any connected parent segments.

When you make changes to the hierarchy, the rules that were used by the previous hierarchy are not deleted or modified. The only exception are the rules that already created expense lines during allocation. These rules are made inactive if no longer used by the new hierarchy.

Example

For example, if you start with the default hierarchy and add the Portfolio segment to level 3 and move the Project segment to level 4, the application creates or modifies the rollup roles for each segment relationship. The application also creates a method for each rule, and a scripted metric for each method handle rollups.

Figure 2. Hierarchy modification example

The names of the rules start with Default roll up from and specify the two dimension tables in the data mart that are part of the hierarchy for the new relationship.

The methods belong to the Rollup allocation group to signify they are created by the application and used for the segment hierarchy.

The names of the scripted metrics start with Metric to roll up from and also specify the two dimension tables in the data mart. For example: Metric to rollup from dm_table_pm_project to dm_table_pm_portfolio.An example of a scripted metric that rolls up from the

Project segment to the Portfolio segment is as follows:
createMethods();
 
function createMethods(){
          var methodUtils =new FinancialMethodUtils();
          var dmtable_rollup_from ='dm_table_pm_project';
          var dmtable_rollup_to ='dm_table_pm_portfolio';
 
	    var gr =new GlideRecord(dmtable_rollup_from);
	    gr.get(line.itcoa_segment_five);
           var dimensionId = gr.getValue('sys_id')
 
	    switch(dimensionId){
                default:
                     return default_allocation_logic(methodUtils, dimensionId, dmtable_rollup_to);
           }
}
 
function default_allocation_logic(methodUtils, dimensionSysId, dmtable_rollup_to){
          // Rollup type:use-none:
          return[];}