Rule 1.01-01: Article 1, Chapter 1 and Rule 1 - 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. One there is no effective 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.Second 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
*************************************************************************************************************************************
There is another way we can achieve the above objective by using SELECT with Generic Time Periods especially All Periods by writing the code as follows. (I won’t recommend taking this approach)
We have to be very careful about the number of years that are in the source module timescale. For example if there is a past year and a current year’s Actuals data in the source module and we only want to bring current year's FY actual data then it calls for a Time Range which in turn will add to the maintenance. Also having “All Periods” in the timescale will take extra amount of space. Hence I wouldn’t go ahead with this approach when I have a better one available
What would you do in such cases? Suggestions are welcome
