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?
@ChrisAHeathcote
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).
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?
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".
@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?
@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.
@andrewtye
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.
Hi Community, I’m encountering an issue where an export created in Anaplan is missing column headers when retrieved via the API. However, when I manually run the same export from the Actions tab, the downloaded file includes the headers. Has anyone experienced this behavior before? I’d appreciate any insights into the root…
We are looking for Anaplan end-users to provide feedback on their experiences with the Excel add-in. Interested individuals will respond to this 5-minute survey to help us understand personal needs and behavior when using the add-in. The feedback provided by survey takers is essential to the roadmap of Anaplan's products.…
Anaplan Champions! The Community team just posted this announcement that certification badges may not be showing up on your profile probably until next year. Rest assured, you will get credit once you complete and pass the exams. https://community.anaplan.com/t5/Blog/Badges-Back-Soon/ba-p/123385
