Hi,

I have come across an issue with the interaction of attributes, rules and hierarchies that I have been unable to workaround.

I have a relatively simple KPI where I need to average the value by the number of working days in the period for C level Periods only.

Each Cost Centre belongs to a Division of the business, different Divisions have a different number of working days and so I need to look up the division of a Cost Centre in my rule.

This gives me a rule like this.

['Measure':'Measure':'M Total for Av']=N:['Measure':'Measure':'Measure'];

['Measure':'Measure':'Measure']=C:
#Allow to add up on the N level periods  
  If(ELLEV( 'One Year', !One Year )= 0 , stet,
#Else calculate the average
  ['Measure':'Measure':'M Total for Av'] \
  DB('Period Properties', DB('}ElementAttributes_CostCentre', !CostCentre, 'Division' ), !One Year, 'Days in Period' )
  );

and  a result that looks like this.

If I rule trace on 2025, Total CC I can see the look-ups happening as expect

Now to introduce hierarchies to the mix, this works fine as long as I only have 1 hierarchy of the cost centre dimension in the mix.

Here we can see the second hierarchy "H2" working, with a different C level.  I do of course have to populate this hierarchies consolidations division values.

and the rule trace

So far so good..

If I have both hierarchies in the view then the intersections of the consolidations do not evaluate.

In the rule we can see it is trying to look-up the intersection of ['Total CC' , 'Total CC H2'] in the attribute look-up.

It is not possible to populate this cell in the attribute cube.

I've tried various ways to work around this.

I set up a "All Members" hierarchy that contains all the members of the other hierarchy and used this for my look-up

