如果您有一个多年模型，该模型的数据范围各不相同，例如（例如，历史涵盖两年，当年的预测和三个计划年），那么时间范围应该能够以术语获得显着的收益模型大小和性能。
但是，在您赶紧赶上所有模型的时间范围之前，让我分享一些注意事项，以确保您最大程度地提高功能的价值并避免任何不必要的陷阱。
- 命名会议时间范围
- Time Ranges are Static
- Time Ranges Pitfalls
- Potential Data Loss
- 公式参考
- 何时使用模型日历
- SELECT Statements
- 应用程序生命周期管理（ALM）注意事项
命名会议时间范围
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!
我们建议使用以下约定：
- Fyy-Fyy。例如，2016财年或一年18财年
可用的时间范围从1981年到2079年，因此“ 19”或“ 20”前缀并非严格必要。保持名称的简短，具有几个优势：
- 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
可用于时间范围的聚合在每个时间范围内都可能有所不同，并且与主模型日历也有所不同。如果您利用此优势并具有与模型日历不同的聚合，则应在描述中添加后缀。例如：
- FY16-FY19 Q (to signify Quarter totals)
- 2016财年Qhy（季度和半年总计）
- FY16-FY19 HY (Half Year totals only)
- 等等
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).
同样，计划时间范围应重命名为20财年2月21日，并提高到20财年（从2019财年）。然后，将有18财年的历史记录，并可以用于计划数据输入。
Time Ranges Pitfalls
Potential Data Loss
时间范围可以为您的模型带来巨大的空间和计算节省，但要小心。在上面的示例中，将16-Fy17的开始期更改为17财年将导致使用16-Fy17作为时间范围的所有订单项删除2016财年的数据。
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:
- 将数据导出到文件
- 将订单项上的现有数据复制到使用模型日历的其他行项目
- Back up the entire model
公式参考
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.
何时使用模型日历
这是一个很好的问题，在该功能的开发过程中，我们在Anaplan进行了思考。时间范围会使模型日历多余吗？好吧，我认为答案是“否”，但是与Anaplan中的许多结构一样，答案可能是“取决于！”对我来说，使用模型日历的一个很大的优势在于，它是本年度的动态，而+/-在任一方都具有动态性。更改本年份，模型将自动更新以及您设置的任何过滤器和计算，以参考当前年度，历史期，未来期间等。
(You are using a central time settings module, aren’t you??)
时间范围没有这种活力，因此每个时间范围都需要对年度进行任何变化。因此，我们在第一次实施时间范围之前的建议是查看每个模块，并且：
- 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.
我们提倡构建模型从逻辑上讲,这是李kely 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.
应用程序生命周期管理（ALM）注意事项
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.
祝你好运！有关更多详细信息，请参阅Anapedia文档。请询问您是否还有其他问题，让我们和您的Anaplanners知道时间范围对您的模型的影响。
Please consult your internal administrators prior to applying any of the ideas or steps in this article.
嗨，马修
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.
这是时间尺度变化的正常行为，但要注意的是
Hope this helps
David
