How to consolidate dimension with maximum of children?

[abcuser]

Hi,
in TM1 v9.5 I created the reclamation cube with the following dimensions:
1. Measure dimension: quantity
2. Product dimension: products --> product_id
3. Buyer dimension: buyers --> buyer_id
4. Defect dimension: defect --> defect_group --> defect_id

Buyer makes official reclaim for particular product. Measure "reclamation quantity" is tracked by buyer_id and product_id!
On single product there can be one or more defects!

I think I need the following consolidation: For product and buyer dimension there should be default sum consolidation. But for defect dimension there should be maximum of children for each level. Like:
defect = max (defect_group)
defect_group = max(defect_id)

Please see attached picture. Left side of picture are data from cube. Red rectangles should be calculated as max(children). On the right site there is spreadsheet of correct values. Green rectangles are using formula max(children).

How to create maximum consolidation to particular dimension (defect dimension) instead of having sum consolidation?

Regards

[jim wood]

I guess you could tackle this a couple of ways. The first approach I would look is at is having a C: level rule for quantity, specifically for Level 2 parents in the defect dimension. I guess this would start with an IF. Do an if to establish if the element is a level 2 parent in defect if not then stet. From there you would need to establish the max. I guess you could do this by a couple of methods. One approach is to have lookup cube containing the relationship between the defect codes and it's parent. Construct this via TI and base your rule off this.

Bare in mind this is just an approach that is bouncing around my head. I haven't tested this in any way,

Jim.

[abcuser]

...having a C: level rule for quantity, specifically for Level 2 parents in the defect dimension. I guess this would start with an IF. Do an if to establish if the element is a level 2 parent in defect if not then stet. From there you would need to establish the max...

I would prefer to solve the problem using rules. Can you please write a formula that I should write in rule?

P.S. Dimension defect has exactly three levels: defect (top member = level 2) --> defect group (level 1) --> defect_id (level 0). If I understand correctly I should write a max formula for level 2 and level 1.

[mastertito4]

...having a C: level rule for quantity, specifically for Level 2 parents in the defect dimension. I guess this would start with an IF. Do an if to establish if the element is a level 2 parent in defect if not then stet. From there you would need to establish the max...

I would prefer to solve the problem using rules. Can you please write a formula that I should write in rule?

P.S. Dimension defect has exactly three levels: defect (top member = level 2) --> defect group (level 1) --> defect_id (level 0). If I understand correctly I should write a max formula for level 2 and level 1.

Will there always be a set number of level 0 elements in each level 1 parent? I see from your example screenshot you always have 2 defect_id's for each defect group, will this pattern continue? or what range of level 0 elements in each level 1 parents do you anticipate?

[lotsaram]

This is quite an easy problem to solve with MDX but rather more difficult to solve with rules as the TM1 MAX rules function just returns the maximum of 2 values (not an array or cube area as you might expect).

If the defect dimension is static and therefore the children of each defect group are a known quantity AND there are not too many individual defect numbers as children for each defect group then you could accomplish this in rules with individual C level rules for each defect group which would consist of layered IF statements doing a value comparison of each pair of children. The levels above defect group would then also be a C level ConsolidateChildren rule on the defect dimension.

It is complicated but workable so long as the defect dimension is static and not too big.

[abcuser]

Will there always be a set number of level 0 elements in each level 1 parent? I see from your example screenshot you always have 2 defect_id's for each defect group, will this pattern continue? or what range of level 0 elements in each level 1 parents do you anticipate?

In first post I have written simple sample. Defect groups and defects_id can change. Dimension currently is having 94 members. Each defect group can have different number of members. But there are always three levels (defect, defect group and top_member).

This is quite an easy problem to solve with MDX...

I am using Cognos BI v8.4.1 Report Studio as end-user reporting tools and end-users are also making reports by them self. If I understand correctly MDX is at reporting stage not at cube design/build state, is it?

