Introduction
Since its introduction of the planning area nearly two and half years ago, customers have greatly benefitted from the improved performance during planning activities. The planning area is defined as the cross product of dimension filters that are included in its definition and can generally take Data Locking and Data Access Control (DAC) into consideration. From a planner’s perspective, the planning area represents the editable data slice that is plannable data in a working session, which should be much smaller than the complete version. Generally, the smaller the planning area, the more performant the planning activity will be from a time and system resource perspective. Since its initial introduction, we have introduced several enhancements to the planning area as well that remain viable planning area optimization strategies.
With the QRC2.2024 release, we now allow dynamic planning area extensions when planning in a table is configured with the ‘Auto-generate based on the table context’ option. This capability, when combined with the auto generate based on table context planning area default optimization strategy, provides a more optimal experience that requires no expertise on the part of the planner to leverage. From the planner’s perspective, they can simply start working directly in a table to progress through their data entry workflows and the planning area will be automatically generated based on the planning context allowing them to change table filters and plan across many tables without having to actively manage their planning areas.
Fortunately, to enable this planning capability is easy.
Model Configuration
The configuration for the planning area can now be found under the “Planning” section (i.e Model-> Preferences).The planning area is automatically enabled for planning models and the model designer can select to take data locking and DAC into consideration, which are highly recommended to reduce the potential size of the planning area. If the model designer selects the Set ‘Auto-generate based on table context’ as Default’ toggle, it will make it exceptionally easy for the story designer to take advantage of this feature as it will be the default setting. We believe this strategy will be ideal for most planning scenarios.
As the planning area performance parameter is configurable, we will now see a warning message when entered threshold exceed 50 million records. Working with large planning areas can consume excessive resources that may affect your colleagues planning experience, so we encourage customers to aggressively keep this number as low as practical to encourage planners to create small planning areas. To protect the overall planning experience when working with planning areas, we have introduced a guardrail of 100 million records to safeguard the planning experience during data entry activities. Currently, data/multi-actions do not provide checks against this guardrail as part of the execution. In general, the smaller the planning area, the better the planning experience.
Story Configuration
There are two ways that the planning area is controlled in story tables:
- With option "auto-generate based on table context"
- the planning area can be extended at a later point in time to cover additional members, such as changing the table filters during data entry workflows
- the SAC frontend manages necessary extensions automatically by showing also cells outside the current planning area as input-ready, and by triggering dynamic extensions of the planning area when needed. Note that the dynamic extension of the planning area is done based on the complete table context and not per individual cell that is being changed.
- Without option "auto-generate based on table context"
- the planning area is statically defined when a public edit is started, and can not be extended when planning in the table
- cells showing values that are fully or partially outside the planning area are marked as not input-ready
Although the default setting for this table configuration can be set in the modeler, it can be overwritten in the story. For the planner, having this setting enabled for planning allows the planning area definition to dynamically extend to create an exceptional planning experience.
Example
Perhaps the best way to understand the enhancement is step through an example in detail. For this scenario, we are going to set the ‘Auto-generate based on table context’ toggle off in the story. We will create a a custom planning area and select the German Bike Co. as the filter for the company code. As we progress through the basic workflow, we will see how this configuration setting in the story will extend the planning area scope automatically.
Step 1: De-select the ‘Auto-generate based on table context’ option for the table in the builder panel.
Step 2: Create a custom planning area and limit the planning area to the company code for German Bike Co. Notice in the version management details, we can see this filter applied to the planning area.
Step 3: If we increase Net Revenue by 5%, we see there are no changes to the planning area scope/size as expected.
Step 4: When we change the company code filter to the US Bike C., we see that the values for Plan are not input enabled, even though we have DAC write access for these values and data locking has not been applied to this company code.
This is the expected behavior as we have not enabled the auto-generate toggle in the table design for the story. The US Bike Co. was not part of the initial planning area configuration and is not extendable based on the table configuration setting.
Step 5: Select the ‘Auto-generate based on table context’ option for the table in the builder panel
Step 6: We now see that the plan values are input enabled for the US Bike Co. As we have not performed any additional data entry in the table, the planning area definition does not yet include the US Bike Co.
Step 7: If we increase Net Revenue by 5%, we see the planning area scope/size has changed and now includes the US Bike Co. as a filter for company code.
Using Version History, we can see where the dynamic extension occurred and can navigate our planning session to earlier steps as per existing capabilities
Step 8: From the version management history panel, we can rollback changes prior to the dynamic extension (i.e. Extend Planning Area step) to provide additional planning flexibility.
Conclusion
From this example, we see that the dynamic expansion provided by this enhancement to the ‘Auto generate based on the table context’ greatly simplifies planning. Using the table context, for this type of planning scenario we can design planning areas based on the table configuration to be relatively small to provide a more optimal planning performance. However. We can still provide the planner with flexibility to extend the planning area automatically to minimize disruptions to their planning experience, such as when table filters are changed. This strategy will also enable the planner to plan across multiple tables where this setting has been applied on it without needing to actively manage their planning area scope.
FAQs
1. How do I know if a dynamic extension has occurred to the planning area?
- The History tab of the version management will indicate where this activity has occurred.
- However, this activity is transparent to the planner and unlikely critical to their daily workflows.
2. What do you mean that a planning area is a cartesian product of dimension filters?
- Example: If your planning area starts with (Company Code: German Bike Co, Time: 2024), and you extend it to also include (Company Code: US Bike Co., Time: 2023), the planning area will then extended to:
- (Company Code: German Bike Co, Time: 2024), (Company Code: US Bike Co., Time: 2024), (Company Code: German Bike Co, Time: 2023), (Company Code: US Bike Co., Time: 2023)
3. Why is a particular dimension not filtered at all by the planning area?
- a dimension filter (after hierarchy expansion) contains too many members, which would cause performance degradation when the filter is applied at query time.
- a dimension filter refers to all members of a dimension and is therefore useless.
- The system may discard filters, in order to improve the query performance or to avoid runtime errors due to planning attempts outside the planning area
- Examples why this may occur
- a dimension filter derived from Data Locking and/or Data Access Control is directly or indirectly blocking planning on a cell
4. Why does a particular member that is locked by Data Locking still end up inside the planning area?
- The filter derived from Data Locking is a cross-product of independent dimension filters.
- Therefore, if e.g. there is at least one member combination for which a Location member Europe (e.g. for Date January 2024) is open, the Location member Europe is not filtered out of the planning area
- This is the case even when another filter, (e.g. derived from the visible table context) excludes January 2024
5. Why is Data Access Control (DAC) not always respected for input readiness when dynamic extensions of the planning area are enabled?
- Supporting input readiness for DAC is on our product roadmap and will be delivered soon
6. Do dynamic extension of the planning area discussed in this blog post apply to data actions?
- Currently, this guardrail does not extend to the data/multi actions,
- Dynamic extensions of the planning area for data actions will be addressed as part of our product roadmap and is expected to be delivered soon.
7. Is this feature available in the SAC Excel Add-In?
- This feature is expected to be added to the product roadmap in the near future
8. Will the dynamic extension of the planning area work for private versions (i.e. explicit private versions)?
- We are not currently planning on adding this capability to private versions.
- SAP Managed Tags:
2 Comments
