Hyperion Financial Management: Zero View and Default View Settings
One of the most common areas of confusion in Hyperion Financial Management (HFM) has been the Scenario application setting for the Default View and Zero View. Peering back into the history of Hyperion Solutions, you will find this setting has existed in all the Consolidation products, such as Hyperion Enterprise’s “missing values” setting under Categories. They are not new features and are a fundamental to HFM.
ZeroViewForAdj and ZeroViewForNonadj
There are two ZeroView settings in HFM. The ZeroViewForNonadj is a setting which applies to the <Entity Currency> Value dimension. The second is the ZeroViewForAdj which applies a setting to the <Entity Curr Adjs> Value dimension member.
The derived data that results from the ZeroView settings commonly appears in HFM as a slightly grey numeric value, as opposed to a black display found with standard data.
Before we explain what it does, let’s talk about why we need it.
Part of Hyperion Financial Management’s financial intelligence is its Account Types. These types help to manage data flowing through the chart of accounts and support variance reporting.
The Revenue, Expense and Flow Account types are referred to as “flow” accounts and tend to support Profit and Loss reporting. As such, they are supported by the View dimension. The View dimension allows data to be viewed, keyed or loaded as YTD or Periodic amounts. Data entered as periodic sales of $1000 to all months would allow users to view December as Periodic $1000 or YTD $12,000.
The ZeroView setting informs the HFM Scenario how to handle data for a flow account when no data is loaded to a Period. No data is not a zero; it is a blank, non-existent value.
If data was loaded from your source system for Jan as $1000, how should HFM calculate Feb? There are two options using the ZeroView settings which are YTD or Periodic. The first option is the YTD setting for the ZeroViewForNonadjs attribute.
Choosing the ZeroView setting as YTD, HFM will fill the period following with a derived value as zero YTD.
Recall that Flow accounts can be viewed as Periodic or YTD, what does Feb look like as Periodic? If there is $1000 YTD in Jan and zero YTD in Feb, there must have been a change in periodic activity. Therefore, the Feb Periodic value would be $-1000 to arrive at YTD zero.
The second option is to set the ZeroView settings as Periodic. This setting addresses the same properties of flow type accounts. In this instance, the following period will have a zero applied as a Periodic zero, which is the activity. This setting is common on the Budget and Forecast Scenarios. The data result is the entry flows through all the periods because the YTD value is derived from the Periodic activity.
How does one determine which setting is correct for their application? Typically, we analyze how the data load file is constructed. For example, for flow accounts that may be adjusted to zero, are they included in the file? Does a periodic version of the file supply zero items as the year-to-date negative offset? The most common setting is to set the ZeroView as YTD for Actual data loads.
A good example why we would set the ZeroView to YTD in Actual would be if data was re-classed month-to-month or a new account is used. In the example below, a different account is used in Feb compared to the data supplied in Jan. The ZeroView setting as YTD will automatically assume the Feb amount is to be YTD zero.
If the Scenario was set to Periodic for the ZeroView, the application would have incorrect results for Feb as 2000. The data would flow through all the Periods, and in this case, the Sales account should be zero for Feb. The original account would require a -1000 Periodic or "0" YTD entries to clear the value in Feb on account Sales.
The ZeroViewForAdjs setting applies to how HFM Journal entries will function for missing data and how they affect future periods.
For Journal adjustments we see the same impact on the data within the <Entity Curr Adjs> Value member. The YTD setting will essentially reverse the Journal in the following period by applying the YTD offset to the Journal.
In cases were a prior period is being adjusted, the YTD setting will keep the YTD values of future Period, such as Feb, constant. As an example, if the original value were 1000 in Jan and 1000 in Feb, the Feb YTD amount would be 2000. A journal posted to Jan would impact the Jan results, but the Feb YTD amount of 2000 would not change. In the example above, what is adjusted is the Periodic amount from 1000 to 500. Therefore, to see the impact on all periods, the Journal would need to be created and posted in all periods going forward.
Journal adjustments with the ZeroView setting for Journals as Periodic will allow the impact of the Journal to affect the YTD results in the future periods. Because of this, to reverse the affect in a future period a reversing Journal entry is required.
Therefore, when viewing data within HFM as a YTD or Periodic view, the grey offset values are the result of your Scenario settings for ZeroViewForNonadjs or ZeroViewForAdjs. These amounts impact your YTD and Periodic results in Local and Translated amounts.
The Default view determines what View will be applied to the “<Scenario View>”. When opening a Grid, form or report, this is the default member that will display.
Because of this, it is important when writing reports or comparing data, a specific view be chosen. The “<Scenario View>” results will vary by the design of each Scenario.
The default view also is a concern for Rules in HFM. This setting sets the basis of calculations.
As an example, if there was a Rule that simply called for “estimated bonus” to be a percent of “sales” after we attained our goal of $1000.00, the calculation would vary by Default View on Scenarios.
In the example, the YTD Scenario will calculate a result because it is calculating Rules off the YTD value of $1500. The Periodic Scenario does not calculate the Rule because it is driven off the Periodic value of $500.
Careful attention to Rules development and the utilization of the Dynamic Sub Routine in rules can help to minimize issues caused by differences in the Default View settings.