If the defect dimension is static and therefore the children of each defect group are a known quantity AND there are not too many individual defect numbers as children for each defect group then you could accomplish this in rules with individual C level rules for each defect group which would consist of layered IF statements doing a value comparison of each pair of children. The levels above defect group would then also be a C level ConsolidateChildren rule on the defect dimension.

Can you please write a sample for single member, that I can work on.

[abcuser]

By the way, is there any other way to solve this problem? I have been using Hyperion Essbase (now Oracle) for years and there there was something similar like a process in TM1 and with SQL I have created something like:
==========
SELECT
ConsolidationElement,
'@MAX(@CHILDREN(' CONCAT ConsolidationElement CONCAT '))' as ConsolidationElementAttribute,
Element
FROM
mytable
==========
Note: @max was accepting an array, @children returned an array of all children of current consolidated element.
Then I have market first column as element, second column as consolidation attribute and third as element. When process was run the consolidation was creating @MAX(@CHILDREN(ConsolidationElement)) formula for every consolidated element in defect dimension. So this was a way to change consolidation on defect dimension from sum to max for every measure. Is there something similar in TM1?

[mce]

By the way, is there any other way to solve this problem? I have been using Hyperion Essbase (now Oracle) for years and there there was something similar like a process in TM1 and with SQL I have created something like:
==========
SELECT
ConsolidationElement,
'@MAX(@CHILDREN(' CONCAT ConsolidationElement CONCAT '))' as ConsolidationElementAttribute,
Element
FROM
mytable
==========
Note: @max was accepting an array, @children returned an array of all children of current consolidated element.
Then I have market first column as element, second column as consolidation attribute and third as element. When process was run the consolidation was creating @MAX(@CHILDREN(ConsolidationElement)) formula for every consolidated element in defect dimension. So this was a way to change consolidation on defect dimension from sum to max for every measure. Is there something similar in TM1?

Hi abcuser,

I do not thing an attribute that determines which child element is the maximum one addresses any solution to your problem as attributes are static to a dimension and do not change depending on the context of a cube where the dimension is used. In your case, the max element may vary for a defect group depending on which product and which buyer you are looking at.

Obviously TM1's rule engine is not very useful for your requirement to perform aggregation not by sum, but my max.

I assume that your requirement for max aggregation is only on leaf levels of product and buyer, which means in consolidations of buyer and/or product, you do default aggregation for the defect group based on the max numbers found in leaf levels of product and buyer.

If this assumption is valid, an alternate solution would be to calculate defect group via a TI process as and when underlying data changes in defect level and store it in a separate cube that has buyer, product, and defect_group dimensions (defect group is a flat dimension with Level 1 and Level 2 members of your defect dimension). Then you can lookup to this cube from your main cube using a C level rule that applies to Level 1 and Level 2 of your defect dimension. Please notice that this rule will not require any additional feeders.

Obviously this approach can be properly implemented if quantities in your main cube are being updated via a TI process. If they are updated via manual entries, then updating your lookup cube for max quantities will require a user trigger or a schedule.

Regards,

[abcuser]

I do not thing an attribute that determines which child element is the maximum one addresses any solution to your problem as attributes are static to a dimension and do not change depending on the context of a cube where the dimension is used. In your case, the max element may vary for a defect group depending on which product and which buyer you are looking at.

Yes, I know. In Essbase there is "consolidation attribute" that does not have anything in common with tm1 attribute except similar names.

calculate defect group via a TI process

Can you write some sample how this id done using TI process?

Obviously this approach can be properly implemented if quantities in your main cube are being updated via a TI process.

All data are being updated using TI.

[abcuser]

Hi,
I have manage to solve the problem with solution of having three cubes, one cube for each level of defect dimension. I have created first cube (in picture blue rectangle) for top level, then I have written rules in second cube where I have created defect dimension with top and defect group level (in picture green rectangle) and pull data to consolidated level from first cube with DB function. The last operation was to create third cube with three levels (top, group defect and defect) (in picture red rectangle) and pull data to consolidated levels from second cube. End-user sees only third cube (in picture red rectangle).

