If you have a multi-year model where the date range for different parts of the model varies (for example, history covering two years, current year forecast, and three planning years), then time ranges should be able to deliver significant gains in terms of model size and performance.
But, before you rush headlong into implementing time ranges across all of your models, let me share a few considerations to ensure you maximize the value of the feature and avoid any unwanted pitfalls.
- Naming convention for time ranges
- Time ranges are static
- Time ranges pitfalls
- Potential data loss
- Formula references
- When to use the model calendar
- SELECT statements
- Application Lifecycle Management (ALM) considerations
Naming convention for time ranges
As with all Anaplan models, there is no set naming convention, however, we do advocate consistency and simplicity. As with lists and modules, short names are good. I like to describe the naming convention thus—as short as practical—meaning you need to understand what it means, but don’t write an essay!
We recommend using the following convention:
- FYyy-FYyy. For example, FY16-FY18, or FY18 for a single year
Time ranges available are from 1981 to 2079, so the “19” or the “20” prefixes are not strictly necessary. Keeping the name as short as this has a couple of advantages:
- It has a clear indication of the boundaries for the time range
- It is short enough to see the name of the time range in the module and line items blueprint
The aggregations available for time R=ranges can differ for each time range and also differ from the main model calendar. If you take advantage of this and have aggregations that differ from the model calendar, you should add a suffix to the description. For example:
- FY16-FY19 Q (to signify Quarter totals)
- FY16-FY19 QHY (Quarter and Half Year totals)
- FY16-FY19 HY (Half Year totals only)
- etc.
Time ranges are static
Time ranges can span from 1981 to 2079. As a result, they can exist entirely outside, within, or overlap the model calendar. This means that there may likely be some additional manual maintenance to perform when the year changes. Let’s review a simple example:
- Assume the model calendar is FY18 with two previous years and two future years; the model calendar spans FY16-FY20
- We have set up time ranges for historic data (FY16-FY17) and plan data (FY19-FY20)
- We also have modules that use the model calendar to pull all of the history, forecast, and plan data together, as seen below:
At year end when we “roll over the model,” we amend the model calendar simply by amending the current year. What we have now is as follows:
You see that the history and plan time ranges are now out of sync with the model calendar.
How you change the history time range will depend on how much historical data you need or want to keep. Assuming you don’t need more than two year’s history, the time range should be re-named FY17-FY18 and the start period advanced to FY17 (from FY16).
Similarly, the plan time range should be renamed FY20-FY21 and advanced to FY20 (from FY19). FY18 is then available for the history to be populated and FY21 is available for plan data entry.
Time ranges pitfalls
Potential data loss
Time ranges can bring massive space and calculation savings to your model(s), but be careful. In our example above, changing the Start Period of FY16-FY17 to FY17 would result in the data for FY16 being deleted for all line items using FY16-FY17 as a time range.
Before you implement a time range that is shorter or lies outside the current model calendar, and especially when implementing time ranges for the first time, ensure that the current data stored in the model is not needed. If in doubt, do some or all of the suggestions below:
- Export out the data to a file
- Copy the existing data on the line item(s) to other line items that are using the model calendar
- Back up the entire model
Formula references
The majority of the formula will update automatically when updating time ranges. However, if you have any hard-coded SELECT statements referencing years or months within the time range, you will have to amend or remove the formula before amending the time range. Hard-coded SELECT statements go against best practice for exactly this reason; they cause additional maintenance. We recommend replacing the SELECT with a LOOKUP formula from a Time Settings module.
There are other examples where the formula may need to be removed/amended before the time range can be adjusted. See the Anapedia documentation for more details.
When to use the model calendar
This is a good question and one that we at Anaplan pondered during the development of the feature; Do time ranges make the model calendar redundant? Well, I think the answer is “no,” but as with so many constructs in Anaplan, the answer probably is, “it depends!” For me, a big advantage of using the model calendar is that it is dynamic for the current year and the +/- years on either side. Change the current year and the model updates automatically along with any filters and calculations you have set up to reference current year periods, historical periods, future periods, etc.
(You are using a central time settings module, aren’t you??)
Time ranges don’t have that dynamism, so any changes to the year will need to be made for each time range. So, our advice before implementing time ranges for the first time is to review each module and:
- Assess the scope of the calculations
- Think about the reduction time ranges will give in terms of space and calculation savings, but compare that with annual maintenance. For example:
- If you have a two-year model, with one history year (FY17) and the current year (FY18), you could set up a Time Range spanning one year for FY17 and another one year Time Range for FY18 and use these for the respective data sets. However, this would mean each year both time ranges would need to be updated.
We advocate building models logically, so it is likely that you will have groups of modules where time ranges will fall naturally. The majority of the modules should reflect the model calendar. Once time ranges are implemented, it may be that you can reduce the scope of the model calendar. If you have a potential time range that reflects either the current or future model calendar, leave the timescale as the default for those modules and line items; why make extra work?
SELECT statements
As outlined above, we don’t advocate hard-coded time selects of the majority of time items because of the negative impact on maintenance (the exceptions being All Periods, YTD, YTG, and CurrentPeriod). When implementing time ranges for the first time, take the opportunity to review the line item formula with time selects. These formulae can be replaced with lookups using a Time Settings module.
Application Lifecycle Management (ALM) considerations
As with the majority of the Time settings, time ranges are treated as structural data. If you are using ALM, all of the changes must be made in the development model and synchronized to production. This gives increased importance to refer to the pitfalls noted above to ensure data is not inadvertently deleted.
Best of luck! Refer to the Anapedia documentation for more detail. Please ask if you have any further questions and let us and your fellow Anaplanners know of the impact time ranges have had on your model(s).
Please consult your internal administrators prior to applying any of the ideas or steps in this article.
Hi Matthew
The availability of the granularity depends on the settings here:
Turning on Quarter here will enable you to set Quarters as the Time Scale
Just a word of warning, if this is not the model calendar setting, check that you haven't got any Parent() functions that refer to a timescale nested within another formula. The value may change. For example, Name(parent(item(time))) for Jan-18 = "FY18" when quarter totals are off, whereas the same formula returns "Q1 FY18" if quarter totals are turned on.
This is normal behaviour for timescale changes, but something to watch out for
Hope this helps
David
