Hello All,
I am using Cognos Express 9.5.
I have built several contributor Models using the Dept Dimensions (Org Structure - Business Units) as the approval hierarchy. This has been working great but now my client would like to have an alternate hierarchy within the Dept dimension for BI reporting (Reporter), mainly for drilling through from the summary cubes to data entry cubes.
When I try to validate and publish the contributor model using the same subset (which excludes the alternate hierachy) I am getting two errors:
1. The Hierarchy has more than one top level member
2. the hierarchy includes consolidated members but excludes their children
Other Points
1. For the BI Reports drill throughs are required from a consolidated income statement (P&L Summary Cube) to Data entry cubes (Payroll and 5 other cubes). Manipulating one report to present the alternate hierarchy is okay but we are talking close to 8-10 reports
Options I considered
1. Creating specific report cubes - This is a lot of effort and and efficient use of rules (potential for TI processes-maybe?)
2. BI Report Manipulation - Alot effort
3. ???? I am still pondering
As always thanks for any suggestions
Lance
Contributor - Multiple Hierarchies in ApprovalHierarchy Dim
-
LanceTylor
- Posts: 66
- Joined: Mon Feb 27, 2012 12:37 am
- OLAP Product: TM1
- Version: 10.2.2 Fix Pack 4
- Excel Version: 2010
-
Derezed
- Posts: 16
- Joined: Fri May 18, 2012 10:23 am
- OLAP Product: TM1, Planning Analytics
- Version: 10.2.2, Planning Analytics 2.x
- Excel Version: Latest
- Location: UK
Re: Contributor - Multiple Hierarchies in ApprovalHierarchy
Hi there,
For the multiple hierarchies in an approval dimension, this is a known defect with TM1 9.5.2 Contributor. My company raised this as an issue with IBM and we worked around it by having separate dimensions for workflow and reporting (a maintenance overhead, but the only way we could think of). The bottom line is no alternative hierarchies in workflow dimensions (unless they are comprised of exactly the same elements as each other). This defect has been fixed in 10.1 and we were advised that it is highly unlikely this will be fixed in 9.5.x.
In my opinon dedicated reporting cubes are very handy if you have a contributorised application. They give you flexibility for controlling access to specific nodes sepatately in reporting and workflow (removing dead cost centres from workflow, for example, but keeping them in your reports for historical reasons).
EDIT: My comment that it was a 'known' defect might be misleading. We raised a service request when we encountered this issue and IBM were able to replicate on their systems using 9.5.x but not 10.1. Whether they choose to classify it as a defect is up to them, but the net result is the same.
For the multiple hierarchies in an approval dimension, this is a known defect with TM1 9.5.2 Contributor. My company raised this as an issue with IBM and we worked around it by having separate dimensions for workflow and reporting (a maintenance overhead, but the only way we could think of). The bottom line is no alternative hierarchies in workflow dimensions (unless they are comprised of exactly the same elements as each other). This defect has been fixed in 10.1 and we were advised that it is highly unlikely this will be fixed in 9.5.x.
In my opinon dedicated reporting cubes are very handy if you have a contributorised application. They give you flexibility for controlling access to specific nodes sepatately in reporting and workflow (removing dead cost centres from workflow, for example, but keeping them in your reports for historical reasons).
EDIT: My comment that it was a 'known' defect might be misleading. We raised a service request when we encountered this issue and IBM were able to replicate on their systems using 9.5.x but not 10.1. Whether they choose to classify it as a defect is up to them, but the net result is the same.