Planual Explained - Day 1
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
Answers
-
If the requirement is to always reference the current year, then I would go one step further and say instead of having a separate module allowing the user to manually input the year, I would calculate the current year in a Time Filter module. This way when we move to the next year we don't have to make any manual changes.
If the requirement is to allow the user to select different years to analyze then maybe allow the user to input the year is warranted.
Other common use cases are to look up the value of previous years., for that, you would also create an entry in the Time Filer module to calculate the previous year.
@Misbah I would actually avoid using All Periods like you mentioned you have to be very careful when using it and ensure that the model will not have data for more than a year. especially if we have the safer alternative of calculating the current year.1 -
Exactly! Modellers build Time Module so that they can use LOOKUPs on that. That's why displayed an example with the help of LOOKUP Module.
All Periods is an option but as I said earlier you have to be very careful
1
