# 3 Types of Rules TM1 Developers Should Know

We’ve gone through our training notes and aside from basic equation rules, we’ve listed three types of common rules which every TM1 Developer should be familiar with. If you haven’t ever had to write one of these rules before, you should try it. It will be good practice because we’ve all seen [‘Sales \$’] = N: [‘Units’] * [‘Price’] example far too many times!

We’ve boiled it down to 3 types of rules which every consultant should know:

• Allocation/Phase Rule – e.g. Allocate our budgeted sales across States based on the Actual Sales ratio.
• Rolling Value Rule – e.g. Opening (Measure) is equal to the Closing of the prior period. Often used in the Balance Sheet or Depreciation rules.
• Averaging Rule (C Level) – e.g. Averaging Percentages or Rates up all hierarchies within the cube.

As with TM1 and Platform Software in general, there are a million ways to do anything, so don’t worry if we don’t follow the methodology you are familiar with. That being said, these 3 rules are a great guide for any TM1 developer!

## Allocation/Phase Rule

This is a common requirement often seen in budgeting rules to allocate/phase an annual budget across months based on Calendar Days, Working Days or Last Year’s Actual Values for the given account.

Here is a sample rule which will phase an annual budget across months based on the number of working days in each month.

```[{'Jul','Aug','Sep','Oct','Nov','Dec','Jan','Feb','Mar','Apr','May','Jun'},'Budget','

There is a number of different ways to write this. For example, I could exclude the {} Months from my rule filter (scope) and filter using an ELISANC within an IF Statement to check that the month element of the current cell being calculated is a descendant of the ‘All Months’ Element but that would clutter the rule tracer when/if used later on the ‘Annual’ Element.

Don't you need a complex feeder with a rule like this?

No. We only have to calculate a month if there is a value in the ‘Annual’ month (which is a posting element for annualised data) within the same year. Which means our feeder can simply be:```
`[‘Annual’,’Budget’,’\$’] => [‘All Months’]; `

This could also be written in longhand:

`[‘Annual’,’Budget’,’\$’] => [‘Jan’], [‘Feb’], [‘Mar’], [‘Apr’] … [‘Dec’];`

## Rolling Value Rule

Calculating a Balance Sheet, Net Book Value or Depreciation? This rule logic is bound to come up. This methodology is going to be slightly different depending on how you have your Time Dimension(s) set up within your cube.

Firstly there are even more possible solutions here, but we are aiming for a sustainable example which means we will be avoiding DIMNM(DIMIX()-1) in favour of using attributes to help move around periods.

We’ll take a customer subscription calculation as our example and assume the cube for this rule has a separate Year and Month dimension.

Given a measures dimension which looks like this:

• Closing Subscriptions
• Opening Subscriptions
• New Subscribers
• Subscriber Churn (Displayed as a positive sign, aggregated with a -1 Weighting)

And a clever little attribute table on the Month Dimension:

Sample Attribute Table to assist Rolling Value Rules.

A rule can then be written which looks like this:

```[{'Jul','Aug','Sep','Oct','Nov','Dec','Jan','Feb','Mar','Apr','May','Jun'},'Forecast','Opening Subscriptions'] = N:
DB('Subscription'
,STR(NUMBR(!Year) - ATTRN('Month',!Month,'Prior Year Component'),4,0)
,STR(NUMBR(ATTRS('Month',!Month,'Month Number')) - ATTRN('Month',!Month,'Prior Month Component'),2,0)
,!Scenario,!Department,!Product,'Closing Subscriptions');```

This is what I would class as a bare-bones rule for Rolling a Value. This should go back as far as the Year dimension’s elements will go and has not potential to create a circular reference like DIMNM(DIMIX()-1) methodology.

If you want to post an opening amount into the first month and first year within your TM1 cube you can use an additional check to see if the generated Year exists using the DIMIX function, if it doesn’t a STET will make the cell editable.

```[{'Jul','Aug','Sep','Oct','Nov','Dec','Jan','Feb','Mar','Apr','May','Jun'},'Forecast','Opening Subscriptions'] = N:
IF( DIMIX('Year', STR(NUMBR(!Year) - ATTRN('Month',!Month,'Prior Year Component'),4,0)) = 0
,STET
,DB('Subscription'
,STR(NUMBR(!Year) - ATTRN('Month',!Month,'Prior Year Component'),4,0)
,STR(NUMBR(ATTRS('Month',!Month,'Month Number')) - ATTRN('Month',!Month,'Prior Month Component'),2,0)
,!Scenario,!Department,!Product,'Closing Subscriptions')
);```

Then, the feeders for this involve the same amount of coding, but the theory may be daunting for people still learning. This is because where the rule went back across time periods to get the value, the feeder has to go forwards across time periods to push the value into the rule calculation cell.

``````[{'Jul','Aug','Sep','Oct','Nov','Dec','Jan','Feb','Mar','Apr','May','Jun'},'Forecast','Closing Subscriptions'] =>
DB('Subscription'
,STR(NUMBR(!Year) + ATTRN('Month',STR((NUMBR(ATTRS('Month',!Month,'Month Number'))-13)*-1,2,0),'Prior Year Component'),4,0)
,STR(NUMBR(ATTRS('Month',!Month,'Month Number')) + ATTRN('Month',STR((NUMBR(ATTRS('Month',!Month,'Month Number'))-13)*-1,2,0),'Prior Month Component'),2,0)
,!Scenario,!Department,!Product,'Opening Subscriptions');``````

This could be written simpler if we didn’t piggyback the same “Prior Year” Attributes and instead added new “Next Year” Attributes. The above example feeder has a minimalistic approach to attributes but is paying for it in rule complexity.

I am also using a filter of each month because I have other N level elements in my month dimension which I don’t want this rule applied to.

## Averaging Rule (C Level)

C  Level (Consolidation Level) rules which do averaging are very similar to normal rules but the reason we have them listed is that people don’t realize until they have to write one that a (non-zero value) countermeasure is needed and you need to use a separate measure to perform the calculation in most cases.

Legacy Method – For averaging a value based on a counter.

```['Average Price'] = C:
['Price'] \ ['Product Count'];
['Product Count'] = N:
IF( ['Price'] > 0 , 1 , 0 );```

Feeder:

```['Price'] =>
['Product Count'],
['Average Price'];```

I’m using price and not units for my product counter as I want to average all prices regardless of if the product is sold in a specific period. If I wanted an average price pro-rata units sold I would back solve my revenue equation like so.

`['Average Price'] = C: ['Subscription Revenue'] \ ['Closing Subscriptions'];`

Feeder:

`['Closing Subscriptions'] => ['Average Price'];`

New Function Method – Averaging based on the data within a measure.

`['Average Price'] = ConsolidatedAvg(2,'Subscription',!Year,!month,!Scenario,!Department,!Product,'Price');`

Feeder:

`[‘Price’] => ['Average Price'];`

The first argument of the ConsolidatedAvg function can be set as either:

• 0 – consider all cells while averaging.
• 2 – Ignore blank cells while averaging

## Were Not Perfect!

Please comment on any mistakes you see in the above workings on our 3 rules or on any areas which need further clarification.