This is solution that I have figured out, but I don't really like this solution, because of many thinks:
1. This is only a simple sample and it already looks complicated - the real production sample will be much more complicated (there are 10 dimensions and 17 measures) and so more difficult to maintain.
2. I am afraid there will be performance problems linking all this three cubes.

Does anyone has any other idea how to solve this "maximum" of children problem?

P.S. I suggest to open a attached picture in another window.
Regards

[paulsimon]

Hi abcuser

I think I may have a more flexible solution for you. This uses two cubes, and will work with an arbitrary number of levels in the hierarchy, including ragged hierarchies. I am not sure what the performance will be like on a real world cube. Depending on how important it is to you to have instant re-calculation, it may still be better to go the TI route (and effectively that is what Essbase does behind the scenes). However, I thought it might be worth proving that this can be done in TM1 using Rules. I have tried pasting in the example below, but I am not sure how this will format on the forum. If it doesn't display correctly , I have also attached an Excel sheet with the code. If you need any further explanation as to how this works, please let me know. If it still doesn't solve your problem then again please let me know.

Code: Select all

I created Cube MaxText to give a simplied example		
and entered some test data		

CUBE:	hqserv:MaxTest	
hqserv:MaxTestMeas	Value	


	Product A	Product B
All Locations	13	52
Germany	1	15
Berlin	0	4
Munich	1	11
UK	12	37
Midlands	3	5
Birmingham	2	3
Coventry	1	2
North	2	2
Edinburgh	2	0
Newcastle	0	2
South East	3	2
London	1	1
Reading	2	1
West and SW	4	28
Bristol	2	3
Cardiff	1	16
Devon	1	9
		
Note that this example has 3 levels of hierarchy, and that it is a ragged hierarchy		
with Germany have no Region level. Despite this the routine still copes.		
		
I then created a dimension called HierChild as follows:		
			
X	HierChild		

N	CH_1		1
N	CH_2		2
N	CH_3		3
N	CH_4		4
N	CH_5		5

C	CH_1_Cumu		1
	CH_1		


C	CH_2_Cumu		2
	CH_2		
	CH_1_Cumu		

C	CH_3_Cumu		3
	CH_3		
	CH_2_Cumu		

C	CH_4_Cumu		4
	CH_4		
	CH_3_Cumu		

C	CH_5_Cumu		5
	CH_5		
	CH_4_Cumu		

The Cumu elements are just there to help prevent over-feeding, so that			
eg if a Location only has two children then I will feed CH_2_Cumu, as we shall see later.			

It is important the CH_1 thru CH_5 appear in index positions 1-5 in the dimension.
If any of your elements had more than 5 children, it is easy to extend the
example to cope with that simply by adding more elements to 
the HierChild dimension, and modifying the rules slightly.

I then created another cube called MaxTestChild that is similar to MaxTest
but it has the extra HierChild dimension.

The MaxTestChild cube pulls in data from the MaxTest Cube via Rules
and uses the extra HierChild dimension to help calculate
the MaxVal (Maximum Value) of the children below each level
The rules in MaxTestChild are:

skipcheck ;

# Find Maximum Value at all levels.

# Limitations:
# Assumes that no Location has more than 5 elements
# Assumes no negative numbers.

# Prevent calculations at consol levels of the HierChild dimension
# ie the Cumus, since these are only there for feeding purposes.

[ 'Value']=C:
  IF( ELLEV( 'HierChild', !HierChild ) = 0 
        ,
        CONTINUE
        ,
        STET
   ) ;

# We want to pull in values against the appropriate HierChild
# of the Location.

