Back to Basics – Regions in Rules

If there is one basic technical best practise which makes TM1 Solutions more straight-forward thus sustainable which is most often not utilised it is #Regions in cube rules. Regions work the same way as grouping rows within Microsoft Excel, except the grouping is done automatically around a set of key words. This is actually a feature in many scripting environments and is called code folding, it is added to a rule like so:

#Region *The title of this region goes here*
*Rules go here*

You can even add regions within regions. Like so:

#Region 1. Sales Rules
	#Region 1.1 Revenue
		['Revenue'] = N: ['Units'] * ['Price'];
	#Region 1.2 COGS
		['COGS'] = N: ['Units'] * ['Standard Cost'];

This example could also extend to showing the corresponding feeders with the same format: “#Region 1. Sales Feeders”.

Check out the gallery below to see just how much more readable this rule is:

If you would like assistance developing Turbo Integrator Processes or Cube Rules for your TM1 Solution, the friendly team of Consultants at InfoCube Consulting Australia can help. Enter your details in the contact form here.


Rolling Forecast in IBM Cognos TM1

Recently, a client has asked to implement a rolling forecast model to move towards a more dynamic way of forecasting so as the periods move forward so does your forecast so you are always forecasting 12 / 18 months out in to the future.

With a rolling forecast the number of periods remain the same so as each period is traded it drops out of the forecast and another period is added. This is best shown with a diagram:

In TM1, this can be easily achieved using a period slider rule. To enable this functionality  the user simply updates the current month string in a global assumptions cube to start the forecast, this in turn updates a rule attached to a period slider dimension which updates the attribute values for those months within the period dimension. The business rule attached to Cube B then pulls data from “Cube A” Actual’s based on the attribute values for those periods and populates values in Cube B for Current Forecast Periods. Note that Actual’s are against real periods in Cube A ( i.e. Dec 2011 instead of m-1, the rule translates real month Dec 2011 into an “m-x’ month and updates the period description using an alias mask being the real period name ). See Ouput below:

Turning on the Alias for the Period Description below for Cube B below:






How the slider rule works (translate sliding period i.e Dec 2011 into sliding period i.e m-1 ). See embedded pseudo code in rule below:

Output in Period_slider attribute cube:

Now that you have an idea of the workings, the only real challenge that remains is to encourage/influence management to think outside the box and adopt a different way of thinking when approaching the forecast, one that I imagine is a mere walk in the park.

Enjoy! See attached for full download of above including cubes and rules.


3 Types of Rules TM1 Developers should know

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.

Continue reading