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.
Hello folks, Does anyone know how to work around the Polaris limitation of using the Formula or Ratio summary method alongside the Closing Balance within the same line item? I have a Business Unit list where the total (All BUs) must display the Corporate (1 of 20 leaf items under All BUs total) number of Unique Customers.…
Has anyone found success using Anaplan XL with Polaris models in a shared drive with or without concurrent users? My team has experienced a variety of errors, login failures, etc. sometimes it works, sometimes it doesn't. We've been recommended to save and edit files locally, which helps but certainly with its limitations…
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.…