['Value']=C:
#  If the location is at the base level (level 0) there are no children
#  so set the Value of each HierChild to 0
  IF( ELLEV('Location',!Location) =0
        ,
0
        ,
#     If the number of the HierChild being calculated (which is
#     the same as its dimix), is more than the number of 
#     children of the Location then set the Value
#     on that HierChild to 0 since there is no child of the Location
#     to supply a value.
        IF( dimix('HierChild',!HierChild) > ELCOMPN('Location',!Location) 
              ,
0
              ,
#           If the Location is at level 1, then this is the first level
#           that will have children.
#           Pull in the value from the MaxTest cube for the Location
#           that is the nth Child of the level 1 location, where n
#           is the dimix of the HierChild element in the HierChild dimension.
              IF( ELLEV('Location',!Location) = 1
                    ,
                    DB('MaxTest',
                          ELCOMP('Location',!Location,dimix('HierChild',!HierChild) ),
                          !Product,'Value'
                    )
                    ,
#                 For higher levels, in the location dimension, 
#                 we can reference this cube, and we take in
#                 the value from the nth child of the consolidated
#                 location, where n is the dimix of the HierChild element 
#                 in the HierChild dimension.
#                 We pull in the MaxVal from HierChild CH_1 since this
#                 is where the final max val is held (see below).
                    DB('MaxTestChild',
                         ELCOMP('Location',!Location,dimix('HierChild',!HierChild) ),
                         !Product,
                         'CH_1',
                         'MaxVal')
              )
        )
  ) ;
  
# Now we use recursion to loop through the values held against
#  HierChild 5 down to 1

# Since HierChild 5, CH_5, is the highest numbered HierChild, 
# the value on CH_5 must be the MaxVal so far.

# Start the Recursion

['CH_5','MaxVal']=C:
        ['CH_5','Value']
  ;

# We use recursion to compare the Value on a HierChild
# against the MaxVal recorded against the next HierChild
# so we compare the MaxVal of CH_5 against the
# Value of CH_4, and hold the result as the
# MaxVal of CH_4.
# Then we look at CH_3 and compare the Value 
# of CH_3 aganst the MaxVal of CH_4, and
# store the result as the MaxVal of CH_3, and so on
# until we come to CH_1 where the MaxVal against
# CH_1 must be the MaxVal across all 5 children.
# (If the location has less than 5 children it doesn't
# matter since the value there will be 0 so it won't
# be the max.

# Recurse bubbling max value down from CH_5 down to CH_1

['MaxVal']= 
  IF( ELLEV('Location',!Location) = 0 
        ,
0
        ,
        Max(
                ['Value']
                ,
                DB('MaxTestChild',
                     !Location,
                     !Product,
                      DNEXT('HierChild',!HierChild),
                       'MaxVal'
                )
        )
   ) ;

feeders ;

# To avoid over-feeding we feed to the cumu of the 
# HierChild number that is the
# max number of children of the Location	
# which automatically feeds all children before	
# this but not after this.	

['Value']=>	
   DB('MaxTestChild',	
        !Location,	
        !Product,	
        !HierChild | '_Cumu',	
         'MaxVal'	
   ) ;	

The Rules above mean that, within the 	
MaxTestChild cube the MaxVal is bubbled down to CH_1	

CUBE:	hqserv:MaxTestChild


		Product A	Product A	Product A	Product A	Product A	Product B	Product B	Product B	Product B	Product B
		CH_1	CH_2	CH_3	CH_4	CH_5	CH_1	CH_2	CH_3	CH_4	CH_5
Value	All Locations	1	2	0	0	0	11	16	0	0	0
Value	Germany	0	1	0	0	0	4	11	0	0	0
Value	UK	2	2	2	2	0	3	2	1	16	0
Value	Midlands	2	1	0	0	0	3	2	0	0	0
Value	North	2	0	0	0	0	0	2	0	0	0
Value	South East	1	2	0	0	0	1	1	0	0	0
Value	West and SW	2	1	1	0	0	3	16	9	0	0
MaxVal	All Locations	2	2	0	0	0	16	16	0	0	0
MaxVal	Germany	1	1	0	0	0	11	11	0	0	0
MaxVal	UK	2	2	2	2	0	16	16	16	16	0
MaxVal	Midlands	2	1	0	0	0	3	2	0	0	0
MaxVal	North	2	0	0	0	0	2	2	0	0	0
MaxVal	South East	2	2	0	0	0	1	1	0	0	0
MaxVal	West and SW	2	1	1	0	0	16	16	9	0	0