DB('Period Properties',  ElementATTRS( 'CostCentre', 'All Members', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This doesn't work, I'm assuming !CostCentre resolves to a tuple of ['Total CC' , 'Total CC H2'], so the lookup fails everywhere or because the All Members hierarchy isn't in the view then the look-up fails, I did get better results with All Members in the view but then I can't report they way I want.

I also set up a new dimension "Master CC" with no hierarchies that contains all members of the Cost Centre dimension.

DB('Period Properties',  ElementATTRS( 'Master CC', 'Master CC', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This also fails at all C levels.

I also tried DB('}ElementAttributes_CostCentre',...) instead of ElementATTRS to look up the Division then I get partially working behaviour on the intersections of N and C levels in the Cost Centre hierarchies.  If I use ElementATTRS to do the look-up then the logic fails on any C level from any hierarchy.

So I understand why this is failing, once we get to the point that the engine is looking up a tuple on the hierarchies then all the lookups fail.

On the assumption that I have not missed a trick here, this is problematic if we can't write C level rules that contain attr look-ups where the dimension might have hierarchies.  It either limits the use of Hierarchies or the complexity of the rules, both big selling points of PA.  Worse the introduction of hierarchies breaks rules that already work.  It's not great when two key pieces of functionality do not play well with each other.

Not sure what the answer is, the engine needs to make a choice if presented with a tuple for an attribute look-up.  Maybe something like picking the lowest level (using bottom up counting) member in the tuple and in the event of a tie pick the first one would work (easy to say I know!)

This is all based on an abstraction of a real problem at a client site.

Happy to supply my example server to anyone who wants to dig deeper.

------------------------------
Steven Rowe
------------------------------

Hi

Based on your last cube screenshot, what dimension is in the column section? Is it the hierarchy of CostCentre dimension?

And what is your expectation on the rules? I guess it makes sense for the system to not calculate because it doesn't know which division to use. Also did you specify in the rule to use which hierarchy when you lookup the division?

------------------------------
Def Marshal

Original Message:
Sent: Mon October 20, 2025 01:32 PM
From: Steven Rowe
Subject: Using String Attribute Look-ups in Rules at the C level and interaction with Hierarchies

Hi,

I have come across an issue with the interaction of attributes, rules and hierarchies that I have been unable to workaround.

I have a relatively simple KPI where I need to average the value by the number of working days in the period for C level Periods only.

Each Cost Centre belongs to a Division of the business, different Divisions have a different number of working days and so I need to look up the division of a Cost Centre in my rule.

This gives me a rule like this.

['Measure':'Measure':'M Total for Av']=N:['Measure':'Measure':'Measure'];

['Measure':'Measure':'Measure']=C:
#Allow to add up on the N level periods  
  If(ELLEV( 'One Year', !One Year )= 0 , stet,
#Else calculate the average
  ['Measure':'Measure':'M Total for Av'] \
  DB('Period Properties', DB('}ElementAttributes_CostCentre', !CostCentre, 'Division' ), !One Year, 'Days in Period' )
  );

and  a result that looks like this.

If I rule trace on 2025, Total CC I can see the look-ups happening as expect

Now to introduce hierarchies to the mix, this works fine as long as I only have 1 hierarchy of the cost centre dimension in the mix.

Here we can see the second hierarchy "H2" working, with a different C level.  I do of course have to populate this hierarchies consolidations division values.

and the rule trace

So far so good..

If I have both hierarchies in the view then the intersections of the consolidations do not evaluate.

In the rule we can see it is trying to look-up the intersection of ['Total CC' , 'Total CC H2'] in the attribute look-up.

It is not possible to populate this cell in the attribute cube.

I've tried various ways to work around this.

I set up a "All Members" hierarchy that contains all the members of the other hierarchy and used this for my look-up

DB('Period Properties',  ElementATTRS( 'CostCentre', 'All Members', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This doesn't work, I'm assuming !CostCentre resolves to a tuple of ['Total CC' , 'Total CC H2'], so the lookup fails everywhere or because the All Members hierarchy isn't in the view then the look-up fails, I did get better results with All Members in the view but then I can't report they way I want.

I also set up a new dimension "Master CC" with no hierarchies that contains all members of the Cost Centre dimension.

DB('Period Properties',  ElementATTRS( 'Master CC', 'Master CC', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This also fails at all C levels.

I also tried DB('}ElementAttributes_CostCentre',...) instead of ElementATTRS to look up the Division then I get partially working behaviour on the intersections of N and C levels in the Cost Centre hierarchies.  If I use ElementATTRS to do the look-up then the logic fails on any C level from any hierarchy.

So I understand why this is failing, once we get to the point that the engine is looking up a tuple on the hierarchies then all the lookups fail.

On the assumption that I have not missed a trick here, this is problematic if we can't write C level rules that contain attr look-ups where the dimension might have hierarchies.  It either limits the use of Hierarchies or the complexity of the rules, both big selling points of PA.  Worse the introduction of hierarchies breaks rules that already work.  It's not great when two key pieces of functionality do not play well with each other.

Not sure what the answer is, the engine needs to make a choice if presented with a tuple for an attribute look-up.  Maybe something like picking the lowest level (using bottom up counting) member in the tuple and in the event of a tie pick the first one would work (easy to say I know!)

This is all based on an abstraction of a real problem at a client site.

Happy to supply my example server to anyone who wants to dig deeper.

------------------------------
Steven Rowe
------------------------------

Hi Def,

Yes, both rows and columns are hierarchies of the Cost Centre dimension.

My expectation of the rules is that they should return the Division of one of the Cost Centres, it's understood why it doesn't as it is having to deal with a tuple but I would point out that if we use  DB('}ElementAttributes_CostCentre', !CostCentre, 'Division' ) to do the look-up it does appear to default down to the N level in the tuple if there is one in it.  So there is already some kind of choice making taking place.

I did test being explicit about the hierarchy but this doesn't really work as that means that hierarchy has to be in the view.  My customer and, in fact, all customers of PA have the ability to create hierarchies on an ad-hoc basis and they should be able to do so without breaking the rule calculations.

------------------------------
Steven Rowe

Original Message:
Sent: Mon October 20, 2025 09:02 PM
From: Def Marshal
Subject: Using String Attribute Look-ups in Rules at the C level and interaction with Hierarchies

Hi

Based on your last cube screenshot, what dimension is in the column section? Is it the hierarchy of CostCentre dimension?

And what is your expectation on the rules? I guess it makes sense for the system to not calculate because it doesn't know which division to use. Also did you specify in the rule to use which hierarchy when you lookup the division?

------------------------------
Def Marshal

Original Message:
Sent: Mon October 20, 2025 01:32 PM
From: Steven Rowe
Subject: Using String Attribute Look-ups in Rules at the C level and interaction with Hierarchies

Hi,

I have come across an issue with the interaction of attributes, rules and hierarchies that I have been unable to workaround.

I have a relatively simple KPI where I need to average the value by the number of working days in the period for C level Periods only.

Each Cost Centre belongs to a Division of the business, different Divisions have a different number of working days and so I need to look up the division of a Cost Centre in my rule.

This gives me a rule like this.

['Measure':'Measure':'M Total for Av']=N:['Measure':'Measure':'Measure'];

['Measure':'Measure':'Measure']=C:
#Allow to add up on the N level periods  
  If(ELLEV( 'One Year', !One Year )= 0 , stet,
#Else calculate the average
  ['Measure':'Measure':'M Total for Av'] \
  DB('Period Properties', DB('}ElementAttributes_CostCentre', !CostCentre, 'Division' ), !One Year, 'Days in Period' )
  );

and  a result that looks like this.

If I rule trace on 2025, Total CC I can see the look-ups happening as expect

Now to introduce hierarchies to the mix, this works fine as long as I only have 1 hierarchy of the cost centre dimension in the mix.

Here we can see the second hierarchy "H2" working, with a different C level.  I do of course have to populate this hierarchies consolidations division values.

and the rule trace

So far so good..

If I have both hierarchies in the view then the intersections of the consolidations do not evaluate.

In the rule we can see it is trying to look-up the intersection of ['Total CC' , 'Total CC H2'] in the attribute look-up.

It is not possible to populate this cell in the attribute cube.

I've tried various ways to work around this.

I set up a "All Members" hierarchy that contains all the members of the other hierarchy and used this for my look-up

DB('Period Properties',  ElementATTRS( 'CostCentre', 'All Members', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This doesn't work, I'm assuming !CostCentre resolves to a tuple of ['Total CC' , 'Total CC H2'], so the lookup fails everywhere or because the All Members hierarchy isn't in the view then the look-up fails, I did get better results with All Members in the view but then I can't report they way I want.

I also set up a new dimension "Master CC" with no hierarchies that contains all members of the Cost Centre dimension.

DB('Period Properties',  ElementATTRS( 'Master CC', 'Master CC', !CostCentre, 'Division' ), !One Year, 'Days in Period' )

This also fails at all C levels.

I also tried DB('}ElementAttributes_CostCentre',...) instead of ElementATTRS to look up the Division then I get partially working behaviour on the intersections of N and C levels in the Cost Centre hierarchies.  If I use ElementATTRS to do the look-up then the logic fails on any C level from any hierarchy.

So I understand why this is failing, once we get to the point that the engine is looking up a tuple on the hierarchies then all the lookups fail.

On the assumption that I have not missed a trick here, this is problematic if we can't write C level rules that contain attr look-ups where the dimension might have hierarchies.  It either limits the use of Hierarchies or the complexity of the rules, both big selling points of PA.  Worse the introduction of hierarchies breaks rules that already work.  It's not great when two key pieces of functionality do not play well with each other.

Not sure what the answer is, the engine needs to make a choice if presented with a tuple for an attribute look-up.  Maybe something like picking the lowest level (using bottom up counting) member in the tuple and in the event of a tie pick the first one would work (easy to say I know!)

This is all based on an abstraction of a real problem at a client site.

Happy to supply my example server to anyone who wants to dig deeper.

------------------------------
Steven Rowe
------------------------------