Multiple Hierarchies - Nodes not assigned

[Former Member]

Hi,

If i take a static view of a hierarchy at a point and time and create a copy of it to make PARENTH2. What happens if extra members are added to the hierarchy for PARENTH1.

For example, PARENTH1 has the following

Member           PARENTH1

ACCOUNT 1    

ACCOUNT 2     ACCOUNT 1

ACCOUNT 3     ACCOUNT 1

Then I had a snapshot of PARENTH1 into PARENTH2

Member           PARENTH1     PARENTH2

ACCOUNT 1    

ACCOUNT 2     ACCOUNT 1     ACCOUNT 1

ACCOUNT 3     ACCOUNT 1     ACCOUNT 1

At a later date a new account appears in PARENTH1 but I dont want it showing in PARENTH2 or it could be under a NOTASSIGNED node. I am assuming though the following will happen? Where the new ACCOUNT 4 will end up being at the root?? Is there a way around this?

Member           PARENTH1     PARENTH2

ACCOUNT 1    

ACCOUNT 2     ACCOUNT 1     ACCOUNT 1

ACCOUNT 3     ACCOUNT 1     ACCOUNT 1

ACCOUNT 4     ACCOUNT 1

Cheers,

[former_member186338 · Accepted solution]

Hi Leo,

May be you can use Time Dependent Hierarchies?

In general the rule is simple:

If you use same parent in different hierarchies - then this parent is required to have same base members in both hierarchies!

Vadim

P.S. "At a later date a new account appears in PARENTH1 but I dont want it showing in PARENTH2 or it could be under a NOTASSIGNED node." - not possible!!!!

[Former Member · Accepted solution]

Hi,

Is this a definite rule or guide because just if we loaded a different hierarchy from the ECC source system this would be possible. i.e. a base member may be under a different parent and thats why it would be under a different hierarchy or i didnt understand the rule..

"If you use same parent in different hierarchies - then this parent is required to have same base members in both hierarchies!"

Is the following not possible i.e. ACCOUNT 4 would be under the node UNASSIGNED in PARENTH2.

Member           PARENTH1     PARENTH2

ACCOUNT 1   

ACCOUNT 2     ACCOUNT 1     ACCOUNT 1

ACCOUNT 3     ACCOUNT 1     ACCOUNT 1

ACCOUNT 4     ACCOUNT 1     UNASSAIGNED

What happens to unassigned nodes when they are transferred from SAP BW? In the SAP BW unassigned nodes are under a node called "unassigned." Would they be transferred to a node called "unassigned"

Cheers,

[former_member186338 · Accepted solution]

In BPC it's absolutely not possible to assign:

in PARENTH1:

PARENTACCOUNT1

  BASEACCOUNT1

  BASEACCOUNT2

And in PARENTH2

PARENTACCOUNT1

  BASEACCOUNT1

  BASEACCOUNT2

  BASEACCOUNT3

Just try in admin client!

Vadim

Unassigned nodes - goto root base members!

[Former Member · Accepted solution]

Hi,

That doesnt make sense (to me anyways) because then what is the point of having two hierarchies because if all have the same parent then wont they be the same hierarchies?

Or do you mean they both have to have the same top node?

Cheers

[former_member186338 · Accepted solution]

For different hierarchies you use different node members (parents)!!!!

For example we have 5 hierarchies in our TITLES dimension, with same base members and different parents (aggregation by clusters, by title types, by auditory of readers etc...)

Vadim

P.S. To track changes in hierarchy - Time Dependent Hierarchy approach is used (TDH)

[Former Member · Accepted solution]

Hi to confirm then the following is possible?

in PARENTH1:

ACCOUNTA

       ACCOUNT1

       ACCOUNT2

ACCOUNTB

       ACCOUNT3

And in PARENTH2

ACCOUNTA

       ACCOUNT1

       ACCOUNT2

       ACCOUNT3

ACCOUNTB

Sure, TDH is an option which I am looking at as well.

[former_member186338 · Accepted solution]

No, this is NOT possible - different base members for parent ACCOUNTA in PARENTH1 and PARENTH2!

Vadim

[Former Member · Accepted solution]

Hi,

above you mentioned

For different hierarchies you use different node members (parents)!!!!

For example we have 5 hierarchies in our TITLES dimension, with same base members and different parents (aggregation by clusters, by title types, by auditory of readers etc...)

Can you please illustrate the example?

thanks

[former_member186338 · Accepted solution]

Example:

Hierarchy 1 (Clusters - Brands):

BRAND_X

     PRINT_X

          PRINT_X_NORMAL (base)

          PRINT_X_SMALL (base)

     PRINT_X_SUPPL (base)

     DIGITAL_X (base)

     WEB_X (base)

     CONF_X (base)

     BOOKS_X (base)

BRAND_Y

     PRINT_Y (base)

     PRINT_Y_SUPPL (base)

     DIGITAL_Y (base)

     WEB_Y (base)

...

Hierarchy 2 (Types):

PRINT

     PRINT_X_NORMAL (base)

     PRINT_X_SMALL (base)

     PRINT_X_SUPPL (base)

     PRINT_Y (base)

     PRINT_Y_SUPPL (base)

DIGITAL

     DIGITAL_X (base)

     DIGITAL_Y (base)

WEB

     WEB_X (base)

     WEB_Y (base)

OTHER

     CONF_X (base)

     BOOKS_X (base)

...

Vadim

[Former Member · Accepted solution]

Hi,

BRAND_X would need to be in hierarchy 2 so i assume that this is a root? Then this would have different base members to hierarchy 1 as it would have none or is that ok?

Cheers,

[former_member186338 · Accepted solution]

BRAD_X is a parent member existing only in hierarchy 1

PRINT is a parent member existing only in hierarchy 2

etc...

Is it clear?

[former_member186338 · Accepted solution]

You can't use:

[TITLES].[PARENTH1].[PRINT]

or

[TITLES].[PARENTH2].[BRAND_X]

[Former Member · Accepted solution]

Hi,

It would exist as a not assigned node - agree?

For example BRAND_X would have be empty PARENTH2

Cheers,

[former_member186338 · Accepted solution]

"BRAND_X would have be empty PARENTH2" - correct!

You can use parent member in 2 hierarchies ONLY with same base members. If not - unassigned!

Vadim

[Former Member · Accepted solution]

Hi - Any ideas why this rule exists?

[former_member186338 · Accepted solution]

Take it as is for classic model. It was the same for BPC 7, 7.5, 10 ...