The MaxTest Cube has the following rules to											
feed values across to the MaxTestChild Cube and to											
pull back the result. Therefore the MaxTestChild cube can be relegated to being a calculation											
cube that no one needs to look at since the results can be obtained just by looking at the MaxTest Cube.											

skipcheck ;											

['MaxVal']= N: ['Value'] ;											

['MaxVal']=C:											
  IF( ELLEV( 'Location' , !Location ) = 0 											
        ,											
        ['Value'] 											
        ,
        DB('MaxTestChild',!Location,!Product,'CH_1','MaxVal') 
  ) ;

feeders ;

['Value']=>['MaxVal'];

# Feed to the Cumulative consolidation of the max number of
# children of the parent location.
# This will ensure that all children will be fed.

[]=>DB('MaxTextChild',
             !Location,
             !Product,
             'CH_' |
             str(				
                   elcompn('Location',				
                                 elpar('Location',!Location,1) 				
                   ) ,				
                   1,1				
             ) | '_Cumu',				
            !MaxTestMeas) ;				

The final result then looks like this				

CUBE:	hqserv:MaxTest			


	Product A	Product A	Product B	Product B
	Value	MaxVal	Value	MaxVal
All Locations	13	2	52	16
Germany	1	1	15	11
Berlin	0	0	4	4
Munich	1	1	11	11
UK	12	2	37	16
Midlands	3	2	5	3
Birmingham	2	2	3	3
Coventry	1	1	2	2
North	2	2	2	2
Edinburgh	2	2	0	0
Newcastle	0	0	2	2
South East	3	2	2	1
London	1	1	1	1
Reading	2	2	1	1
West and SW	4	2	28	16
Bristol	2	2	3	3
Cardiff	1	1	16	16
Devon	1	1	9	9

Regards

Paul Simon

[Melissa18]

Hi abcuser

Have you considered using the "Max" formula in a rule? Something like this:

['Quantity'] = C:
if(Ellev('Defect',!Defect)>0,
Max(DB('Reclamation', !Measure, !Product, !Buyer, Elcomp('Defect',!Defect,1)),
DB('Reclamation', !Measure, !Product, !Buyer, Elcomp('Defect',!Defect,2))),
Continue);

Not sure if this is exactly what you are looking for, but I'm sure it's worth playing around with.

Regards

[kpk]

In the 9.5.2 NewFeatureGuide I have found the following:

"New functions for Rules and TurboIntegrator
The following new functions are available in TM1, version 9.5.2 for use with rules and TurboIntegrator:
● ConsolidatedMin
● ConsolidatedMax
● ConsolidatedAvg
● ConsolidatedCount
● ConsolidatedCountUnique
Note: These functions were not documented in the standard TM1 9.5.2 documentation. For complete
details, search for these functions in the latest release documentation and updates on the IBM®
Cognos® TM1® Info center."

[abcuser]

['Quantity'] = C:
if(Ellev('Defect',!Defect)>0,
Max(DB('Reclamation', !Measure, !Product, !Buyer, Elcomp('Defect',!Defect,1)),
DB('Reclamation', !Measure, !Product, !Buyer, Elcomp('Defect',!Defect,2))),
Continue);

Melissa18,
this code works fine for simple sample posted in my first post!!!

Now I have implemented the same logic to my production cube (production cube has the same logic, just more dimensions and more measures). But in production this rule does not work correctly - at top levels of cube I get too small numbers. It looks to me, that "defect" dimension overrides other dimension calculations such as "buyer".

I have attached the production cube print-screen. At picture I have selected Quantity as measure, in rows there is Defect dimension and in columns there is Buyer dimension. I have drawn red rectangle at number 3 (which is incorrectly calculated!). It looks like this number is consolidated as max of children from defect dimension (green rectangle). But if we look at Buyer dimension consolidated value should be sum of buyer dimension children which equals to 4 (purple rectangle). So value in red rectangle should be 4 and not 3!

