In SAP Analytics Cloud (SAC) Planning, the version dimension is mandatory and unfortunately private. The private nature of the version dimension contradicts the recommendation I gave in an earlier blog post (use of multiple models) but nontheless there are significant reasons to stay with the version dimension as designed. This requires version members to be defined separately in each planning model. It makes early alignment on required versions essential in a SAC planning project. Furthermore, I want to highlight the version dimensions importance in context of the seamless planning roadmap and customer influence opportunities.
1. Why the Version Dimension Matters in SAC Planning
While some recommendations suggest simplifying the model by using a single version member and managing versions via a custom public dimension, I would not recommend this approach. SAC offers several reasons to use the version dimension as intended:
Strong frontend support: SAC provides clear visual indicators for version editing by hitting the advanced button before publishing
Private versions: Using the native version dimension ensures consistent handling of version management capabilities in SAC, including the opportunity to create private versions on the fly to plan different scenarios.Roadmap alignment: SAP’s Seamless Planning roadmap shows continued investment in the version dimension, confirming its strategic importance in future planning capabilities. Building your planning landscape in SAC assuming there is only one version dimension member will create problems when trying to adopt the newest seamless planning features. Check the new blog post of @Max_Gander (Unlocking the Next Chapter of Seamless Planning in… – SAP Community).
For these reasons, it’s advisable to define all necessary version members upfront and use the version dimension as designed.
2. Limitations of the Version Dimension in SAC Reporting
Besides the private nature of the version dimension there are other limitations.
For instance, when you try to use the data analyzer on top of a planning model, SAC forces you to either add the version to the drill or set a single member filter:
The “New Table Building Experience” introduced flexibility regarding the version dimension and measures (The New Table Building Experience in SAP Analytics… – SAP Community) in Story Building. But the new experience still has certain restrictions (Restrictions for the New Table Build Experience | SAP Help Portal)The concept of a version dimension is not applied to analytic models in Datasphere. When you are using seamless planning you can bypass the restrictions in reporting regarding versions by defining an analytic model in Datasphere. But there are some widget features that only work with a version dimension, so this is also not a perfect solution.
3. Limitations of the Version Dimension in SAC Planning
When you try to build input enabled layouts in SAC planning, you will be confronted with limitations regarding the version dimension. I will share one use case to show the problem in detail:
SAC has this great “Forecast Layout” for planning. Unfortunately, the sum for the year value is not input enabled (see the green box). So, I tried to build a second input enabled table, that allows total values to be planned (see red box), beginning with the planning of the rest of the year:
Layout:
Calculation Editor “Rest of Year Forecast”:
As you can see, the input on the “Rest of Year Forecast” measure works as expected.
But the expectation is to plan the total year value including the YTD Actuals and here the limitation of the version dimension becomes problematic. Since I have to remove the filter in the table widget for the Version, everything becomes read-only:
Layout Forecast and Actuals:
Calculation Editor Forecast with Actuals:
The use of the new experience, or the use of cross calculations does not help to solve the requirement to plan on a measure, that inherits two or more versions, although the inverse formula points to a specific version. I found a solution with constant selection (which I find problematic) and I just hope, that the flexibility with the version dimension will be enhanced in the future. Especially, with the new possibilities of seamless planning coming with the next release, this would be a great enhancement. Data federation in planning is only possible, when the input layouts can be designed in a flexible way. Otherwise, it will be required to copy/paste the data across the planning landscape.
Key Takeaways
Although the version dimension comes with restrictions, I would advise you to use it as intended. To further support consistency across models, consider supporting the customer influence to enable Version as Public Dimension in SAC.Restrictions in the data analyzer regarding versions will become more problematic with the new seamless planning release. Please comment, if you find a customer influence. I would definitely support it!Restrictions in input enabled crosstabs regarding the version dimension are an obstacle when trying to build a federeated planning landscape. Consider supporting the customer influence to allow inverse formulas on measures with different versions. If I missed a simple trick, please comment and I will update this blog post.
In SAP Analytics Cloud (SAC) Planning, the version dimension is mandatory and unfortunately private. The private nature of the version dimension contradicts the recommendation I gave in an earlier blog post (use of multiple models) but nontheless there are significant reasons to stay with the version dimension as designed. This requires version members to be defined separately in each planning model. It makes early alignment on required versions essential in a SAC planning project. Furthermore, I want to highlight the version dimensions importance in context of the seamless planning roadmap and customer influence opportunities. 1. Why the Version Dimension Matters in SAC PlanningWhile some recommendations suggest simplifying the model by using a single version member and managing versions via a custom public dimension, I would not recommend this approach. SAC offers several reasons to use the version dimension as intended:Strong frontend support: SAC provides clear visual indicators for version editing by hitting the advanced button before publishingPrivate versions: Using the native version dimension ensures consistent handling of version management capabilities in SAC, including the opportunity to create private versions on the fly to plan different scenarios.Roadmap alignment: SAP’s Seamless Planning roadmap shows continued investment in the version dimension, confirming its strategic importance in future planning capabilities. Building your planning landscape in SAC assuming there is only one version dimension member will create problems when trying to adopt the newest seamless planning features. Check the new blog post of @Max_Gander (Unlocking the Next Chapter of Seamless Planning in… – SAP Community).For these reasons, it’s advisable to define all necessary version members upfront and use the version dimension as designed.2. Limitations of the Version Dimension in SAC ReportingBesides the private nature of the version dimension there are other limitations.For instance, when you try to use the data analyzer on top of a planning model, SAC forces you to either add the version to the drill or set a single member filter:The “New Table Building Experience” introduced flexibility regarding the version dimension and measures (The New Table Building Experience in SAP Analytics… – SAP Community) in Story Building. But the new experience still has certain restrictions (Restrictions for the New Table Build Experience | SAP Help Portal)The concept of a version dimension is not applied to analytic models in Datasphere. When you are using seamless planning you can bypass the restrictions in reporting regarding versions by defining an analytic model in Datasphere. But there are some widget features that only work with a version dimension, so this is also not a perfect solution.3. Limitations of the Version Dimension in SAC PlanningWhen you try to build input enabled layouts in SAC planning, you will be confronted with limitations regarding the version dimension. I will share one use case to show the problem in detail:SAC has this great “Forecast Layout” for planning. Unfortunately, the sum for the year value is not input enabled (see the green box). So, I tried to build a second input enabled table, that allows total values to be planned (see red box), beginning with the planning of the rest of the year:Layout:Calculation Editor “Rest of Year Forecast”:As you can see, the input on the “Rest of Year Forecast” measure works as expected.But the expectation is to plan the total year value including the YTD Actuals and here the limitation of the version dimension becomes problematic. Since I have to remove the filter in the table widget for the Version, everything becomes read-only:Layout Forecast and Actuals:Calculation Editor Forecast with Actuals:The use of the new experience, or the use of cross calculations does not help to solve the requirement to plan on a measure, that inherits two or more versions, although the inverse formula points to a specific version. I found a solution with constant selection (which I find problematic) and I just hope, that the flexibility with the version dimension will be enhanced in the future. Especially, with the new possibilities of seamless planning coming with the next release, this would be a great enhancement. Data federation in planning is only possible, when the input layouts can be designed in a flexible way. Otherwise, it will be required to copy/paste the data across the planning landscape.Key TakeawaysAlthough the version dimension comes with restrictions, I would advise you to use it as intended. To further support consistency across models, consider supporting the customer influence to enable Version as Public Dimension in SAC.Restrictions in the data analyzer regarding versions will become more problematic with the new seamless planning release. Please comment, if you find a customer influence. I would definitely support it!Restrictions in input enabled crosstabs regarding the version dimension are an obstacle when trying to build a federeated planning landscape. Consider supporting the customer influence to allow inverse formulas on measures with different versions. If I missed a simple trick, please comment and I will update this blog post. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
