TM1 Tutorials.com

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

I’ve boiled it down to 3 types of rules which every consultant should at least know how to write.

• 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 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 is a million ways to do anything, so don’t be upset if we don’t follow your exact methodology.

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','$'] = N:
IF( ['Annual'] <> 0 ,
IF( DB('General Ledger',!Year,'Annual',!Scenario,!Department,!Account,'Phasing') @= 'Even Phasing' ,
['Annual'] \
DB('Assumption',!Year,'All Months','Actual','Unspecified Department','Working Days') *
DB('Assumption',!Year,!Month,'Actual','Unspecified Department','Working Days')
, CONTINUE )
, CONTINUE ) ;

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.

With a rule like this you would need a complex feeder right?

Wrong. We will only have to calculate a month if there is a value in the ‘Annual’ month (which is a posting element for annualized data) within the same year. Which means our feeder can simply be:

[‘Annual’,’Budget’,’$’] => [‘All Months’]; 

This could also be written in long hand:

[‘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 favor of using attributes to help move around periods.

We’ll take a customer subscription calculation as our example here 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:

 

 

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')
);

And then the feeders for this involve the same amount of coding but the theory can 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.

Also I’m using a filter of each month because I have other N level elements in my month dimension which I do not want this rule applied to.

 

Averaging Rule (C Level)

This is something which should be very easy to do, but TM1 couldn’t easily handle it before version 9.5.2. TM1 9.5.2 now supports an averaging function among other new rule and TI functions you can check out here. I’ll show examples of the old methodology and the new also.

C  Level (Consolidation Level) rules which do averaging are very similar to normal rules but the reason we have them listed is because people don’t realize until they have to write one that a (non-zero value) counter measure 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 the 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

 

Please feel free to comment any mistakes you see in the above workings or on any areas which need further clarification.