I hope I am making the correct assumption. If I am, is there any way I can set the calculation order of dimensions? To consolidate buyer dimension first and then defect dimension.
Regards

[paulsimon]

Hi abcuser

I hadn't noticed the consolidation scheme in the other dimension. I made a small modification to the rules I submitted earlier for the MaxTextChild cube, which I believe does what you want.

MaxVal.JPG (364.69 KiB) Viewed 26853 times

The change to the rules is highlighted in bold below. It uses ConsolidateChildren. I am not a big fan of this function but it is a way to get a calculated consolidation in one dimension while allowing natural consolidation in another. In your cube you probably have several hierarchies so you will need to list each of those dimensions as ConsolidateChildren(dim1,dim2,..), ie all hierarchical dimensions apart from the Defect dimension which is the one where you want the MaxVal function to apply.

skipcheck ;

# Find Maximum Value at all levels.

# Limitations:
# Assumes that no Location has more than 5 elements
# Assumes no negative numbers.

# Prevent calculations at consol levels of the HierChild dimension
# ie the Cumus, since these are only there for feeding purposes.

[ 'Value']=C:
IF( ELLEV( 'HierChild', !HierChild ) = 0
,
CONTINUE
,
STET
) ;

# We want to pull in values against the appropriate HierChild
# of the Location.

['Value']=C:
# If the location is at the base level (level 0) there are no children
# so set the Value of each HierChild to 0
IF( ELLEV('Location',!Location) =0
,
0
,
# If the number of the HierChild being calculated (which is
# the same as its dimix), is more than the number of
# children of the Location then set the Value
# on that HierChild to 0 since there is no child of the Location
# to supply a value.
IF( dimix('HierChild',!HierChild) > ELCOMPN('Location',!Location)
,
0
,
# If the Location is at level 1, then this is the first level
# that will have children.
# Pull in the value from the MaxTest cube for the Location
# that is the nth Child of the level 1 location, where n
# is the dimix of the HierChild element in the HierChild dimension.
IF( ELLEV('Location',!Location) = 1
,
DB('MaxTest',
ELCOMP('Location',!Location,dimix('HierChild',!HierChild) ),
!Product,'Value'
)
,
# For higher levels, in the location dimension,
# we can reference this cube, and we take in
# the value from the nth child of the consolidated
# location, where n is the dimix of the HierChild element
# in the HierChild dimension.
# We pull in the MaxVal from HierChild CH_1 since this
# is where the final max val is held (see below).
DB('MaxTestChild',
ELCOMP('Location',!Location,dimix('HierChild',!HierChild) ),
!Product,
'CH_1',
'MaxVal')
)
)
) ;

# Only use MaxVal calculation when only Location is consolidated
# and all other dims are base level. Otherwise allow normal
# consolidation to happen.

['MaxVal']=C:
IF( ELLEV( 'Location', !Location) > 0
& ELLEV( 'Product', !Product) = 0
,
CONTINUE
,
consolidatechildren('Product')
) ;
# Now we use recursion to loop through the values held against
# HierChild 5 down to 1

# Since HierChild 5, CH_5, is the highest numbered HierChild,
# the value on CH_5 must be the MaxVal so far.

# Start the Recursion

['CH_5','MaxVal']=C:
['CH_5','Value']
;

# We use recursion to compare the Value on a HierChild
# against the MaxVal recorded against the next HierChild
# so we compare the MaxVal of CH_5 against the
# Value of CH_4, and hold the result as the
# MaxVal of CH_4.
# Then we look at CH_3 and compare the Value
# of CH_3 aganst the MaxVal of CH_4, and
# store the result as the MaxVal of CH_3, and so on
# until we come to CH_1 where the MaxVal against
# CH_1 must be the MaxVal across all 5 children.
# (If the location has less than 5 children it doesn't
# matter since the value there will be 0 so it won't
# be the max.

