Best option for not calculating other versions in cubes

[BigG]

Hi There,

I have intention in 1st few lines of TM1 cube rules to STET versions that are read only, as these are copied from a 'current' version through TI so dont need to be calculated. To do this I can reference the versions:
['version_copy_1'] = N: STET
['version_copy_2'] = N: STET
etc

But new versions are contiuually added so this is not manageable for updating of 'hardcoded'' rules.

could try for each calculated measure ['Calculated Measure'] = If( !Version @= 'Current', CONTINUE, STET) ; but this will mean repeating for each calculated measure

Looking for alternatives or suggestions for another method to achieve the best result.

Basically dont need to calculate any other version (except current) as TI process will load these from current for archiving as data.

Thanks for replies in advance. Tell me if you want me to expand. Cheers

[Steve Vincent]

i'm afraid no matter what you do, some form of maintenance is going to be required. you could use an attribute against the version that denotes if it calculated or input. if you reference that attribute in your rule and apply it to all versions, then at least you don't need to maintain the rule but you still need to update the attribute.

[garry cook]

IMO, the easiest form of maintenance is create a Static Version consolidation and lump your statics under there then put

[]=N:IF(ELISANC('Version','Static Version',!Version)=1,STET,CONTINUE); (or put a 2 line string / numeric check if you've got string variables mixed in with FEEDSTRINGS)

as your first line. Still requires maintenance but it's usually safer to have someone update a consolidation than update the rules - at the very least, it's certainly easier to diagnose if something goes wrong.

Does give that annoying side effect of the Rule Tracer always having that rule at the top though when you look at it which always annoys me.

As an aside, if you have a maintenance proccess or TI each night to put any versions which aren't part of the Static consol into a Live Consol, you get the advantage of pointing your feeders at the Live consol and take advantage of the feeding a consol actually feeding the descendants functionality to avoid overfeeding (which can quickly get out of hand with versioned static data otherwise).

As Steve said though - you'll need a bit of maintenance whatever you do.

[BigG]

thanks for your quick responses

After thinking through a bit more, since the live version (current) is always the same and only a single version, I think the following works. Tell me if you think not

[] = If( !Version @= 'Current', CONTINUE, STET) ;

The maintenance TI process will always source 'current' and target the static version indicated manually as part of the admin process. Run once as a snapshot then next time a new version is created and this is targeted.

With the feeders - would only feed 'Current' as it is only one element - no need for the consol Live. But thanks for the suggestion as that logic would help with other areas.

[jydell]

I create a C element in the dimension called "stet versions' then place the n elements i want stet'd out under this. Then I use "eliscomp" formula to determine if the version is a child of the 'stet versions' and stet out accordingly. This 1 rule is then repeated through all relevant cubes.

For me this is easy to maintain, transparent to others and eliminates the need to continually update rules.

JD

[harrytm1]

Hi all,

I notice that if I use the following at the top of the rules to STET out history versions, it will result in subsequent rules that calculate based on calculated string measure values in the same cube.

[] = IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

Scenario:
A country assumption cube that allows users to default the calculation method by country. Say, "Method A" or "Method B".

Another details cube that pulls the selected country calculation method over based on the Entity dim attribute "Country". Hence, a string measure "Country Calc Method" is created in this cube and rule is written to do the above.

This details cube also has Feedstrings written at the 1st line. Everything is ok so far i.e. the method is pulled over correctly.

Next, another string measure is created to allow user to manually override the country method e.g. "Calc Method Override". Also, another string measure "Final Calc Method" is created. The rule is simply checking that if "Calc Method Override" is not blank, use "Calc Method Override", else use "Final Calc Method".

After saving the rules, the above "Final Calc Method" is not calculated at all i.e. it does not display the correct method, whether it is the country default, or the override selection.

I then remove the earlier stated ELISANC STET rule and the logic works. I further replace the ELISANC STET rule with the following and it works too:
[ {'History 1', 'History 2'}] = STET;

Next, I introduce one text attribute and one numeric attribute in Version dim and instead of using ELISANC, I used ATTRS and ATTRN separately to test. Both FAILED.

The conclusion: there seems to be a bug relating to NOT ELISANC per se (as evident from the same issue using ATTRS and ATTRN) but relating use a rule-calculated string measure to further calculate some other numeric or string measures. This is in conjunction with having a STET statement earlier with [] or [] = S: as the LHS. This may be due to Feedstrings, but I'm not sure.

If I use [] = N: as LHS in the STET statement, it is ok.

Anyone experienced the same issue? It greatly hampers the way rules are written.

Harry.

[harrytm1]

Anyone can help on the above? Or can confirm that it is indeed a bug?

Using 9.5.2 FP3 and 10.1.

[Steve Rowe]

Hi Harry,

I struggled to quite get what you are saying....

Any chance of posting the rules and a cube view?

Cheers,

[lotsaram]

Anyone can help on the above? Or can confirm that it is indeed a bug?

Using 9.5.2 FP3 and 10.1.

Hi Harry I get what you are saying and your approach sounds correct. There should be no difference if you leave out the N: qualifier so it might be a bug (behaviour of STET and especially CONTINUE have been known to be at times flaky for C: and qualifier omitted). But it sounds like you have an easy workaround - just use N: with your "history rule". Any reason why this won't work in your case?

[Duncan P]

[] = IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

I don't know if it's relevant but this statement above only applies to (and therefore turns on STET for) numeric cells. If you want STET for string cells as well you need

Code: Select all

[] = S: IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);
[] = IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

