Issue with Never aggregation property within forms – Solved with some startling results

Issue with Never aggregation property within forms – Solved with some startling results

Somehow, the Never Aggregation property in Hyperion Planning does not seem to work for v11.1.2.3

As presumed, we are expecting that the aggregation for any member which has been tagged within Hyperion Planning would not aggregate across all dimensions including the immediate parent. Accordingly, we created a member and tagged the member with a smartlist which showcases the textual value against the ID of 1,2,3. When retrieved within a form with time period as columns and IDescendants of YearTotal, the values of summary time periods across until YearTotal was being populated on form save. Is this normal or is that a bug?

Case:

  • Create a smartlist named ‘SalePeriod’ with members “Yes”, “No” & “Not Sure”. Let the values and ID be generated dynamically.
  • Create an account member called “Sale Period” to track if a sale is scheduled during the time period. Select ‘Never’ as the aggregation property for the member.
  • Select the data type for account “Sale Period” as SmartList and select ‘SalePeriod’ from the list
  • Refresh the database
  • Create a form with accounts (“Sale Period” and few other relevant accounts) in rows and time period ( IDescendants(“YearTotal) ) in column.
  • Select ‘Calculate Data Form’ business rule logic and select ‘Save’ as the option.
  • Set Evaluation order to include accounts dimension only
  • Open the newly created form and select values for “Sale Period” for the month of Jan as “Yes”, Feb as “No” and Mar as “Not Sure”.
  • Click Save.
  • Q1 is populated with ‘6’ as the value since the TimeBalance property is set to ‘Flow’.

Analysis:

Since “Sale Period” is tagged as ‘Never’ within aggregation property, the value in database should not have been populated. However, there seems to be an override of this functionality due to ‘Calculate Data Form’ business rule logic OR due to the default Grid Spread functionality within the Planning forms.

Update (08-Nov): The problem is now solved and the main cause of issue was due to  Account Type property was not set to ‘Saved Assumption’. This is logical as well since the request from all quarters that had poured to the development team was use cases wherein the summary time period and parent level members for statistical data within Hyperion Essbase had to be recalculated / back calculated to ensure that they do not display the incorrect results.

However, we are startled to find out that it is not only the ‘Saved Assumption’ property which determines how the ‘Calculate Date Form’ business rule logic would be executed within forms. It is also a derivative of the TimeBalance property which gives the desired results. If the TimeBalance property is set to ‘Balance’, ‘First’, ‘Weighted Average – Actual Actual’ or ‘Weighted Average – Actual 365’, the resultant values in summary time period would be undesired values. In order for the ‘Never’ property to work in accordance with the desired results, one has to ensure that the TimeBalance is not set to any of the above mentioned property and only then would the ‘Calculate Data Form’ business rule logic would not populate the summary time periods. In all other scenarios, the aggregation property of ‘Never’ would still continue to populate the summary time periods ignoring the configuration.

Apparently, it seems that during the development of ‘Never’ feature within aggregation property, this aspect was not looked upon. In our opinion, the feature should produce the desired results, irrespective of the property value chosen in the TimeBalance property.

Comments are invited from readers on their opinion on the findings.

Leave a Reply

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

*

arrow_upward