1.01-01 Never use SELECT with Time

Rule 1.01-01: Never use SELECT with TIME This goes against “Sustainable” of PLANS if you wish to use SELECT with TIME.

Use Case: Let’s say we have a source module where we have a time dimension and we want to bring in the annual Revenue for one year into our target module (Ignoring rest of the dimensions)

Here is how it was done in Pre Planual Era

Source Module – Please see below for Screenshot

Target Module: Source Module.Revenue [SELECT: TIME.’FY20’]. We are successfully able to pull the values into our target module.

 

What is wrong with this method? This is NOT the recommended way of doing things because we have not developed it keeping future in mind. It derails your Sustainability if you hardcode it to one particular year. Imagine what happens when you have hardcoded TIME with SELECT at a number of places.

1. There is no way to track where all it has been used in the model unlike other Lists and Line items where you can see the referencing. You may have to take the export of model blueprint to do the analysis.

2. Yearly roll over process will be high maintenance because every year this has to be changed in the Dev model and pushed to Prod environment and it calls for code review, testing etc.

Here is how it should be done in Planual Way:

Source Module: Please see below for Screenshot

LOOKUP Module: Create a dimensionless module with one line item (at least) which will hold the year for which we are trying to pull the values e.g., FY20 in our case. (Format of this line item has to be Time Period Annuals)

Target Module: Source Module.Revenue [LOOKUP: LOOKUP Module. Time].

Advantages:

There is no need to change the code in yearly rollover activity.

Lookup module can be published on the dashboard for Admin users giving them flexibility to change the year selection.

It doesn’t break S of PLANS