Recent Posts


Enhanced Planning Validations: Part 2 – by Tyler Feddersen (featured on Cameron Lackpour’s blog)
Posted on August 21, 2014
Author: Melanie Mathews, Performance Architects

Last month, Tyler Feddersen was featured in a blog post by Cameron Lackpour, a well-known veteran in the EPM community with specialties in Hyperion Essbase, Planning, ODI, Financial Reporting, and system automation.

Tyler is featured again in the closing segment of this two-part series on Planning validations – a small snippet is below.

“If you recall from Part 1, I created two validation members: AllocValidate and Validate. AllocValidate was created in the dense Accounts dimension while the Validate member was created within a sparse dimension, to give us block suppression capabilities. For this portion of the validation process, I created an additional Accounts member, LockFlag. This new member will be used in coordination with the previously created member, AllocValidate, to create a locking “flag” that all business rules can use to decide whether the rule should continue to process or not.

Additionally, I added a “NO_XXXX” for each dimension. The flag only needs to be stored at the Entity level, so each dimension outside of Accounts, Period, Scenario, Version, Year (although, I use No Year), and the dimension containing “Validate” will need the “NO_XXXX” member.”

To continue reading please visit Cameron’s Blog For Essbase Hackers.

We want to thank Cameron again for featuring some of our expertise.

Author: Melanie Mathews, Performance Architects


© Performance Architects, Inc. and Performance Architects Blog, 2006 - present. Unauthorized use and/or duplication of this material without express and written permission from this blog's author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Performance Architects, Inc. and Performance Architects Blog with appropriate and specific direction to the original content.

Leave a Reply

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