Learn About Planning Model Data
When you’re planning in SAP Analytics Cloud, you’ll usually work with data from a planning model. Read on to get familiar with this type of model.
Types of Models
When a model is created, the modeler chooses whether it’s an analytic model or a planning model.
Analytic models don’t allow planning operations like data entry and version management. To support these features, planning models have more structure including a planning date dimension and a version dimension. For details, see Learn About Models.
Updating Planning Data
Manual Data Entry
As a planning user, you’ll often work in stories or analytic applications. A variety of planning tools are available, but the simplest changes involve entering values manually in a table. Tables show which cells are booked (that is, not empty) and which ones you can change with planning operations.
Tables also give you an entry point for version management. Through the version dimension, you can work with multiple versions of the data that could reflect different categories (such as actual and plan), different scenarios (pessimistic and optimistic), and different periods (Q1 forecast and Q2 forecast).
Structured Planning
As well as manual data entry, most planning processes involve structured planning operations like data actions, multi actions, and allocation processes. These are created in advance by modelers to reflect your organization's business rules and to automate repetitive parts of the planning process. You can run them to make a set of changes to the model data all at once. For more information, refer to Run Data Actions, Multi Actions, and Allocations.
How Planning Models Store Data
Most planning models are import data models. Unlike live data models, your source data is copied into SAP Analytics Cloud so that you and your team can adjust it during planning tasks. (One exception is live data connections to SAP BPC embedded.)
Planning models store data at the lowest levels of each dimension hierarchy, known as the leaf level. A model's data foundation is made up of a row of data for each combination of leaf dimension members. Each table cell usually represents data from many of these rows.
Parent members only show the aggregated values of their children, and generally don't contain values on their own.
You can book values directly to leaf members, or to parent members. For data entry on parent members, the system automatically disaggregates your data to leaf members. For details, see Disaggregation of Values During Data Entry.
Unassigned Data
By default, dimensions in planning models usually have an unassigned member with the number sign (#) as its ID. It's always a leaf member. You can store data in this member if you don’t want to distribute it among the other dimension members.
For example, if you're planning capital expenses but don't want to decide which locations will receive the new equipment yet, you can book the data to the unassigned member for the organization dimension.
Some dimensions like account, version, and date don’t have an unassigned member, because all of your data needs to be explicitly assigned to one of the dimension members.
Publishing Your Changes
In some cases, the data can then be exported back to a source system like SAP BPC, SAP Integrated Business Planning, or SAP S/4 HANA. Or in a live data connection to SAP BPC embedded, you can plan with live data and publish your changes directly to the data source.
Types of Planning Models
SAP Analytics Cloud currently supports two types of import data models for planning: a classic account model and a new model type with measures.
The main difference is that the new model type can have multiple measure values for each row of model data. Classic account models have a single measure. Because of this, the new model type offers some different configuration options. For details, see Get Started with the New Model Type.
For planning on models with measures, take note of the following points:
Account Dimensions in Models with Measures
Account dimensions are optional in planning models with measures. This is because each measure sets many of the same properties of an account dimension member, such as aggregation, scale, units, and whether there are currency values or not. For background information about different model configurations, see Choosing a Model Configuration.
Limits on Value Ranges and Decimal Places for Measures
| Data Type | Value Range | Decimal Places |
|---|---|---|
| Integer | Between -2^31 to 2^31 (that is, 2,147,483,647) | None |
| Decimal | Up to 15 digits, including decimal places | Up to seven |
In tables, data entry and copy and paste operations can't exceed a measure's value range or number of decimal places.
When using the planning panel or creating data actions, messages will also let you know about changes in data types across different measures.
Copying Across Measures in Data Actions
In a model with measures, you can use data actions to copy data from a source measure to a target measure. You should keep the data types of these measures in mind to avoid unexpected results.
When creating data action steps, a warning will show up if your source measure has a greater value range or more decimal places than one of the targets. For example, if you copy a decimal measure to an integer, the decimals will be rounded off. If a value range is exceeded, the data action won't be able to run.
Keep this in mind if you’re copying measures using parameters, too. For example, if you’re copying a decimal to a measure parameter with any data type, no warning shows up when you’re creating the data action, but a user might select an integer measure when running the data action. This could result in decimal place data being discarded during the copy step, or in the data action failing if source values exceed the integer value range.
When using measure parameters for source or target members, it’s recommended to define them with specific data types to avoid this case.
For details about parameters, see Add Parameters to Your Data Actions and Multi Actions.
Treatment of Measures from the Same Set of Dimension Members
In some cases when figuring out whether a value has changed or remained the same, the software doesn’t distinguish between different measures for a specific set of leaf members.
This happens because models with measures store the values for each measure on the same row in the fact table. (Each row is associated with a combination of leaf members from all dimensions.)
This issue occurs in the following situations:
-
When you enter data for two measures that belong to the same set of leaf members, a message appears showing that one database record was changed.
-
When data locks are applied with measures as a driving dimension, this issue affects importing or deleting values in the modeler. For any set of dimension members with a mix of locked and unlocked measure values, you won’t be able to change any of the measure values by importing or deleting data in the modeler. (Appending unbooked values to these measures is allowed, since it doesn’t change the data.) For details about data locking, see Set Up Data Locking.
-
When you copy a public version and publish the resulting private version to a different public version, you can choose to only publish the changed dimension combinations (Publish member combinations with changed data). In this case, all measures will be published for each set of leaf members where any measure was changed. For details, see Create, Publish, and Manage Versions of Planning Data.
Restrictions
Importing data from SAP BPC is currently not supported by models with measures.