RFE 82432-Picklists based on Subset to have an option to display an Alias but return Principal Name
Posted: Tue Jan 12, 2016 5:42 pm
I think many who use picklist will agree that not have a code/description style picklist is a major issue when you expect users to pick values from a list of codes that may be IDs or other generated references.
I have loaded RFE 82432 to request that we basically be allowed to use syntax like: subset:<dimension>:<subset>:<alias> to do this. Please go and vote for this!
What would be really cool if you use Picklist cubes is to have subset:<dimension>:<MDX>:<alias> as you could then code the MDX within the Picklist cube. This would be useful if for instance you select an option and the MDX brings back a filtered set based on the option e.g. you have a table with account and countries. When a particular country is selected, the MDX would be written to filter and return the countries that are valid. Let me know if you think this option is useful and depending on the responses, I will request it too.
Thanks for your vote.
For those who do not have access to view the RFE, this is what it says:
Description
When assigning a subset based Picklist to a measure, the picklist is linked to a named subset. Based on the elements in the subset, the selected value is stored in the cube. Depending on the subset, this may be the PrincipalName or may be an Alias.
From a user's point of view however, a list of IDs is meaningless and they require a view of a human readable list, normally an alias.
Ideally you want to store the PrincipalName of the element rather than an alias which may change over time.
Use Case
A model contains a dimension with transaction codes from the line of business system. A mapping table is required to map the incoming transaction codes to a reporting transaction code.
A subset has been created on a dimension where the source system transaction codes reside and this is linked to the picklist.
Users updating the mapping table are faced with a list of IDs and need to refer to another sheet or table to find the correct value.
Picklists should work just like any other combo box environment where you can show a code and description, let the user select and bring back the code (PrincipalName) into the cube.
Business Justification
Not having the ability to see the descirption or an alias wastes time, is prone to error and to some users is more of a hinderance.
With 3rd party integration, you run the risk of sending mal-formed data as you may be sending an element with a description which the receiving system cannot handle or does not expect. This can lead to exception reports and increases operational risk.
Data integrity is at the core of any system and without this feature, the use of subset based picklists puts this in jeopardy.
Having the ability to specify an alias e.g.
subset:<dimension>:<subset>:<alias>
would make the picklist more functional, reduce time waste, protect data integrity and make TM1 more user friendly.
I have loaded RFE 82432 to request that we basically be allowed to use syntax like: subset:<dimension>:<subset>:<alias> to do this. Please go and vote for this!
What would be really cool if you use Picklist cubes is to have subset:<dimension>:<MDX>:<alias> as you could then code the MDX within the Picklist cube. This would be useful if for instance you select an option and the MDX brings back a filtered set based on the option e.g. you have a table with account and countries. When a particular country is selected, the MDX would be written to filter and return the countries that are valid. Let me know if you think this option is useful and depending on the responses, I will request it too.
Thanks for your vote.
For those who do not have access to view the RFE, this is what it says:
Description
When assigning a subset based Picklist to a measure, the picklist is linked to a named subset. Based on the elements in the subset, the selected value is stored in the cube. Depending on the subset, this may be the PrincipalName or may be an Alias.
From a user's point of view however, a list of IDs is meaningless and they require a view of a human readable list, normally an alias.
Ideally you want to store the PrincipalName of the element rather than an alias which may change over time.
Use Case
A model contains a dimension with transaction codes from the line of business system. A mapping table is required to map the incoming transaction codes to a reporting transaction code.
A subset has been created on a dimension where the source system transaction codes reside and this is linked to the picklist.
Users updating the mapping table are faced with a list of IDs and need to refer to another sheet or table to find the correct value.
Picklists should work just like any other combo box environment where you can show a code and description, let the user select and bring back the code (PrincipalName) into the cube.
Business Justification
Not having the ability to see the descirption or an alias wastes time, is prone to error and to some users is more of a hinderance.
With 3rd party integration, you run the risk of sending mal-formed data as you may be sending an element with a description which the receiving system cannot handle or does not expect. This can lead to exception reports and increases operational risk.
Data integrity is at the core of any system and without this feature, the use of subset based picklists puts this in jeopardy.
Having the ability to specify an alias e.g.
subset:<dimension>:<subset>:<alias>
would make the picklist more functional, reduce time waste, protect data integrity and make TM1 more user friendly.