After years of developing planning solutions with SAP BW Integrated Planning and BPC, I recently completed a SAC Planning project with seamless planning. Coming from a BW IP/BPC background, I initially tried to replicate familiar structures in SAC. But I quickly realized that SAC’s flexibility requires a different mindset, starting with model design and granularity.
In this first blog post, I’ll share model design decisions, and practical tips for BW developers moving to SAC Planning. This blog post shall also help developers without BW background by highlighting the restrictions of certain functionalities in SAC. Finally, I also want to show you the potential additional value of seamless planning for your planning project.
1. SAC vs. SAP BW modelling: general background information
In SAC, the new model is a mixture of InfoCube-like and a direct-update planning ADSO in BW. All characteristics are keys (InfoCube-like), but there is only an active table (direct-update). Furthermore, measures in SAC models cannot be of a text/characteristic type. So,
there are no requests, no chance to roll backno inherited delta mechanismno characteristic as key figure.
But SAC models come with a Standard data audit functionality, that works out of the box (except for import jobs). Because of the missing requests in SAC, planning functions should be kept simple.
2. Model Design: SAC is not BW
When designing planning solutions in SAC, I recommend you to break down planning requirements across multiple models. In SAP BW, developers were required to create composite providers and aggregation levels (and input enabled queries) on top of ADSOs to structure planning logic. SAC does not have those intermediate layers, which can accelerate development. But this simplicity also introduces challenges when trying to consolidate everything into a single model.
Here are a few examples:
Any data entry creates an edit version. If multiple planning scenarios share one model, SAC shows the “Publish Data” banner across all stories when you edit plan data in one story.
The SAC Excel Add-In allows end users to plan on ad-hoc created tables, which can be convenient for flexibility. However, this becomes significantly more critical when SAC models are large and complex. In such cases, ad-hoc planning can bypass frontend validations (for instance, javascript logic in stories), leading to inconsistencies and governance challenges (check comments here Ability to disable planning option in SAC Cloud excel add-in centrally by admin).Upload jobs in SAC cannot derive master data automatically. In huge models, this often leads to wide files with many columns.Data validations are less robust than characteristic relationships in BW. They must be handled manually in Data Actions and carefully considered during story design, since SAC still allows “unassigned” values even when validations are defined.Data point comments are more fragile. Because they depend on the full navigation state, they can be lost more easily in huge models.
These limitations highlight the need to rethink model design. Instead of treating an SAC planning model like a BW ADSO, it’s more accurate to compare it to an aggregation level or even an input enabled query. It’s a layer tailored to specific planning logic.
3. How does seamless planning help?
Seamless planning let’s you expose your fact and dimension tables to Datasphere. Hence, you can bring together the data of your different models more easily for reporting purposes instead of having a lot of cross model copies in native SAC.
You can also
add SQLscript logic,enrich your plan data with Datasphere tables for configuration/customizing (multiple keys and characteristics as non-key fields),or leveraging public dimensions exposed from SAC (single key).
The results can be consumed
via real-time reporting (Datasphere Analytic Models)or via import jobs to SAC models.
4. What’s next?
With the Q4/2025 update, seamless planning shall become bidirectional, meaning that the View data in Datasphere can be added to SAC models as read-only version. This update will make Datasphere data better accessible. It will support direct consumption of Datasphere fact data in planning models, which will let you have a single planning enabled table with real-time reference data from other planning models.
Summary
Model design matters: Avoid putting all planning scenarios into one model. SAC lacks BW’s aggregation layer, so splitting models improves performance and governance. Seamless Planning currently focuses on exposing SAC fact and dimension tables to SAP Datasphere, enabling integrated reporting and SQLScript-based logic. It will help you implementing a federated planning landscape in SAC.Always keep the Roadmap in mind: By Q4/2025, SAC will support direct consumption of Datasphere fact data in planning models, reducing reliance on import jobs and enabling real-time integration in planning enabled crosstabs.
After years of developing planning solutions with SAP BW Integrated Planning and BPC, I recently completed a SAC Planning project with seamless planning. Coming from a BW IP/BPC background, I initially tried to replicate familiar structures in SAC. But I quickly realized that SAC’s flexibility requires a different mindset, starting with model design and granularity.In this first blog post, I’ll share model design decisions, and practical tips for BW developers moving to SAC Planning. This blog post shall also help developers without BW background by highlighting the restrictions of certain functionalities in SAC. Finally, I also want to show you the potential additional value of seamless planning for your planning project.1. SAC vs. SAP BW modelling: general background informationIn SAC, the new model is a mixture of InfoCube-like and a direct-update planning ADSO in BW. All characteristics are keys (InfoCube-like), but there is only an active table (direct-update). Furthermore, measures in SAC models cannot be of a text/characteristic type. So,there are no requests, no chance to roll backno inherited delta mechanismno characteristic as key figure.But SAC models come with a Standard data audit functionality, that works out of the box (except for import jobs). Because of the missing requests in SAC, planning functions should be kept simple.2. Model Design: SAC is not BWWhen designing planning solutions in SAC, I recommend you to break down planning requirements across multiple models. In SAP BW, developers were required to create composite providers and aggregation levels (and input enabled queries) on top of ADSOs to structure planning logic. SAC does not have those intermediate layers, which can accelerate development. But this simplicity also introduces challenges when trying to consolidate everything into a single model.Here are a few examples:Any data entry creates an edit version. If multiple planning scenarios share one model, SAC shows the “Publish Data” banner across all stories when you edit plan data in one story.The SAC Excel Add-In allows end users to plan on ad-hoc created tables, which can be convenient for flexibility. However, this becomes significantly more critical when SAC models are large and complex. In such cases, ad-hoc planning can bypass frontend validations (for instance, javascript logic in stories), leading to inconsistencies and governance challenges (check comments here Ability to disable planning option in SAC Cloud excel add-in centrally by admin).Upload jobs in SAC cannot derive master data automatically. In huge models, this often leads to wide files with many columns.Data validations are less robust than characteristic relationships in BW. They must be handled manually in Data Actions and carefully considered during story design, since SAC still allows “unassigned” values even when validations are defined.Data point comments are more fragile. Because they depend on the full navigation state, they can be lost more easily in huge models.These limitations highlight the need to rethink model design. Instead of treating an SAC planning model like a BW ADSO, it’s more accurate to compare it to an aggregation level or even an input enabled query. It’s a layer tailored to specific planning logic.3. How does seamless planning help?Seamless planning let’s you expose your fact and dimension tables to Datasphere. Hence, you can bring together the data of your different models more easily for reporting purposes instead of having a lot of cross model copies in native SAC.You can alsoadd SQLscript logic,enrich your plan data with Datasphere tables for configuration/customizing (multiple keys and characteristics as non-key fields),or leveraging public dimensions exposed from SAC (single key).The results can be consumedvia real-time reporting (Datasphere Analytic Models)or via import jobs to SAC models.4. What’s next?With the Q4/2025 update, seamless planning shall become bidirectional, meaning that the View data in Datasphere can be added to SAC models as read-only version. This update will make Datasphere data better accessible. It will support direct consumption of Datasphere fact data in planning models, which will let you have a single planning enabled table with real-time reference data from other planning models.SummaryModel design matters: Avoid putting all planning scenarios into one model. SAC lacks BW’s aggregation layer, so splitting models improves performance and governance. Seamless Planning currently focuses on exposing SAC fact and dimension tables to SAP Datasphere, enabling integrated reporting and SQLScript-based logic. It will help you implementing a federated planning landscape in SAC.Always keep the Roadmap in mind: By Q4/2025, SAC will support direct consumption of Datasphere fact data in planning models, reducing reliance on import jobs and enabling real-time integration in planning enabled crosstabs. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
