TM1 Forum

Karthik1710 wrote:Curious. I just tested it out.

Had a test cube created with 2 dimensions (Dummy_Acct, Dummy_Amount).
First entered an amount of 25000 for all accounts.
Through a rule, assigned 500 to one specific account.

Using a TI, I took the cube as source and used below:
ViewExtractSkipCalcsSet
ViewExtractSkipRuleValuesSet
ViewExtractSkipZeroesSet

Put in an ASCIIOUTPUT in Data.

Result: I did not see the rule over-ridden Account in the output file.

So I think the ViewExtractSkipRuleValuesSet works the way I thought it works. It simply skips reading the cells that have rules set. Is that what you are looking for?

P.S.: I am yet to check what are the config parameters set.

This would be not just interesting, but a potential major headache. Can you please attach your test case?

I am new at the forum and the discussion seems a bit obsolete, but I have to give a try...
We are facing the same problem in TM1 10.2.2. RTM as PavoGa, in a more mysterious appearance: sometimes the process(es) retrieve the rule-calculated value, sometimes the values "behind" the rule (ie. the value written into the cell before a rule calculation was applied).
The corresponding feeders are set up correctly.
I am convinced that the command ViewExtractSkipRuleValuesSet must not "deactivate" the rule, instead it should only force the process to disregard the cells which are rule-driven.
For, at least in our TM1 models, it is a frequent thing that a cell contains a manually entered value, which is later overridden by a rule calculation, e.g. the user sets a calculation from a picklist in a "calculation type cube". In this case either the process should retrieve the rule-calculated value, or disregard the cell, if ViewExtractSkipRuleValuesSet is set to 1. (Also, the original, manually entered value should remain, since the described scenario must be reversible.)
I ran over the complete variety of Fix Lists, but still have no clue...
Please reply if you have any new ideas.