Planning Analytics

Why was TM1Val designed the way it was? We are exploring UniversalReports as a potential solution for our reporting needs and are finding the new formula cumbersome to implement, especially when moving from DBRWs. I am struggling to explain to our users why the new formula is such a departure from the old one. Why was it built like this? Before universal reports are broadly adopted these issues should be addressed. 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)
• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?
• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

I would appreciate insight anyone can share

------------------------------
Ryan Clapp
------------------------------

Hi,

I haven't use it because it is not available yet in our TM1 version :). But my understanding 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)

           with this, I think we can get value from more than one server or more than one cube in one sheet 

• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?

          according to IBM documentation, we only need to mention dimension name, hierarchy name, and then the element name from the dimension and hierarchy mentioned before. 

 [dim1].[hier1].[elem1]

• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

My understanding, mode selector make user can do checking before submit to TM1 server (mode 2) or directly write to tm1 (mode 1)  

we can make it as toggle. Once user ready to submit, then they choose mode 1, otherwise choose mode 2. 

Regards,

Veronika

------------------------------
Veronika Gultom

Original Message:
Sent: Tue April 23, 2024 02:46 PM
From: Ryan Clapp
Subject: TM1Val Design Questions

Why was TM1Val designed the way it was? We are exploring UniversalReports as a potential solution for our reporting needs and are finding the new formula cumbersome to implement, especially when moving from DBRWs. I am struggling to explain to our users why the new formula is such a departure from the old one. Why was it built like this? Before universal reports are broadly adopted these issues should be addressed. 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)
• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?
• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

I would appreciate insight anyone can share

------------------------------
Ryan Clapp
------------------------------

Mode 2 clears the data - so you wouldn't want to do that.

Mode 1 works like DBS / DBSW. So you have to point to a value somewhere. You cannot point the formula to itself. 

Mode 0 is read only. It's the equivalent of the READ part of DBRW but hierarchy enabled.

So you could change from 0 to 1 and it will then writeback the value you are pointing to but really you would propbably want 2 cases set up, one where you read and the other where you conditionally write using a user controlled lookup flag Y/N just as you would with DBRW & DBSW

------------------------------
John O'Leary

Original Message:
Sent: Wed April 24, 2024 01:48 AM
From: Veronika Gultom
Subject: TM1Val Design Questions

Hi,

I haven't use it because it is not available yet in our TM1 version :). But my understanding 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)

           with this, I think we can get value from more than one server or more than one cube in one sheet 

• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?

          according to IBM documentation, we only need to mention dimension name, hierarchy name, and then the element name from the dimension and hierarchy mentioned before. 

 [dim1].[hier1].[elem1]

• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

My understanding, mode selector make user can do checking before submit to TM1 server (mode 2) or directly write to tm1 (mode 1)  

we can make it as toggle. Once user ready to submit, then they choose mode 1, otherwise choose mode 2. 

Regards,

Veronika

------------------------------
Veronika Gultom

Original Message:
Sent: Tue April 23, 2024 02:46 PM
From: Ryan Clapp
Subject: TM1Val Design Questions

Why was TM1Val designed the way it was? We are exploring UniversalReports as a potential solution for our reporting needs and are finding the new formula cumbersome to implement, especially when moving from DBRWs. I am struggling to explain to our users why the new formula is such a departure from the old one. Why was it built like this? Before universal reports are broadly adopted these issues should be addressed. 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)
• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?
• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

I would appreciate insight anyone can share

------------------------------
Ryan Clapp
------------------------------

Why was TM1Val designed the way it was? We are exploring UniversalReports as a potential solution for our reporting needs and are finding the new formula cumbersome to implement, especially when moving from DBRWs. I am struggling to explain to our users why the new formula is such a departure from the old one. Why was it built like this? Before universal reports are broadly adopted these issues should be addressed. 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)
• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?
• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

I would appreciate insight anyone can share

------------------------------
Ryan Clapp
------------------------------

Hi Ryan,

I do agree on your point that it is quite complicated to use. It adds the flexibility from DBRW, however, not in the same simple way. 

Requiring users to use the URI also seems a bit mad to me, users don't know it, and don't want to.

The reason for the MDX syntax I do understand, as the new formulas allows you to point to multiple hierarchies in the same dimension, and the syntax points to the [dimension].[Hierarchy].[Member]. However, it would be simpler if users could do the same as we can in rules and processes in TM1, where it is simply dimension:element and dimention:hierarchy:element for alternative hierarchies. Less syntax, simpler to understand.

The flexibility we get is great, but the implementation is to complex. 

------------------------------
Emil Malmberg Fosdal
Solution Architect
CogniTech A/S

Original Message:
Sent: Tue April 23, 2024 02:46 PM
From: Ryan Clapp
Subject: TM1Val Design Questions

Why was TM1Val designed the way it was? We are exploring UniversalReports as a potential solution for our reporting needs and are finding the new formula cumbersome to implement, especially when moving from DBRWs. I am struggling to explain to our users why the new formula is such a departure from the old one. Why was it built like this? Before universal reports are broadly adopted these issues should be addressed. 

• It requires 3 "name/location" parameters, URI, server, and cube; why? This is difficult for average report developers to keep track of and not a huge value add. Most finance users don't know the URI is and don't care to. Why not just a sever prefixed cube name like before (or the ability to easily alias them in the connections settings)
• Requires MDX syntax for element references. Why should report developers need to use MDX syntax to get a cell value? Couldn't it just use colon like rules syntax does?
• Why is it overloaded with a mode selector? Can we just have 3 functions (Tm1Val, Tm1ValWrite, Tm1ValClear). Overloaded functions make the behavior not obvious. Function overloading can lead to more error prone code.

I would appreciate insight anyone can share

------------------------------
Ryan Clapp
------------------------------