# Recurse bubbling max value down from CH_5 down to CH_1

['MaxVal']=
IF( ELLEV('Location',!Location) = 0
,
0
,
Max(
['Value']
,
DB('MaxTestChild',
!Location,
!Product,
DNEXT('HierChild',!HierChild),
'MaxVal'
)
)
) ;

feeders ;

# To avoid over-feeding we feed to the cumu of the
# HierChild number that is the
# max number of children of the Location
# which automatically feeds all children before
# this but not after this.

['Value']=>
DB('MaxTestChild',
!Location,
!Product,
!HierChild | '_Cumu',
'MaxVal'
) ;


I would also suggest taking a look at the new functions in 9.5.2. However, I know that it is not always possible (or for that matter wise) to immediately adopt the latest version.

Regards


Paul Simon

[mce]

Good news!

The following new functions are available in TM1, version 9.5.2 for use with rules and TurboIntegrator:

● ConsolidatedMin
● ConsolidatedMax
● ConsolidatedAvg
● ConsolidatedCount
● ConsolidatedCountUnique

Note: These functions were not documented in the standard TM1 9.5.2 documentation. For complete
details, search for these functions in the latest release documentation and updates on the IBM®
Cognos® TM1® Info center.
http://publib.boulder.ibm.com/infocente ... /index.jsp
10 IBM

[kpk]

I have installed the 952 version but could not test it since there is no further information about the functions (eg. syntax) ...

Good news!

The following new functions are available in TM1, version 9.5.2 for use with rules and TurboIntegrator:

● ConsolidatedMin
● ConsolidatedMax
● ConsolidatedAvg
● ConsolidatedCount
● ConsolidatedCountUnique

Note: These functions were not documented in the standard TM1 9.5.2 documentation. For complete
details, search for these functions in the latest release documentation and updates on the IBM®
Cognos® TM1® Info center.
http://publib.boulder.ibm.com/infocente ... /index.jsp
10 IBM

[paulsimon]

Peter

I tried that link and if you search in that area on ConsolidatedMax it just finds the page you were already on. Isn't the IBM site wonderful.

I would guess that have a similar syntax to ConsolidateChildren.

Regards


Paul Simon

[Andy Key]

Search on the base ibm.com website, not the infocenter and you get...

https://www-304.ibm.com/support/docview ... s=swgimgmt

[Alan Kirk]

Search on the base ibm.com website, not the infocenter and you get...

https://www-304.ibm.com/support/docview ... s=swgimgmt

Well spotted, but check the update date; possibly the reason that no-one found it before is that it's only been there for a few hours.

Now personally I'm wondering how many minutes it would take me to modify the source documentation of a .pdf (the reference guide comes to mind), recompile it, and whack the updated version up for download again.

Or, indeed the main help file. Modifying the help file for TM1 Tools is a pain when new screenshots need to be taken, but a plain text modification like that? Type, save, compile, upload, and it's there in the main documentation.

Better than buried in some backwater and waiting for someone to remember to add it circa 2014. Maybe.

For those who think that's harsh or pessimistic I offer the example "SwapAliasWithPrincipalName". In earlier versions it appeared in the reserved words list of the TI manual without any explanation of what it was supposed to do or how it was supposed to work. I raised this, along with a bunch of other documentation-related issues, as an SR back at the start of December last year. It was closed on 8 Dec last year with the notation "Thank you for bringing these TM1 documentation issues to our attention, I shall raise the issues you have highlighted with the TM1
Documentation team, and request their investigation and correction."

Every glitch / issue/ absence that I raised, including the absence of proper documentation on SwapAliasWithPrincipalName, still exists in the 9.5.2 documenation, over 3 months later.

I swear, sometimes I think they don't so much have documentation as a jigsaw puzzle, where you may find bits and pieces of the answers if you search enough web sites. Probably starting with this one, thanks to observant folks like Andy.