Yes that would work, but maybe you could do it in twoMay 4 2012 at 6:34 AM
No score for this post
|Cameron Lackpour |
from IP address 18.104.22.168
Response to Re: Built in to Planning
I've never seen an "Employee" (there have been and still are Employee apps even with WFP around) database split across two Plan Types. Are you sure you want to do that?
What's a lot more common is something like:
P&L (still has its own data)
|_Some other category of Expense
Where the P&L PT has its own expenses, Employee has a bunch of them but they come across as one or two salary-related expenses, and the third PT (if used) has yet another category of expenses.
The thing that splits the PTs apart is dimensionality that only makes sense to a given PT. Employee by name or position or whatever only makes sense when considering Employee expenses, so it lives as a custom dimension in its own PT. Capital Projects follow the same rule.
Common dimensions like Entity (you're forced to use it in all, although what goes into what PT is up to you) and maybe a custom dimension like Business Unit are unique to a PT.
Many customers also throw an ASO reporting cube on top of the Planning application and feed it in various ways. These applications are NOT part of the Planning application, require separate licensing (full Essbase or whatever it's called nowadays), separate security, etc.
- Re: Yes that would work, but maybe you could do it in two - NoMadBanker on May 4, 7:50 AM
- Database size? But how do you report it? - Cameron Lackpour on May 4, 8:02 AM