"Rule 1.02-02": Article 1, Chapter 2, and Rule 2” Do not use formulas in the version settings. Whilst this is a simple construct and it might be OK for simple models; it effectively adds size to models every time versions are used in a module even if you don't want the variance. Also, in modules with 3 or more dimensions if you have calculation line items and aggregations the results may not always be accurate; you cannot amend the summary method for a version formula within the versions setting. It goes against PERFORMANCE elements of PLANS if you wish to go against this rule
Use Case: To see the variance between Actuals and Forecast Numbers
Here is how it was done in Pre Planual Era. We used to add third version called Variance in the Version Page of the model and write the formula within the formula bar
What is wrong with this method? Although it is the easiest way of calculating the variance but it is definitely NOT the best way. Problem with this approach is that every time you use version as a dimension Variance will be accompanied with other versions even if you don’t want to see that Version ( Anaplan doesn’t have Version Subsets). Also each version is treated as a separate block and is not equal to any list item addition which increased the size drastically.
Here is how it should be done in Planual Way: There are many ways to calculate the variance between two versions. Here is one such way where I am using only Two Native Dimensions i.e., Actual and Forecast in Source Module
Create a Target module without Versions as a dimension and bring the Actual & Forecast Values into their respective Line items. You can use SELECT Statements to pull the values. .
Interested to hear ideas from Community Members how would you deal with the comparison of multiple Real Versions? The example above is very simple and straightforward.
Let's say we have Actuals, Forecast, and 3 budget rounds, adding new Version (e.g. new Budget round) Users cannot see the variance, without Model Builder help to add new line item, write formula, calculate Variance.
While working with Dummy Versions, this is very easy, you can let Users choose two Versions they want to compare and use LOOKUP.
For Real Versions I would usually do line items Current Version, Previous Version (PREVIOUSVERSION(Current Version)), Variance, but analysis is still limited then to Current and Previous Version.
I completely understand what you mean to say & I agree with you that is simple & straightforward. But here the intention was to explain the rule and be precise and succinct about it & not venture about other version related topics
Well, 100% agreed that normally the decision is taken at the design phase based on the requirements. If more detailed and flexible comparison is needed, dummy versions is the way to go.
Imagine that you have model with real versions which was built and designed this way based on requirements, but after year or two of using it, the client actually wants to add more of versions and be able to do the comparison reports. Therefore the question. Changing real versions to dummy versions would be a pain, but maybe some people have nice example of more detailed comparisons with real versions.