At times, the “value” of the parent element needs to be referred to, to determine how a calculation applies to a specific element.

A simple everyday example would be of Balance Sheet Vs. Income Statement across the time dimension. The QTD for Balance Sheet Accounts is the
balance of the last completed month in the quarter and the summation of all completed months for Income Statement.

TM1 has a pretty good function ELPAR that would be of help in such cases. However, the following points attempt to elucidate the practical difficulties in using it.

• A single ELPAR function can only check for the parent 1 level up. So, if the parent is sitting at 5 levels above, we would have 5 nested ELPAR functions.
• In a ragged hierarchy, ELPAR will not always be effective. The rules/ TI process will need to be written to accommodate the nuances of the hierarchy.
• Also, the special handling would need to be repeated for every instance of usage.

ELISANC might seem like an answer. However, the way TM1 would behave is, it would look at every element above the level of current element level. This would make it less effective in large hierarchies.

Meaningful Alternative – ATTRS (a string attribute):

Store all parent values for an element as attribute and use it for all comparisons. This would be the fastest look up.

• The Attribute is set up once when the dimension is created/ modified.
• The rules/ TI look cleaner in many cases
• The processing is faster since it is a straight look up
• Attributes can be used in BI reporting E.G say the report is for all Midwestern states, the attribute value of “Midwestern States” can be used in reporting

Conclusion, while creating hierarchies, add the multiple level parents as different attributes.

Dimensions are the building blocks of OLAP tools like TM1. This underscores the need to have correct dimensions for the specific purpose intended.

Dimensions can be classified in the following categories.

Based on Functionality:

Master / Reporting Dimensions

• The master dimensions are used to create other dimensions, which are mathematical subsets of the master dimension

E.G. a department hierarchy with all departments (active and inactive) is a master dimension.

A dimension with active departments only can be derived from the master dimension and used for budget.

• Master dimensions can help reporting since master dimensions can continue to have inactive elements.
• Master dimensions can store time based snapshots

E.G. Say the hierarchy appearance has changed over years, the master dimension can store multiple hierarchies – one for each year.

• Master dimensions can also help in security management of the entire environment. Security can be set in a cube with the master dimension and propagated to other dimensions.
• The cubes with master dimensions can have minimal number of rules. This would make it easy to archive data.
• Master dimensions are a good idea, even if, reporting is not a part of the environment.

Budget Dimensions

• Budget dimensions are dimensions that store relatively much lesser number of elements, help in creating budgeting cubes and apply complex logic that can change year over year.
• The number of elements in a cube is relatively less with only active elements required.

Hybrid Dimensions

• Certain dimensions can be easily used across the Reporting and Budget environments
• Hybrid dimensions also signify cross usage of dimensions across their type (detailed below) i.e. a Measures dimension combined with time.

Based on Type:

1. Departments or a variation (Products. Divisions etc.)
2. Accounts (Chart of Accounts or a subset)
3. Versions/ Scenario
4. Time
5. Measures
6. Supporting Dimensions

The types of dimensions used and the number of dimensions for each type depend on needs of an environment.

While collecting requirements, it is necessary to determine how many cubes and dimensions will be required.

However, to determine the number of dimensions, it is necessary to evaluate the behavior of data across the first four categories of dimensions – Departments, Accounts, Versions and Time.

All cubes storing budget or reporting data must have a measures dimension.

A Global Assumption Cube couldhave Time (Year) dimension to support storing the assumptions across multiple years.

More about dimensions in next issue…

In TM environments that have models to plan employee-based salaries, dummy names are used as placeholders. As positions are filled, the intention is to replace the place holders with the actual employee code or names. This is only an isolated example. Similar needs would exist in multiple ways within an implementation.

To support this, TM1 has a newer function SwapAliaswithPrincipalName. The implementation of the function in an environment must be done properly to avoid data loss and confusion.

Three to Four TI processes are required to achieve the change. Steps:

• Determine an alias to perform this function. This alias needs to be unique and not used elsewhere.
• Create process 1 to save data and delete the alias. (Create the alias manually for first run). This provides a clean slate.
• Create process 2 to add the alias back and update the alias for the old element value to the new value.
• Create process 3 to “Swap”. Command = SwapAliasWithPrincipalName(DimName,AiasName,Flag); I have usually used the flag value of 0.
• Create process 4 to update other attribute values. This is optional, but will be used more often than not

The values can be supplied as parameters and the update chain can be executed using a wrapper process.

End result, the name of the dummy employee/ place holder is now replaced with the actual employee’s name.

Other processes, especially, if they refer to consolidated elements, may produce an error – “Element not found”. Server restart should fix this.

For end-user control, create an active form and give users access to execute processes.