Mapping Native Versions to a Versions List
Is there an elegant way to map native versions to a versions list?
I know we cant use SUM as this will only recognise and map the 'current version'.
Therefore, is there another way?
Answers
-
Use the first part of this article (create a module with line items doing the SELECT's to the Native Versions, then create a LISS and map those to the Custom versions).
0 -
Thanks Rob -
Interestingly I came to the same conclusion after a long walk. The only exception I have is that the native versions will be recycled and will change name so I need an easier way to repoint my native versions item to a different list item in my versions list. Having to update the SELECT each time seems too cumbersome.
My thoughts are to map native versions to a second general list (Version1, 2, 3 etc ) this mapping will always stay the same. We then map these to my version list in a system module where we can choose where to point the native version to in our version list. . That way when a version is changed I can simply update the intermediate mapping rather than changing the SELECT references.
What are your thoughts?
0 -
Are they changing the name or adding to/removing the Native Versions? If so, you should still be good. If adding/removing native versions, that would be a structural change, meaning it has to be done in DEV and sync'd to Prod (assuming ALM is in play). When this happens, have a "manual" process of changing the "selects".
0 -
@rob_marshall - when you say "manual" what do you mean? if there's a better way than having to remember to update the selects that would be rather nifty or is it the means that @ChrisAHeathcote touches on with his intermediate mapping step?
0 -
@rob_marshall we shouldnt be adding new native versions but rather recycling those that are pre-existing. This way I can map native versions to a intermediate list (Actuals, Version 1, Version 2 etc ) and then use a mapping table dimension by my target list to assign which list item in my intermediate list that target list should LOOKUP.
This should work well for my current use case.
As we recycle the native version my users will just have to update the mapping table to reassign the target LOOKUP rather than having to change SELECT references.
0 -
When I say "manual" I meant they would have to adjust it in DEV and then sync…That was under the assumption Chris/client was creating a new version and therefore they would need to "create" the Select statement for that new version. With that said, Chris has since come back and said they wouldn't be doing that.
I have another idea, although what you have in place and what that article states will work just fine. When the user is remapping the custom versions to the select statements, is there a pattern? I am thinking you can put the very seldomly used "code" in for the select statements (code of the Custom Versions) and then use a finditem() for the mapping, therefore there would be no manual intervention.
0
