Innovative Way to Structure Essbase/Planning Account Dimension

---

Hey Everyone,
I wanted to share with you today a pretty innovative, and different  way to structure an account dimension in Essbase or Planning.  This method is not new and has been passed down from generation to generation from ancient times when planning could be installed from 3.5" floppy disks, slowly evolving into what I am going to describe below.  This will not be ideal to use in all situations, but when it fits, it fits very well.

I am going to cut to the chase and just get right into it.  Below you will find a sample structure of this method for use in a planning application and some notes below about why I personally like and dislike about this structure.

• Account
• Transferred_Accounts (~)
• Loaded_Sales (Stored) (~)
• Loaded_COGS (Stored) (~)
• Input_Accounts (~)
• Sales_Adjustment (Stored) (~)
• COGS_Adjustment (Stored) (~)
• Calculated_Accounts (~)
• Calculated_Sales (Stored) (~)
• Calculated_COGS (Stored) (~)
• Reporting_Accounts (~)
• Total_Earnings (Dynamic Calc) (+)
• Sales (Dynamic Calc) (+)
• Loaded_Sales (Shared) (+)
• Total_Adjusted_Sales (Dynamic Calc) (+)
• Calculated_Sales (Shared) (+)
• Sales_Adjustment (Shared) (+)
• COGS (Dynamic Calc) (-)
• Loaded_COGS (Shared) (+)
• Total_Adjusted_COGS (Dynamic Calc) (+)
• Calculated_COGS (Shared) (+)
• COGS_Adjustment (Shared) (+)

So obviously this example above is pretty simple, but what I am trying to show here is how you can bucketize most of the accounts in a flat list and use them as shared members in the Reporting Hierarchy.  With a flat list of Transferred, Input, and Calculated Accounts it makes processing and locating accounts much easier.

Something to note is that all members under the Reporting_Accounts parent, are either dynamic calc or shared.

I know this is going to get asked, so I will address it right now...  "But Scott, you are telling me that in the reporting account structure my Sales = Loaded_Sales + Calculated_Sales + Sales_Adjustment?  That is not right..."  The answer is like Schrödinger's cat, yes and no.  Yes, the outline physically aggregates these members.  No, because loaded data should be in the Actuals scenario and calculated/adjustment data should be in the Plan scenario.

Below is my list of Pro's and Con's for this method.

Pro's

• Simplifies calc scripts.  For example, if you had a calc script that cleared all of the input accounts for a specific period, you could use @CHILDREN("Input_Accounts") within the fix statement.  This will avoid having to maintain the calc script if a new input account is added to the structure.
• This works for data exports and transfers as well.  
• This method makes locating accounts much easier as you can sort the flat lists of accounts by name in Essbase.
• This method also simplifies security.  For example, you can apply security easily to all Input accounts in one place without having to pick through a large reporting hierarchy.  --Thanks MG!

Con's

• This adds complexity for end-users since they need to be trained to only pull from the Reporting hierarchy at the bottom of the dimension.
• Since this in a non-conventional way to structure your accounts, some administrators might think you are crazy.  There is a very small gap between crazy and innovative.

I would love to hear some feedback on this approach to see what some of you other experts think of this.  Also as always, let me know if you find any errors in what I am posting.  Thanks for reading!