Moved to here: https://community.ibm.com/community/user/businessanalytics/discussion/tm1val-design-questions-1?ReturnUrl=%2fcommunity%2fuser%2fbusinessanalytics%2fcommunities%2fcommunity-home%2fdigestviewer%3fListKey%3d24e1ec12-c4ef-4dde-bcb7-6b5ea09a9fa8%26CommunityKey%3d8fde0600-e22b-4178-acf5-bf4eda43146b
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 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 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 appreciated insight anyone can share
------------------------------
Ryan Clapp
------------------------------