TM1 Forum

Hi Gurus!
I have a TM1 Contributor Application and I need to separate only nodes that has Approved by Reviewer ( for export or visible in reports for example).
I saw the cube }tp_application_state_xxxx I can see the states of nodes, and I can make a TI process to export only nodes who state is green, but I'm not sure if this is the best way to do this.

Actually, in an Approval application, the approved node(parent node) should shows only the data who has reviewed, shouldn't?.

Anyone have any idea how to do this?

As far as I am aware, this is the way to go about it. You may already be aware, however see this link for IBM tech note on EP contributor node states:
http://www-01.ibm.com/support/docview.w ... wg21360941

0 = Not Started, 1 = Incomplete, 2 = Work in Progress, 3 = Ready, 4 = Locked

Last I checked, IBM has maintained the same id/value even in TM1 Contributor applications.

Hy sachin,
Although the link is about the EP Contributor (instead TM1 Contributor) you are right about the Node States. But I'm not sure if the Logic of the application are correct.
Let me show some example:
If you have some Approval application, and the approval hierarchy have 4 levels.
The leaf level submit the value for the parent, and than the parent level may choose if the value is right or not.

In this moment, the highest level already contains the value not approved by the parent.(node state is orange).

In my opinion, the highest level need to shows only the values that nodes are green.

Actually, in an Approval application, the approved node(parent node) should shows only the data who has reviewed, shouldn't?

Tianoklein,

As you've noticed approval states in TM1 are entirely separate from consolidation and the state acts only as a reference, hence how the cube can work on its own outside a contributor application.

Whether IBM have applied the correct logic here could easily be debated; for example you clearly believe only approved levels should be shown but from my perspective an approver could wish to know ahead of submission what sort of numbers are likely to be submitted to them.

If we ignore that however and look at getting you the results you want; there are a few ways to do it:

1/ A separate cube (or cubes) that are identical to your existing cubes but with an approval dimension; there is a simple = rule then placed against it looking at the original cube (note = not =N: etc) the rule does a lookup for each application status.

2/ Add a host of extra measures to your existing cubes to do the same as option 1 but without the extra cube.

3/ Add a host of extra versions/scenario to the version dimension in your existing cubes to do the same as option 1 but without the extra cube.

I feel that the extra cube gives more flexibility; depending how you wish to get into this cube and how often you need to update it you can easily use TI as opposed to rules.

tianoklein wrote: In my opinion, the highest level need to shows only the values that nodes are green.

Actually, in an Approval application, the approved node(parent node) should shows only the data who has reviewed, shouldn't?

From the situations I have seen so far, it is helpful to have the data at root node irrespective of whether or not the node is submitted. As declanr suggested, upper management, when they look open the root node, it is helpful for them to know numbers that they are going to see in the period.

I have seen the approval application used both ways.

• In one they rigorously followed the submission of node, keeping track of node states, calling the node owner to submit it on time.
• While in another, they did not rely on the node status at all - since it was a monthly forecasting app, users did not want to go through the hassle of submit/reject and then reset at beginning of forecasting period every month. We had means to lock/unlock the applications using the rights file. In this instances, all WIP was assumed to be submitted when applications were locked!

If your users want to see only the approved data in the hierarchy, you could build an alternate reporting cube and populate it using TI by doing node state look up at the }tp_applicationcube of the corresponding app. Publish this cube to Cognos Connection and build your BI reports off of it. HTH.