Be aware that in some older versions of TM1 the S: statement must come before the numeric version in order for both to apply.

[harrytm1]

Hi all,
thanks for the replies.

Just wanna simplify to the following:

Case A:
This does not work i.e. Calculated string values in non-history versions cannot be used further in other rules.
[] = IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

Case B:
To lotsaram, I need to STET both S and N, hence I cannot use this only
[] = N: IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

Case C:
[] = S: IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);
[] = IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

I have not tried the above, but I thought using [] only (i.e. the 2nd line) will mean to apply to both N and S?
NOTE: I tested [] only; you are right, String rules will still apply. Guess my understanding is wrong.

I did try the following and it still fails:
[] = S: IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);
[] = N: IF(ELISANC('Version', 'History', !Version) = 1, STET, CONTINUE);

[Duncan P]

Code: Select all

[] = IF( ... );

applies to both N and C but not S. If you want S as well you have to specify it.

[harrytm1]

Update:

Case A:
If i use this by itself, the numeric rule that depends on calculated string values work. Of course, only the S rules get STET, the N rules will still apply in historic versions.
[] = S: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Case B:
If I use this, string rules will still apply in historic versions and numeric rules do not apply in historic version. However, the numeric rules in rule-versions will NOT work i.e. treat the calculated string value as blank.
[] = IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Case C:
If I use this by itself only, the result is the same as Case B.
[] = N: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Case D:
[] = S: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);
[] = N: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);
In this case, both S and N are used. Both S and N rules are successfully STET in historic versions. But the numeric rules in rule-versions will still NOT work i.e. treat the calculated string value as blank.

Case E:
Same result as Case D.
[] = S: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);
[] = IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Case F:
Same result as Case D.
[] = N: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);
[] = S: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Case G:
Same result as Case D.
[] = IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);
[] = S: IF(ELISANC('Version', 'Version History', !Version) = 1, STET, CONTINUE);

Conclusion:
Only Case A works. But it cannot STET the numeric rules in version history. Seems to be a bug, and a big one too.

[Duncan P]

Hi Harry,

Update:
However, the numeric rules in rule-versions will NOT work i.e. treat the calculated string value as blank.

In a number of places you mention rules that are not working, but we can't see what relation they have to the rest of the data, including that in the STET versions. Would it be possible for you to post the whole rule, or if not to create a test case that exhibits the same behaviour that you can share?

Cheers,
Duncan.

[Steve Rowe]

Also is it possible there is a rule order problem or a seperate N and C rule issue?

[Duncan P]

Good point Steve. When you post the rule Harry could you also include the value of AllowSeparateNandCRules from your TM1S.CFG. Thanks.

[harrytm1]

Sure! I'm creating a sample and will post the rules soon. Thanks for your help thus far!

[harrytm1]

Here are the images and rules. There are two identical cubes: Source and Target. The dimensions are Version, Year and Measure.

In the Version dim, Actual version is a child of "Version History" parent while Budget is not. In the Measure dim, the elements are String and Number. Only Target cube has rules. It pulls the String value from Source cube over to its own String measure. Then, if the calculated String value is "True", Number value will return 1000, else it will be -9999999.

Case A - Using [] = S: and []
Result: Number is calculated to be -999999 even though String (calculated) is "True" i.e. failed. STET is working in Actual version.

Case A_S and All_Fail.png (48.65 KiB) Viewed 15394 times

Case B - Using [] = S: ONNLY
Result: Number is calculated as 1000 as String (calculated) is "True" i.e. correct. STET for string is working in Actual version.

Case B_S only.png (48.67 KiB) Viewed 15394 times

Case C: [] = N: only
Result: Number = -9999999 i.e. failed.

Case D: [] = N: and [] = S:
Result: Number = -9999999 i.e. failed.

Case E: [] only without qualifier
Result: Number = -9999999 i.e. failed.

Case F: No STET at all
Result: Number = 1000 i.e. correct.

tm1s.cfg:
AllowSeparateNandCRules=T

I have also tested using AllowSeparateNandCRules=F, the results are still the same.

Hope this explains my observation. Let me know if you need more info.

[Steve Rowe]

Yuck, Agreed this is a bug.

I'm wondering if t might correct itself if you fed your string cell from source?

Cheers,

[harrytm1]

Sadly, feeding it does not help. I have tried in the actual model.

Please also note that TI will also fail to recognise the calculated string value even if it's fed.

Serious bug.