Forum Stats

  • 3,872,223 Users
  • 2,266,407 Discussions
  • 7,911,107 Comments

Discussions

PBCS dimension matching

3540143
3540143 Member Posts: 70
edited Feb 9, 2018 2:54AM in Planning and Budgeting

Hello,

i need your help on this case.

A Department dimension was added when the PBCS application was created.. now i am adding an Employee dimension but need to match it with the Department dimension.

i mean, like when added Employee 1 under Employee dimension, the system will know which dept the employee belongs in the Department dimension.

is that possible??

or would be better to just create Employee dimesion with departmental heirarchy?

if that is the case, the Department dimension will not be tagged in the cube where the Employee dimension is.

any insights is greatly appreciated!!!!

Thanks much!

Tagged:

Answers

  • Dayalan Punniyamoorthy
    Dayalan Punniyamoorthy Member Posts: 1,516 Gold Trophy
    edited Feb 8, 2018 11:47PM

    If the requirement is purely for Reporting purpose why not using the Attributes 

    Regards,

    Dayalan P.

  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited Feb 9, 2018 2:36AM

    Hi Dayalan, with many employees to 1 department, that would be 'nasty' to manage with attributes!!

  • Robert Angel
    Robert Angel Member Posts: 4,535 Bronze Crown
    edited Feb 9, 2018 2:43AM

    If you are guaranteed that an employee is in 1 department and 1 department only, and if a person moves department then you are either happy to create a new employee to keep their history where it was (or to move their history to their new department) and there is no need for half their costs to HR half their costs to IT, then the child approach might work for you, but when you had the children you will have a large exercise to apportion the costs down the hierarchy correctly as your original base level members will no longer be base level members.

    However, if you have regular employee movements, or a number of employees who need inter-departmental charging then you need a new dimension.

    Both are fairly hefty exercises as with the first approach you will have a big exercise to apportion the costs down the hierarchy, and the second is essentially a 'start over', as any change in dimensionality in Essbase will lose the entire database content, you're only recourse there being to first export your data, so you can then do an out of system exercise to refer to it (or in your other instance) and then repopulate the database with the expanded dimensionality.

    And of course with both options all of your artifacts (forms, business rules etc) will need rewriting for the expansion.

    Neither course is trivial and both need careful consideration, planning and testing.

  • Dayalan Punniyamoorthy
    Dayalan Punniyamoorthy Member Posts: 1,516 Gold Trophy
    edited Feb 9, 2018 2:54AM

    I agree with you, but not knowing the requirement, was thinking of other way round like Department as attribute attached to each employee initially. Again not a great solution but suggested if only for a reporting purpose.

This discussion has been closed.