Planual Rules regarding Native Time
1.01-01 Never use SELECT with Time
This goes against the Sustainable element of PLANS, and the hard coding can cause issues when updating the timescales of the model. Modules with Time formatted items to be used as sums and lookups are the better option.
exception
| 1.01-01a Generic Time periods | It's OK to use SELECT with Generic Time periods such as Actual Period, Current Period, YTD, YTG, ALL Periods. |
| 1.01-01a Generic Time periods | It's OK to use SELECT with Generic Time periods such as Actual Period, Current Period, YTD, YTG, ALL Periods. |
relatedToRule
1.01-02 Use the Model Calendar by default
As the Model Calendar is dynamic, there are a lot of advantages in using it for most modules. Choose suitable time settings (past and future years) that cover most of the requirements and use the model calendar to set these for the most part.
For the exceptions outside the “norm”, use time ranges for efficiency of calculations and for keeping the model size under control. But remember, Time Ranges may need to be updated manually on a year-end rollover.
bestPracticesArticles
1.01-03 Use Current Period
Utilizing the Current Period within the Time Settings allows the use of CURRENTPERIODSTART(), CURRENTPERIODEND() and can be used to create lookup modules to hold the current period automatically.
1.01-04 Consider All Periods
Consider enabling the "All Periods" setting to add a Top Level to your time dimension. This provides significant flexibility, especially when referencing the same calculation repeatedly across multiple modules. However, keep in mind that because it acts as a Top Level, it comes with the usual drawbacks of Top Levels, such as increased cell count and memory usage.
Engine Applicability: Classic Hyperblock and Polaris
1.01-05 Keep timescale subtotals turned off by default
| Keep the "include" settings for timescale subtotals (such as Quarter totals, and Half-Year totals) turned off by default. Because these subtotals create aggregation points in all modules utilizing the model calendar, you should only enable them if absolutely necessary for your module's logic. Remember that while Time Ranges inherit Model Calendar settings by default, you can adjust their "include" settings individually. Engine Applicability: Classic Hyperblock and Polaris |
relatedToRule
1.01-06 Keep Time Range names short and descriptive
| Time Ranges should be named using a short, descriptive format such as FYxx-FYyy. This ensures the scope of the Time Range is easily visible within the module Blueprint, improving auditability without needing to reference the Time Range settings. This approach will require minor renaming during rollovers. For ranges that increment often (and are clearly documented) using a generic name such as "Actual Years" reduces maintenance. Engine Applicability: Classic Hyperblock and Polaris |
bestPracticesArticles
1.01-07 Align Time Ranges to data dimensionality
| Evaluate the time horizon required before assigning a time scale to a module. To minimize unnecessary calculations and optimize model performance, apply a specific Time Range to any module that doesn't require the full span of the default model calendar. Engine Applicability: Classic Hyperblock and Polaris |
bestPracticesArticles
1.01-08 Use daily timescales on large time horizons with caution
| Review the need for daily granularity for long timescales, specifically if the daily timescale spans five years or more. Use time ranges to restrict the daily calendars if possible and use PREVIOUS rather than CUMULATE to optimize calculation efficiency. For Polaris models, you must also guard the formula to ensure the engine only calculates required cells. Engine Applicability: Classic Hyperblock and Polaris |
