How to Make Your Period Dimension Represent Two Different Fiscal Calendars


March 15th, 2016

It happens quite frequently that companies change their fiscal calendar. From a 2013 article on, there was a study of over 1,700 public firms during the 15-year period from 1993-2008 that found over 45% of those firms had shifted their fiscal year-ends. The typical reason for the fiscal calendar change is to better align with the business cycle. How do you create the consolidation solution in Hyperion EPM that is most adaptable to a fiscal calendar change?

I recommend building your Period dimension in Hyperion metadata to use generic labeling. Here’s what you see so often with the Period dimension – a typical Jan-Dec fiscal calendar labeled with the 3-letter months:

Here’s one version of the Period dimension using generic labeling:

Now, when you ask users and consumers of reporting about the differences between the two calendar examples shown above, you’ll get a case of a small change that seems like a big change. For traditionalists, it may seem like a big change to no longer see “Jun” and now see “P6”. But notice that the long descriptions have stayed the same so you’ll continue to see “June”. So for your traditionalist users and consumers of reporting, tell them they can still have “June” or “August” or “December” because Hyperion EPM reporting can support displaying either the short labels and the long descriptions (or both).

So, what happens when you have a fiscal year reporting change? Let’s say the fiscal calendar goes from a December year-end to a November year-end. In fact if you have the typical 3-letter month Period dimension, you must rebuild the Hyperion consolidation solution. However with the Period dimension designed to use generic labeling, you do not necessarily have to rebuild the Hyperion consolidation solution. If you are using Hyperion EPMA to manage metadata, you could continue to use the existing Hyperion consolidation solution and simply update the long descriptions.

Next, what you could do is add a new member to the Scenario dimension to represent the post-fiscal year end change, for example let’s add a new Scenario member named “ActualNFY – Actual New Fiscal Year”. And while we’re updating the Scenario dimension in EPMA, you can rename the current Scenario member from let’s say “Actual” to “HistActual – Historical Actual”. What does this give you?

  • #1 – You can store both your old historical data in the old fiscal calendar year of Jan-Dec without having to touch it. The scenario member name is simply renamed. You simply let all users of the HFM application know that when the scenario member is “HistActual” the Period dimension P1-P12 represents the old fiscal calendar.
  • #2 – You can start using a new Scenario member to restate historical data into the new fiscal year Dec – Nov and populate however many prior years of data is necessary for trend & comparison reporting requirements.
  • #3 – You can see both the “old view” of your reported data vs. the “new view” of your data in one application, which should make designing SmartView and Financial Studio reports more straightforward.

One more thing: as a nice bonus, if you’re building the consolidation solution to use generic Period dimension labeling, it makes more sense and looks coherent when you add a Period 13 member.




About TopDown Team

The TopDown Team includes members of TopDown Consulting who want to let the community know about webcasts, conferences, and other events. The team also conducts interviews on various EPM industry topics.

Leave a Reply

Your email address will not be published. Required fields are marked *