TM1 Dynamic Aliases – changes not being picked up by feeders

[ChrissyG]

Version: 10.2 FP1
Note: I have attached the issue with screenshots in a Word doc so it is easier to understand.

I have a dimension called “RollingMonths” consisting of month offset keys. Its alias is the actual month name and year for the current state. It is updated using rules that reference 1. An assumptions cube that defines the current month and 2. the Months dimension to figure out the month names of the offset months.

As a test I have hardcoded some feeders from the Assumptions cube to each element in this cube to ensure they are being fed. When using zero suppression all values show up correctly.
[{'OPEX Current Month','OPEX Current Year'},'Value']=>
DB('}ElementAttributes_RollingMonths','m-1','Description'),
DB('}ElementAttributes_RollingMonths','m-2','Description'), …etc
I have an Input cube that uses the RollingMonths dimension along with other dimensions (let’s call them Dim 1, Dim 2). The input cube displays Budget and Actuals scenarios that are rule derived from a Master cube and also has a scenario Forecast that is editable. The Master cube has dimensions Years, Months, Dim 1, Dim 2 – so it is the same structure as the Input cube only a different time dimension. The Master cube values are updated via process and the only rules are feeders to the Input cube.
Input Cube Rule:
[]=N:

IF(!FCST_Scenario @= 'Current Forecast', CONTINUE,

DB('OPEX Fcst vs Bud vs Act Cube',

SUBST( ATTRS('RollingMonths',!RollingMonths,'Description'),5,4 ),
SUBST( ATTRS('RollingMonths',!RollingMonths,'Description'),1,3 ),

!Date_Type,!Hierarchy_DualTree,!Account_Group,!FCST_Scenario, !FCST_Measures)
);
Master Cube Feeder:
['Activity Date','Budget','Net Amount']=>

DB('OPEX Forecast Input Cube',
( ATTRS('Months',!Months,'Month Short Name') | ' ' |!Years ),
'Activity Date',!Hierarchy_DualTree,!Account_Group,'Budget','Net Amount');

The Issue:
As an example – let’s say the current month is May.
At the end of each month, the process is to update the current month to June – which will shift all the alias names in the RollingMonths dimension. The }ElementAttributes_RollingMonth Cube updates successfully, but when I look at the Check Feeders statement for Budget in Jan, it still points to m-4 which according to the }ElementAttributes_RollingMonth Cube is the element name for the alias Feb 2014.
The other thing that happens is when I run a process that copies data from the Master Cube to the Input Cube, it also copies January data to Feb 2014 (or m-4), February data to Mar 2014 (or m-3) as per the prior mapping state. The following is the code in the TI process, where V1 is Years and V2 is Months.
vRollingMonthTarget = ATTRS('Months', V2, 'Month Short Name') | ' ' | V1;
ValueN = CellGetN(vSourceCube,V1, V2, V3, V4, V5, vCopyFromElement, V7);
CellPutN(ValueN,vTargetCube, vRollingMonthTarget, V3, V4, V5, vCopyToElement, V7);

I have found some things that work. I created a dummy cube that included the element name and alias as values.

If I click recalculate on this cube after a month change, I see the correct mappings. AND my TI process and feeders work correctly. They have no connection to this cube other that the fact that they pull the rolling months information from the same source (ie }ElementAttributes_RollingMonths).
My current solution:
If I recompile the dimension by adding a dummy element, saving it and then deleting the element – then everything works as it should. I am using this method as well because I can code it into a TI process and have it scheduled.

If anyone can explain to me what is happening behind the scenes in TM1 that is causing this issue and/or provide me with a more elegant solution it would be greatly appreciated!

Thanks for your time!

[tomok]

Feeders don't refire when you update a string value used in a feeder which is in essence what you are doing by updating the alias values. You have to force them to be re-evaluated either be recycling the service or doing something else like saving the rule file or issuing a CubeProcessFeeders command in a TI.

[ChrissyG]

The funny thing is, and I forgot to mention this in my initial post, but even when executing a CubeProcessFeeders in a TI process it doesn't do anything and I still get the incorrect mappings.

[Steve Rowe]

There are two components to this problem, the feeder and it being retriggered when the alias changes, it sounds like you have a handle on this. There is also the change to the alias to consider, this is tricky when you are moving a alias from one element to another.

So...It might be worth checking that your month alias are rolling around the way you think they are. You'll need to clear them down totally before repopulating them with the new offset. I'd be inclined to do the work in 3 different TIs to give the metadata chance to sort itself out.
1. Clear the offset alias
2. Populate the alias with new items
3. Process feeders.

Cheers,

[ChrissyG]

Thanks for the reply! I am testing out this solution now, but have run into a bit of an issue.

I have tried 2 things:
1. Deleting the attribute altogether (and removing the rules that populated it).
2. Assigning the alias new values (not related to month names as it was before). I tried both blank values and its respective element name values. Even an arbitrary "test" value on one element.

When I view the }ElementAttributes_RollingMonths cube, I see the expected results.

I then tried to update the month, and add the alias back and set it with the new values for Mmm YYYY but it gives me an error stating that it is a duplicate alias name.

I went to my Rolling Months Cube to see what the mappings currently looked like. This cube contains a Mmm YYYY value calculated from the Months Dimension and uses the following rule to get the associated element name from the RollingMonths attribute:

['Code']=S:
DIMNM('RollingMonths',
DIMIX('RollingMonths', DB('Rolling Months Cube',!Years,!Months,'Description') )
);


Even with the attribute deleted from the RollingMonths Dimension, I still see the old mappings! How does TM1 not throw an error that the attribute does not exist? What am I missing? Is there some hidden code within the guts of TM1 that says if there is a rule/feeder attached to the attribute then hold its values in some temp file?

Note: I have even tried the CubeProcessFeeders command after deleting the alias.

Update: If I change any code referencing the alias and use the ATTRS it changes the results. This corrects my Rolling Months Cube and my feeders so I see the expected mappings. However, I still can't update my alias without it complaining about it not being unique. The only thing that makes this work is again refreshing the RollingMonths Dimension by adding then removing a dummy element. Seems that no matter how I try to work around this issue TM1 wants to cache the old values and make things difficult.

[Steve Rowe]

Hi,

The following maybe happening and apologies as I did not word my instructions very well.

Clearing the alias value with a blank may not do anything since blank is not a valid alias value, this may mean that TM1 struggles to drop the old alias pointers.
Setting the alias value to the element name may also not do anything since that is the default value for the alias and so again TM1 may struggle to drop the alias.

The above is conjecture, not tested.

Setting the alias value to something new and unique should force the change through and then you should then be able to set them to the real values you want. If this didn't work I would just build and delete a subset against the dimension in TI just to give it a nudge.

Cheers,