Hyperion Planning tips: entry 1

From time to time I stumble upon little tweaks that greatly affect deliverable functionality in planning. This is the first blurb in a series that will be updated over time. These apply to hyperion planning 9.3.1.1 p1. Most of these tips probably work with 9.2 as well but I can't confirm or deny.

1. -enabling YTD dynamic time series in planning
2. -creating alternate period rollups
3. -use of substitution variables
4. -top of dimension properties in planning
1. storage properties can be set
   

1. enabling YTD dynamic time series in planning:
In order to use ytd dynamic time series you must first rename the year dimension to something else. I tend to use Years. Year is a reserved word and using this as your dimension name will prevent you from being able to perform dynamic time series.

2.creating alternate period rollups:
If you'd like to create your own alternate period rollups you can now do this on the planning side and push them into essbase. You could make your own ytd rollups, qtd rollups or what ever you dream up. While adding them in the web interface it's a little painful as it's not too easy to reorder the members but it does work.

3.use of substitution variables:
We can now use substitution variables inside of member formulas. This applies to essbase as well as planning and probably came out with maybe system 9. This is a huge step forward and might effect every business rule you develop going forward. It could be used for the processing of the current budgeting period, forecast year, or anything you can dream up. I'm a little embarrased that I didn't stumble upon this (co worker tried it and told me it worked. I still didn't believe him) earlier. I need to spend more time reading the release notes.

4. top of dimension properties in planning:
storage properties can be set:
Now you can utilize some of those essbase skills in tuning a database. We can now set the storage property of the top dimension nodes. While we've probably all created our own work arounds to reduce blocks, this makes it a lot easier to "tighten up" our databases while working within the planning infrastructure.

as always feel free to correct me or better yet, send in some tips that you've stumbled upon..

you can contact me anonymously at hjohnson@john-assoc.com

hj

migrating skillset from essbase to hyperion planning:

This will be revised as I stumble upon other major topics but here's a start at some of the major components that must be understood by an essbase consultant for them to move into the hyperion planning world. (why an essbase guy should morph into hyperion planning is a topic for another day...)

For an essbase guy to morph into a hyperion planning consultant the following must be known and understood.

-yes, essbase is the back end for planning
-a planning app is comprised of an application and 1 or multiple plan types.
-a few database settings must be known when the application is created for the first time. Once created, these items cannot be changed. Among them are:
-starting year for model
-number of plan types. You can have up to 3 for planning. If you create only 1 when creating the application, you will not be able to create type2 and type 3 later. There are some additional modules that bring the total plantype up to 5 (capx, workforce planning)
-a planning application that contains more than 1 plan type will exist on the essbase side as an application with 1 or more databases. Each plan type translates into a database.
-the outline meta data is stored in a relational repository. When you want to modify the outline changes are made to the repository. Then they are pushed to essbase via a refresh operation.
-when a refresh operation is being performed, it affects all plan types at the same time. You cannot choose to update only 1 plan type when there are 3 existing.
-changes to the repository are made thru using either planning web interface (if not using architect), HAL (product is on life support and will sunset soon), DIM (informatica with planning adapter), or enterprise architect.
-do not play in the relational tables (unless you really know what you are doing)
-do not, do not, do not modify the outline directly on the essbase side unless you really know what you are doing (with system 9.3.1.1 other than some formulas, this is not that necessary)
-do not touch the system until you can confirm that backups are being performed properly. This means that the relational metadata tables and the outline must be backed up with the same date stamp.
-do not go home at night until the refresh has completed successfully.
-the worst thing that can happen is to have a planning model where the refresh will not run. The system will be up and work but your connection between the metadata and essbase is broken and you will never be able to update the outline again until the refresh completes successfully
-security in planning is not as flexible as that in essbase. You cannot have an account be writeable in budget and read only in forecast (assuming budget and forecast are both writeable). The filters are based on one dimension at a time.




If anything above doesn't sound correct please correct me....

hj