This Essbase discussion board is provided as a free service and dedicated to all the Essbase professionals out there!
 

 Return to Index  

Built in to Planning

May 3 2012 at 10:11 AM
No score for this post
Cameron Lackpour 
from IP address 98.111.159.77


Response to HyperionPlanning Plan Type Data Sharing

 

You define the source of the account (one PT) and make it available to others. It automatically gets XREF'd as a dynamic calc. Of course performance can fall right off a cliff if you have lots of these. I often will go through and make them all stored members and then force their valuation through a business rule.

Here's something I wrote long ago and really need to work into a full blog post:
<snippet>
Chop the Accounts
When I build a Planning application with more than one Plan Type, I like to create upper level Account parents that segregate by Plan Type. This makes security and dimension builds as straightforward as possible. Yes, this does require extra dynamic calcs in the target (really, it’s the master) Plan Type to pull the XREF’d data from the source Plan Type(s), but I think it’s a small performance penalty to pay for clarity. I reserve the right to bin the above approach if it doesn’t work for a particular application, dear client(s), so please don’t consider the above set in stone.

Mythical application example -- Account
To do this, name and order the Accounts like the below to split security by Plan Type:

Accounts
|--Wrkforce Accounts
|--Consol Accounts

NB -- Wrkforce, the source of employee expenses, is ordered before target Income Plan Type so that there are no forward dynamic calcs.
</snippet>

The issue with shared members across PTs is that they can get REALLY mixed and cause a lot of noise in the hierarchies -- remember, what you see in Planning/EPMA isn't what really translates to Essbase but of course that's where everything happens. I like to segregate the shared members as much as possible hierarchically and then move data around as needed. I also try to keep the scope of XREF'd data as small as possible.

Regards,

Cameron Lackpour

 
Scoring disabled. You must be logged in to score posts.Respond to this message   
Responses

  1. Re: Built in to Planning - NoMadBanker on May 3, 12:59 PM
    1. Yes that would work, but maybe you could do it in two - Cameron Lackpour on May 4, 6:34 AM
      1. Re: Yes that would work, but maybe you could do it in two - NoMadBanker on May 4, 7:50 AM
        1. Database size? But how do you report it? - Cameron Lackpour on May 4, 8:02 AM
     
 Copyright © 1999-2014 Network54. All rights reserved.   Terms of Use   Privacy Statement  

RSS feed for this forum - http://www.network54.com/Forum/58296?xml=rss. Please email hypess (at) gmail.com, if you have any questions/feedback/issues.