Planning Concept in BW

© 2019 SAP SE or an SAP affiliate company. All rights reserved.
PUBLIC
2019-05-20
Planning Concepts
THE BEST RUN

Content
1 Planning Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Concept for Protecting Data from Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Data Basis InfoProvider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Characteristic Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Characteristic Relationships for Time Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Data Slices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Implementing Characteristic Relationships and Data Slices on the SAP HANA Database. . . . . . . . 16
1.3 Aggregation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Simple Aggregation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Complex Aggregation Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
1.4 Filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.5 Variable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.6 Planning Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Process Flow of Planning Function: Distribution by Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Standard Planning Function Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Default Key Date in Planning Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
1.7 Planning sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Scheduling Planning Sequences in Process Chains. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Planning Sequence for Bottom-Up Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
1.8 Implementing a Planning Function Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Implementing Business Logic for a Planning Function Type in ABAP Classes. . . . . . . . . . . . . . . 107
Implementing Business Logic for Planning Function Types on the SAP HANA Database. . . . . . . . 111
1.9 Input-Ready Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Input-Ready Queries at Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
Displaying All Valid Characteristic Combinations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Disaggregation (Top-Down Distribution). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Defining Inverse Formulas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Inverse Formulas at Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Master Data Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.10 Saving Changed Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
1.11 Audit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Audit Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Audit Query. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
1.12 Lock Concept and Lock Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Managing Lock Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Storing the Lock Table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Planning Concepts
2 PUBLIC Content
Selecting Lock Characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Displaying Active Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .165
Displaying Master Locks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Analyzing of Locking Conflicts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Sizing Lock Tables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
2 Creating Planning-Relevant Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

2.1 Creating Aggregation Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
2.2 Creating a Data Slice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
2.3 Creating Characteristic Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Tab Page: General Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Tab Page: Characteristic Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
2.4 Creating Planning Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
2.5 Creating a Planning Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Planning Concepts
Content PUBLIC 3
1 Planning Concepts
Planning in SAP Business Planning and Consolidation, version for SAP BW/4HANA (Embedded) provides
business experts with an infrastructure for creating and operating planning scenarios or other applications.
Planning covers a wide range of topics, ranging from simple data entry to complex planning scenarios.
Prerequisites
The authorizations that users require for planning are the same as the authorizations required to analyze the
data in a query. As well as the display authorization, users need the change authorization.
Context
The planning model is comprised of the following elements:
● Data (stored in InfoProviders intended for planning)

● Restrictions to data or their input-enabledness (CompositeProviders, characteristic relationships)
● Methods to change data (planning functions, planning sequences - also within process chains - manual
planning in the form of input-ready queries)
● Utilities (filters that can be used in queries and planning functions; variables used to parameterize objects
that can be used where selections are used in data slices for example)
● Concepts for protecting data centrally (data slices), with time restrictions if required
Procedure
1. Creating Data Basis and Managing Locks
Suitable InfoProviders are used to store data for planning.
To make that only one user can change data, this user's data is locked. Depending on the expected load
(determined by the number of users working in parallel and the complexity of the selection), you can set
one of several lock processes as the default.
2. Defining Planning Model Objects
○ Aggregation Levels
To set the level that data can be entered or changed on (manually by user input or automatically by a
planning function), you define an InfoProvider of type aggregation level. An aggregation level consists
of a subset of characteristics and key figures of an InfoProvider suitable for planning.
○ Characteristic Relationships
You use characteristic relationships to model semantic relationships between characteristics (such as
product group and product). This allows you to perform various checks, for example whether a
Planning Concepts
4 PUBLIC Planning Concepts
particular combination of characteristics can be generated (if this combination is permitted) or
whether a cell is input ready. Characteristic relationships are created for an InfoProvider suitable for
planning.
○ Data Slices
You use data slices to protect whole areas of data globally against changes (current values or historic
values for example).
○ Planning Functions
Planning functions allow system-based processing or generation of data. Functions can be executed
immediately (using the pushbutton) or in the background as a planning sequence. SAP delivers
numerous standard planning function types. You can also define your own function types.
○ Planning Sequences
A planning sequence is a sequence of planning functions and manual input templates that are
executed sequentially. Planning sequences can also be processed in the background as a step in a
process chain.
○ Filter
A filter describes a section of a dataset which is processed in a query or a planning function (calendar
year 2016, 2017; customer group XY for example).
○ Variables
You can use variables in various places: In the filter for pameterizable selection of characteristic values,
for parameterization of planning functions or planning sequences.
 Note
More information about transporting planning model objects: .
3. Defining Input-Ready Queries
In the BW Modeling tools, you can define an input-ready query based on an InfoProvider that is suitable for
planning. You can use a query of this type for manual planning. Whether a particular cell is input-ready
depends on the drilldown and whether characteristic relationships and data slices are permitted for the
cell.
Related Information
Data Basis InfoProvider [page 7]

Aggregation Level [page 22]
Filter [page 27]
Variable [page 29]
Planning Functions [page 32]
Planning sequence [page 96]
Implementing a Planning Function Type [page 106]
Input-Ready Query [page 117]
Saving Changed Values [page 151]
Audit [page 153]
Lock Concept and Lock Management [page 160]
Planning Concepts
Planning Concepts PUBLIC 5
1.1 Concept for Protecting Data from Changes
The planning model incorporates are concepts for protecting data from changes. These are tailored for various
usage scenarios.
During planning, it is usual to use various versions which must not be changed any more once planning has
been completed. Another scenario is rolling planning, where planning activities can be performed during
certain time frames. This might be the next 12 months after the current month for example, while no planning
activities can be performed for all months prior to the current month. What this usage scenarios generally have
in common is that the planning data is protected from changes by all users (perhaps with the exception of
administrators). These usage scenarios can be depicted using data slices. Data slices are generally not specific
to a user for manual planning and planning functions. Using variables or exit data slices makes it possible to set
data slices user-specifically.
Data slices make it possible to have a kind of status administration in planning. This is not explicitly supported
by the system however, as status administration of planning data generally splits up planning into areas of
responsibility and assigns the persons who control the planning activities, and who are responsible for the
monitoring and administration of the planning activities. This normally involves setting rules that are used to
delimit the various areas of responsbility. In the case of cost center planning, this could be the cost center. For
sales planning, this could be the country or region. This usage scenario is supported by the system using the
work status inSAP Business Planning and Consolidation, version for SAP BW/4HANA (Embedded). The work
status makes it possible to define the areas of responsibility and to assign the persons responsible. For the
various areas and subareas, a freely definable planning status can be set. This is particularly useful for
protecting planning data from changes. This functionality is provided in work status administration. Protecting
data from changes is carried out by the system – depending on the status of the planning data - using data
slices that are created at runtime.
In addition to the concepts of data slices and work status administration in SAP Business Planning and
Consolidation, version for SAP BW/4HANA (Embedded), which are stored in the database, there is also the
concept of fixing cell values in manual planning. Fixing of cell values is an input help that is offered in order for
example to interactively remove values from distribution during disaggregation, or to control the sequence of
calculations of inverse formulas. Fixings only apply in the user session where they are made. They are not
stored in the database.
A concept that is completely separate from the three concepts described above is the lock concept of the
planning in SAP Business Planning and Consolidation, version for SAP BW/4HANA (Embedded). This locks all
transaction data that is read in change mode exclusively for use in a single user session. This lock concept
makes sure that only the user who has set the lock can make changes to the locked data.
Related Information
Data Slices [page 15]

Lock Concept and Lock Management [page 160]
Planning Concepts
1.2 Data Basis InfoProvider
The data basis is provided by InfoProviders that are suitable for planning or that contain InfoProviders of this
type.
Basis InfoProviders that are suitable for planning
The following data is persisted to the basis InfoProvider that is suitable for planning. You can use the
following InfoProviders for this:
● DataStore Objects:
○ Standard DataStore object with the property Write Change Log
○ Data mart DataStore object
○ Direct update DataStore object:
 Note
For more information about planning on a DataStore object, see SAP Note 2189829 .
● InfoObject (Characteristic)
○ With modeling property Usable as InfoProvider
○ With modeling property Planning Mode
○ As an InfoProvider it is in the planning mode (iby default, a plannable InfoObject is first in load mode
and must be changed.)
 Note
For more information about standard settings of InfoObjects, see , and for switching between load and
planning mode, see
Also note the following conditions that must be fulfilled before a characteristic can be used as a basic
InfoProvider for master data planning:
○ The characteristic has a master data table and was created using SAP BW∕4HANA, which means it was
not implemented using a special master data read class, such as SAP HANA view.
○ It does not have the property Enhanced Master Data Update.
○ It is not an XXL InfoObject.
○ The characteristic is not a reference to another characteristic.
If the InfoObject has a text with the property Long Text Is Extra Long or Attribute Only, the text cannot be
planned.
● Local provider in BW Workspace
The following rule therefore generally applies: Data records can only be changed via planning if exactly
one aggregation level is involved for the plannable basis InfoProvider on the route from ‘top’ to ‘bottom’.
Planning Concepts
CompositeProvider Suitable for Planning
Planning is not executed directly on the basis InfoProviders mentioned above, but via an InfoProvider of type
aggregation level that defines which characteristics and key figures can be used to fill the data records.
Aggregation levels can be defined on plannable basis InfoProviders or on composite InfoProviders, provided
that these do not contained aggregation levels.
The following composite InfoProviders are suitable as the basis for aggregation levels:
● CompositeProviders that contain at least one basis InfoProvider that is suitable for planning The
participating InfoProviders (including SAP HANA models) can only be assigned using a UNION.
 Note
For more information about planning on a CompositeProvider, see SAP Note 2091885 .
● Note that 1KYF_* key figures of a basic InfoObject can only be mapped in the CompositeProvider if they
belong to a navigation attribute of the InfoObject. In particular, the date fields 1KYF_DATE*
1KYF_TXTDATE* and the 1KYF key figures of units and currencies cannot be exposed in the
CompositeProvider.
A CompositeProvider can be used directly for planning if it contains at least one aggregation level.
Characteristic Relationships and Data Slices
In the context of planning, you can define the permitted combinations of characteristic values (in the form of
characteristic relationships) for planning suitable InfoProviders and create data slices for the selected data that
you want to protect.
 Caution
Note that changes for Central Settings, Characteristic Relationships and Data Slices in the active user
sessions do not take effect immediately if these settings have already been read in this same user session:
These settings are buffered in order to enhance consistency and performance.
If the generic types of characteristic relationships (attribute, hierarchy) and data slices (selection) do not meet
specific customer requirements, you can implement characteristic relationships and data slices of type Exit.
Default Key Date for Planning
You can still create a key date for an InfoProvider, which is suitable for planning, as the default key date for
planning. If time-dependent objects (such as attributes or hierarchies) are used in objects in the planning
model, you can always refer to the default key date for planning. This allows you to ensure that the same key
date is used throughout the planning model. The planning model objects that are relevant for this are
characteristic relationships, data slices and parameters of planning functions.
Planning Concepts
Tools
You can create InfoProviders as the data basis for planning in the BW Modeling tools or as local query extended
models.
Related Information
These links take you to the documentation about planning suitable basis InfoProviders.
Creating Aggregation Levels [page 172]
These links take you to the documentation about planning suitable virtual CompositeProviders and aggregation
levels.
Characteristic Relationships [page 9]
Implementing Characteristic Relationships and Data Slices on the SAP HANA Database [page 16]
Data Slices [page 15]
Default Key Date in Planning Functions [page 95]
Master Data Planning [page 150]
These links take you to the documentation about planning-specific metadata objects and central settings.
1.2.1 Characteristic Relationships
Characteristic relationships are used to define a relationship between characteristics with matching contents.
Use
You can use characteristic relationships to define rules for checking permitted combinations of characteristic
values for each InfoProvider, which is suitable for planning. You can also define rules for the system to use to
derive values from one characteristic for another. This is useful for example if you want the derivable
characteristics to be available for further analysis.
You can define characteristic relationships for the master data of a characteristic (type attribute), a hierarchy
(type hierarchy), a DataStore object (type DataStore) or an exit class (type exit).
An InfoProvider can either be used as a storage for transaction data for planning, or it can be used for modeling
the permitted combination of characteristics.
 Tip
If you use a direct update DataStore object to store permitted characteristic combinations, this has the
advantage that you can configure this DataStore object in an input-ready query directly.
Planning Concepts
We advise not to mix these InfoProvider roles for the storage of plan data and for the storage of plan data rules.
If these roles are mixed during a user session however, the following rules apply:
● If an InfoProvider named A is used as the InfoProvider for the planning, other InfoProviders, which use A in
a characteristic relationship, are not input-ready.
● If InfoProvider A is used first in a characteristic relationship and then used as an InfoProvider for planning,
the planning provider is not input-ready.
● If InfoProvider A is used in CompositeProvider as a PartProvider and used in a characteristic relationship of
a different PartProvider, PartProvider A is not input-ready.
Integration
If characteristic relationships are defined for the attributes or hierarchies of characteristics, the system
proposes the attributes and hierarchies created in the system in question for a characteristic.
Characteristic relationships are created for a basis InfoProvider suitable for planning. The system then applies
the characteristic relationships to all planning-relevant InfoProviders that reference this basis InfoProvider.
Every input-ready query and planning function automatically takes the characteristic relationships into
account:
● In an input-ready query, cells for invalid characteristic combinations are not input ready, and new data
records with invalid characteristic combinations cannot be created.
● Planning functions use the characteristic relationships to constantly check whether new characteristic
combinations are valid. If it finds invalid combinations, the system produces an error message.
The system derives the possible characteristics when it identifies the delta records in the delta buffer (for the
local provider in the BW workspace) or in the after image buffer (for the DataStore object).
Possible source characteristics include characteristics in the planning-relevant InfoProvider that are filled by
characteristics from the relevant aggregation levels. If characteristic relationships are changed, the data
records in the planning-relevant InfoProvider might also have to be adapted to the new structure. You use the
Reposting Characteristic Relationships planning function for this purpose.
Prerequisites
Before you can define characteristic relationships, the following prerequisites must be met:
● The InfoProvider must be a basis InfoProvider that is suitable for planning. The defined characteristic
relationships also take effect in CompositeProviders where planning-relevant basis InfoProviders are used.
● In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of
the basic characteristic and it must be contained in the planning-relevant basis InfoProvider.
● In characteristic relationships of type hierarchy, the target characteristic must be contained in the
selected hierarchy and in the planning-relevant basis InfoProvider. The hierarchy is mainly intended for
modeling a derivation relationship. Therefore the hierarchy cannot contain the same leaf or inner node
more than once. Link nodes are also not permitted.
● With characteristic relationships of type DataStore, only the following DataStore objects are permitted:
○ DataStore object: All types are supported as long as the DataStore object has a unique key and is not a
data mart DataStore object.
Planning Concepts
 Note
As well as the characteristic relationships listed above, characteristic relationships for the time
characteristics are also permanently activated in the system.
Key Features
Definition of a Characteristic Relationship
You can create characteristic relationships are created for a basis InfoProvider that is suitable for planning. A
characteristic relationship is made up of a set of relations (steps), which link characteristics and which are
numbered sequentially. Each of these relations links a set of characteristics. These relations represent the
smallest units of a characteristic relationship.
Behavior of combination checks with and without derivation
You can only use relations to check characteristic combinations or derive characteristics. You specify this
behavior when defining a relation. You can link several relations of type Derivation if the targets of one relation
are the sources of another relation. Redundancy should be avoided here, to make sure that the relations
actually represent the smallest unit of the characteristic relationships.
At runtime, the system determines which relations of the characteristic relationships are used in the
InfoProviders relevant for planning.
● Combination check: A relation is only used in an aggregation level if every characteristic of the relation
occurs on the aggregation level. With derivations, these are the source and target characteristics. In this
case, no characteristics are derived, and the system just performs a combination check.
● Characteristic derivation: Derivation is not performed in an aggregation level. New rows in input-ready
queries are an exception to this rule. Here, the system attempts to fill further characteristic values for other
characteristics by means of derivation from known characteristic values. Derivations are only performed
for records in the planning-relevant basic InfoProvider. The system first determines the set (S) of
characteristics that are filled by the relevant aggregation level. If all the source characteristics are in set S,
the system applies the derivation relations in the next step. The target characteristics of these derivations
can then be used as sources in the subsequent steps. This means that the system performs the maximum
possible derivation in the planning-relevant basis InfoProvider. If previously derived characteristic values
are changed again in subsequent steps, the derivation is incorrect. The system posts an error message.
Things to look out for with the initial characteristic value (# not assigned)
The initial characteristic value # not assigned) has a special role in a relation. Characteristics that do not occur
in an aggregation level (and cannot be derived) are updated with the initial value.
 Example
● Combination check without derivation:

There is a relation between the characteristics Product and Assortment; usually there is no derivation
relationship between the two. In aggregation levels with Product but without Assortment, Assortment is
therefore updated with the initial value. These types of combinations are always valid and they cannot
be forbidden. This also applies to combinations with the initial value for Product.
● Combination check with derivation:
There is a relation between the characteristics Cost Center and Profit Center; Profit Center can be
derived from Cost Center. In an aggregation level that contains Profit Center but not Cost Center, Cost
Planning Concepts
Center is also updated with the initial value. Combinations of this sort cannot be forbidden. However,
since Profit Center can be derived from Cost Center, the reverse situation produces an invalid
combination.
The special combinations listed in the example above with the initial values are known as automatically valid
combinations. In the case of relations of type Exit, methods CHECK and DERIVE are not called for
automatically valid combinations. The system still creates the automatically valid combinations, even if these
are not returned in method CREATE. To prevent this from happening in a characteristic relationship, you can set
the Also apply to automatically valid combinations = X flag. In this case, methods CHECK and
DERIVE are also called for automatically valid combinations. The system does not add the automatically valid
combinations to combinations created in CREATE.
 Note
Note that characteristic relationhips do not act as a further implicit filter for the transaction data to be read.
The system reads the transaction data specified by the filter of the query or planning function (regardless
of whether this is valid or invalid according to the characteristic relationship) and then possibly also creates
further combinations in accordance with the rules described above.
Related Information

Characteristic Relationships for Time Characteristics [page 12]
The following links take you to the documentation for the characteristic relationship concept.
Creating Characteristic Relationships [page 175]
Tab Page: General Settings [page 177]
Tab Page: Characteristic Relationships [page 177]
The following links take you to the documentation for the task of editing a characteristic relationship.
1.2.2 Characteristic Relationships for Time Characteristics
The BW/4HANA system contains various time characteristics. When you create a planning model, you have to
select an appropriate time characteristic for the planning-relevant InfoProvider.
Use
You should avoid using redundant time characteristics in a planning-relevant InfoProvider. However in some
cases, like in the example below, this may be useful.
 Example
The choice of time characteristic depends on the planning application. You can use the Fiscal Year Period
characteristic 0FISCPER (12.2005 + 1 = 1.2006) for rolling planning, for example.
Planning Concepts
However, if you want to build query views that contain Periods in the rows and the Fiscal Year in the data
columns, it makes more sense to use the Periods and Fiscal Year time characteristics.
If a planning-relevant InfoProvider contains redundant time characteristics, at runtime, the system uses the
characteristic relationships that are required by the input-ready queries or planning functions for the
corresponding time characteristics. The characteristic relationships are of type “derivation”, except for the
characteristic relationship for the characteristics FISCVARNT, 0FISCYEAR, 0FISCPER3.
 Caution
Note that the system only allows unique relationships. You can derive the calendar year (0CALYEAR) from
time characteristic quarter (0CALQUARTER), but not the calendar week (0CALWEEK).
If you want to model a relationship of this type, you require a customer-defined characteristic relationship
of type exit that uses its own characteristics. These characteristics must reference the appropriate
standard time characteristics.
The system uses the derived characteristic relationships for the time characteristics (as with the other
relations) for derivation purposes and combinations checks.
 Caution
Note that for each time characteristic there is a maximum valid time interval. This can be set in the system.
If you are using a time characteristic, the maximum valid time interval has to cover the entire planning time
frame.
On the General Settings tab page, you can specify the time interal on the F4 Help and Hierarchies for Time
Characteristics screen (transaction RSRHIERARCHYVIRT). Since this setting impacts on performance, you
are advised to keep the interval as small as possible.
You cannot create derivations that contain a time derivation that is used automatically in the system.
The following table offers an overview of the derivations that are automatically supported by the system:
Source characteristics Target characteristics Comment
0CALDAY 0CALWEEK
0CALDAY 0CALMONTH
0CALDAY 0CALQUARTER
0CALDAY 0CALYEAR
0CALDAY, 0FISCVARNT 0FISCPER Fiscal year variant required due to com

pounding
0CALDAY, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com

pounding
0CALDAY 0WEEKDAY1
Planning Concepts
Source characteristics Target characteristics Comment
0CALDAY 0CALMONTH2
0CALDAY 0CALQUART1
0CALDAY 0HALFYEAR1
0CALDAY, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com

pounding
0CALMONTH 0CALQUARTER
0CALMONTH 0CALYEAR
0CALMONTH 0CALMONTH2
0CALMONTH 0CALQUART1
0CALMONTH 0HALFYEAR1
0CALQUARTER 0CALYEAR
0CALQUARTER 0CALQUART1
0CALQUARTER 0HALFYEAR1
0CALMONTH2 0CALQUART1
0CALMONTH2 0HALFYEAR1
0CALQUART1 0HALFYEAR1
0FISCPER, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com

pounding
0FISCPER, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com

pounding
0CALWEEK, 0WEEKDAY1 0CALDAY
0CALYEAR, 0CALQUART1 0CALQUARTER
0CALYEAR, 0CALMONTH2 0CALMONTH
0FISCYEAR, 0FISCVARNT, 0FISCPER3 0FISCPER Fiscal year variant required due to com
pounding
0FISCVARNT, 0FISCYEAR, 0FISCPER3 Fiscal year variant required due to com

pounding
Planning Concepts
Related Information
1.2.3 Data Slices
The data slice is a concept for protecting the main data of a planning-relevant basic InfoProvider against
changes. This protection affects all input-ready queries and planning functions that use this planning-relevant
InfoProvider.
Key Features
There are two types of data slice:
● Data slices based on a selection. Here, you set the restrictions for the characteristics that you want to
protect against changes.
● Data slices based on an exit class. In the exit class, you can implement a customer-specific logic to protect
data records. For more information, see the documentation about the attributes and values of the class in
transaction SE24. If you want to buffer access to data methods that have already been read in method
IS_PROTECTED, you can pass this task onto the system and do not have to implement it in this exit. To do
this, you go to CONSTRUCTOR in the exit class and set attribute N_USE_EXTERNAL_BUFFER in interface
IF_RSPLS_DATASLICE.
The following basic rules apply for data slices:
● If there is no data slice defined for a planning-relevant basis InfoProvider, any valid characteristic
combination can be posted to this InfoProvider.
● Every data record in the selection in a data slice is protected against changes. The corresponding cells in
input-ready queries cannot be changed. You cannot use planning functions to change or save this kind of
record. The data slices cumulate.
● If a planning-relevant basis InfoProvider contains a data slice that does not contain any characteristic value
restrictions, the data slice acts as a lock for postings of all types in the entire InfoProvider.
● When you save a new data slice, it has the status Active.
● You can deactivate an existing data slice, for example if data stored in the data slice in question needs to be
changed for administration purposes. In this case, deselect the Active flag.
Related Information
Creating a Data Slice [page 174]
Planning Concepts
1.2.4 Implementing Characteristic Relationships and Data
Slices on the SAP HANA Database
If the generic types of characteristic relationships (attribute, hierarchy, DataStore) and data slices (selection)
do not meet specific customer requirements, you can implement characteristic relationships and data slices of
type Exit.
The following are two examples of requirements that can be met with an implementation of characteristic
relationships or data slices of type Exit:
● Example 1: Let us assume that two previously separate sales organizations are being merged. Some of the
products offered by one organization are also offered by the other, and these products originally had
different product numbers in the two organizations. To allow standardized reporting over the entire product
range, the two independent product catalogs are mapped to a cross-organizational product catalog using a
mapping table. The mapping table has the following structure:
Mapping Table Z_MAP_PRODUCT

Region Regional_Prod_ID Product_ID
R_01 RP_123 UP_123
R_02 RP_123 UP_321
... ...
In the different regional sales organizations, different products can have the same identification number. To
ensure that there is a unique designation for a cross-regional comparison, these RP numbers must be
converted into unique UP numbers. In our example, product RP_123 from region R_02 is given product ID
UP_321.
● Example 2: Let us assume that a company wants to implement a company-wide planning process for
quarterly sales key figures at the product group level. Note that some regional sales organizations fix their
plan data (for certain planning versions at least) on a certain date, while others modify their plan data if
dictated by certain subsequent events.
This could mean for example that the plan data of Region A for the first quarter of the following year is fixed
starting on 15th December of the current year, while Region B is allowed to modify its plan right through to
the end of January on the basis of an unforeseen opportunity to increase its sales. To make this
comprehensible, plan version V2 can be introduced, filled with the original plan data from plan version V1
and then opened for modifications from Region B only.
To implement the requirement in example1, you can define a characteristic relationship of type Exit, containing
two relations (steps) with derivation: The first relation has the unique ID as its source characteristic and the
original ID (in connection with the original sales organization) as its target characteristic, while the second
relation is the same but the other way round. The original ID is therefore derived if the unique ID is planned. The
unique ID is derived if the fields are reversed. The consistency of the two IDs is guaranteed if both
characteristics are open for planning.
The requirement from example 2 is a typical case for a data slice of type Exit, defined on the characteristics
Region, Plan Version and Quarter, with access to data that is edited outside of the SAP BW∕4HANA system in a
tool for the planning process, which stores its data in a database. To make this requirement more individual
still, there should a number of administrators who are authorized to modify plan data at any time, in order to
correct incorrect entries.
Planning Concepts
ABAP Exit Implementation
The typical ABAP exit implementation of these examples is direct, with the external data being read from the
database using SQL commands from the ABAP runtime and - taking into account further information such as
user name (sy-uname) - checking, deriving or creating records in the corresponding structure.
Implementation on the SAP HANA database
You can perform SAP HANA-optimized planning using internal database routines in the SAP HANA database. In
that case, we recommend also implementing the customer-specific exist functionality for characteristic
relationships directly in the SAP HANA database using SQLScript. Otherwise you will still not exhaust the
possibilities for performance optimization: Plan data would then have to be submitted to the ABAP runtime and
processed in individual records. While this would not be problematic for displaying data from analytical queries,
as the data is available in the ABAP runtime anways, there can be a negative impact on performance if
disaggregation (top-down distribution) or planning functions are executed on mass data. The entire data
processing then takes place in the SAP HANA database. An ABAP implementation of the exit functionality
would then prevent performance from being optimized.
 Note
Note the following: Even if you implement SQLScript procedures for all methods that are used in
characteristic relationships and data slices, the corresponding ABAP implementations must also be
present, as the system triggers the ABAP equivalent in certain situations in order to avoid additional data
transfer of individual records between the SAP BW∕4HANA system and the SAP HANA database. The aim is
always to bring the algorithms to the data. The results list for the client are formatted in ABA. Checks on
the basis of characteristic relationships and data slices are relevant for this.
 Note
If a SQLScript implementation is performed, the names of the implementing SQLScript procedures are
determined in the ABAP runtime, and other parameters that are only available in AS ABAP (such as the
user name in the sy-uname system field) are determined for subsequent use in the SQLScript
implementation.
 Note
The three methods CREATE, CHECK and DERIVE in the case of ABAP and in the SQL procedures, which are
identified in the SAP HANA of IF_RSPLS_CR_EXIT_HDB~ GET_SQLSCRIPT_INFO in the parameters
E_PROCEDURE_NAME_CREATE, E_PROCEDURE_NAME_CHECK and E_PROCEDURE_NAME_DERIVE,
must always return consistent results. This means: The exact records generated by CREATE must also be
identified by CHECK and DERIVE must complete the exact values that are identified as valid by CHECK (or
that would be generated by CREATE).
If your implementations (ABAP and SAP HANA) do not fulfill this prerequisite, then it is possible that the
results in ABAP and in SAP HANA will be different, even if the pairs (CREATE in ABAP and in SAP HANA;
CHECK in ABAP and in SAP HANA and DERIVE in ABAP and in SAP HANA) calculate identical results.
For ABAP processing of the exits, the following interfaces are required:
Planning Concepts
● IF_RSPLS_CR_EXIT : ABAP implementation of the characteristic relationships
● IF_RSPLS_DS_EXIT : ABAP implementation of the data slices
In addition to these interfaces, the following interfaces also have to be implemented in order to process the
data in the SAP HANA database:
● IF_RSPLS_CR_EXIT_HDB : SQLScript implementation of the characteristic relationships

● IF_RSPLS_DS_EXIT_HDB : SQLScrip implementation of the data slices
The SAP HANA-specific interfaces have the following tasks:
1. They serve as marking interfaces which show that the data will be processed in the SAP HANA database,
regardless of the existence of characteristic relationships and data slices of type Exit.
2. By providing information about the corresponding SQLScript implementations, these implementation
should be called up if the data is processed in the SAP HANAdatabase, and a data transfer to the ABAP
runtime environment can be avoided.
Related Information
SAP HANA HANA-Specific Interfaces for Characteristic Relationships and Data Slices [page 18]
Parameters for the SQLScript Procedures [page 20]
Transport and Lifecycle Management of Required Objects [page 21]
1.2.4.1 SAP HANA HANA-Specific Interfaces for

Characteristic Relationships and Data Slices
This section provides an overview of the implementation of SAP HANA HANA-specific interfaces
IF_RSPLS_CR_EXIT_HDB (for characteristic relationships) and IF_RSPLS_DS_EXIT_HDB (for data slices).
These contain two methods, GET_SQLSCRIPT_INFO and GET_SQLSCRIPT_ PARAMETERS.
Method GET_SQLSCRIPT_INFO
Method GET_SQLSCRIPT_INFO returns the name of the SQLScript procedures that are required for exit
processing in the SAP HANA HANA database.
Planning Concepts
Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_CR_EXIT_HDB has the following export parameters:
Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_CR_EXIT_HDB

Parameter Description
E_DB_SCHEMA_NAME Name of a database schema that contains the SQLScript

procedures to be executed.
If the parameter of the method is not set, the DB schema of

the SAP system is taken.
E_PROCEDURE_NAME_CHECK Name of the SQLScript procedure that contains the imple

mentation of the method to check characteristic relation
ships.
E_PROCEDURE_NAME_DERIVE Name of the SQLScript procedure that contains the imple

mentation of the method to derive characteristic relation
ships.
E_PROCEDURE_NAME_CREATE Name of the SQLScript procedure that contains the imple

mentation of the method to create characteristic relation
ships.
E_PARAMETER_NAME Name of a DDIC structure that describes additional parame

ters that are passed on to the SQLScript procedures at run
time.
If the parameter of the method is not set, no additional infor

mation is sent by the application server.
Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_DS_EXIT_HDB has the following export parameters:
Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_DS_EXIT_HDB

E_DB_SCHEMA_NAME Name of a database schema that contains the SQLScript

procedures to be executed.
If the parameter of the method is not set, the DB schema of

the SAP system is taken.
E_PROCEDURE_NAME_PROTECTED Name of the SQLScript procedure that contains the imple

mentation of the data protection check in data slices.
E_PARAMETER_NAME Name of a DDIC structure that describes additional parame

ters that are passed on to the SQLScript procedures at run
time.
If the parameter of the method is not set, no additional infor

mation is sent by the application server.
 Note
If method GET_SQLSCRIPT_INFO does not set one of the parameters with procedure names, the
corresponding ABAP implementation is called at runtime as a fallback.
Planning Concepts
Method GET_SQLSCRIPT_ PARAMETERS
When export parameter E_PARAMETER_NAME of method GET_SQLSCRIPT_INFO returns the name of the
DDIC structure, method GET_SQLSCRIPT_ PARAMETERS is called. For both characteristic relationships and
data slices, this method has the following export parameter:
Export Parameter of Method GET_SQLSCRIPT_PARAMETERS

E_S_PARAMETER Structure used to pass on additional parameters to the

SQLScript procedures.
At runtime, this parameter has the type of the DDIC struc

ture called E_PARAMETER_NAME.
1.2.4.2 Parameters for the SQLScript Procedures
All SQLScript procedures for the implementation of methods to check and derive characteristic relationships
or to protect data slices require an IN table parameter and an OUT table parameter with the structure of the
modeled characteristic relationship or data slice. The IN parameter table contains all data records to be
processed in the implementation. The OUT parameter table returns the processed data records.
Methods for characteristic relationships
● CHECK
○ IN: All data records that should be processed by the procedure.
○ OUT: All data records in the IN parameter table, which are considered valid with regard to the
characteristic relationship.
● DERIVE
○ OUT: All data records in the IN parameter table, which are considered valid with regard to the
characteristic relationships with derivation of target characteristic values from the source
characteristics.
● CREATE
○ OUT: For the CREATE procedure, there is only one OUT table parameter with the structure of the
modeled characteristic relationship. We recommend submitting important parts of the selection via
the parameter structure.
Methods for data slices
● PROTECTED
Planning Concepts
○ OUT: All data records in the IN parameter table, which are protected against changes with regard to
the data slice.
For all methods, the following applies:
If a DDIC structure of method GET_SQLSCRIPT_INFO is returned in parameter E_PARAMETER_NAME, the

SQLScript procedure must have additional scalar parameters. The names of these parameters correspond to
the component names of the DDIC structure.
 Recommendation
We recommend using the new program RSPLS_SQL_SCRIPT_TOOL. The SAP BW∕4HANA-Planning: Tool for
SQLScript Exits screen appears. On the third tab, Sample Characteristic Relationship/Data Slice, you can
create sample code (based on your own objects) for characteristics combinations and data slices. The
corresponding characteristic combination step or data slice must have already been created of type “Exit”.
Please note that the system sometimes executes characteristic combinations and data slices in ABAP for
performance reasons, if an SQLScript implementation is used. You therefore need to create identical
implementations from the result for SAP HANA and ABAP.
Fallback for SAP HANA-optimized processing
If you require SAP HANA-optimized processing, problems can occur in connection with ABAP exit
implementations in characteristic relationships and data slices.
To prevent this from happening, you can also provide SAP HANA implementations for the required functions in
SAP HANA and use SQLScript for the implementation. Note however that this involves working with an
additional development environment and programming language.
A simpler solution, albeit one which cannot be compared with this one in terms of performance, is described in
the following SAP Note: 1956085 .
1.2.4.3 Transport and Lifecycle Management of Required

Objects
The ABAP classes that implement the SQLScript metadata rules can be transported with the CTS (Change and
Transport System) on the ABAP Application Server. The following section describes the software logistics
options for the corresponding SQLScript procedures.
Creating SQLScript Procedures Separately for Every System
You can create the procedures for each system in your system landscape using the SQL console in the SAP
HANA studio or using transaction DBACOCKPIT in the SAP BW∕4HANA system as SAP HANA catalog objects.
Planning Concepts
In the software, this option is only supported by syntax highlighting in the SAP HANA studio, but it is also very
simple and direct. Note however that every change to the implementation of a procedure must be replicated
manually in all other systems in your system landscape.
Creating the SQLScript Procedures as SAP HANA Repository Objects
You can create and activate the procedure as a SAP HANA repository object in the development system. (The
activated object is then in the DB schema _SYS_BIC.) This allows you to use the SAP HANA software logistics
functions to provide data to downstream systems. This option involves a considerable amount of configuration
in order to set up a workable development environment in the SAP HANA studio. It is often worth the extra
effort though, as you receive better system support and can use Lifecycle Management for SQLScript
procedure implementations in SAP HANA.
Creating SQLScript Procedures as AMDPs
We recommend implementing the SQLScript procedures as AMDPs (ABAP Managed Database Procedures) in
order to integrate these implementations into the Transport Management System in AS ABAP. For SQLScript
procedures, you can therefore use the Transport and Lifecycle Management that you are acquainted with from
working with ABAP development objects.
 Note
For more information about AMDP, see the ABAP key word documentation at
● http://help.sap.com/abapdocu_740/en/index.htm?file=abenamdp.htm
● http://help.sap.com/abapdocu_740/de/index.htm?file=abenamdp.htm
1.3 Aggregation Level
Use
Aggregation levels are used as InfoProviders for planning: They allow you to model levels containing data that
can be changed manually, using input-ready queries, or automatically, using planning functions.
An aggregation level is defined by a set of characteristics and key figures of the underlying InfoProvider. The
key figures contained in the aggregation level are aggregated using the characteristics not contained in the
aggregation level.
The simplest case is where an aggregation level lies on an InfoProvider, which is suitable for planning.
Aggregation levels can also be created on InfoProviders that are suitable for planning, as they contain a basic
InfoProvider that is suitable for planning: You can create several aggregation levels for one InfoProvider.
Simple Aggregation Level
Planning Concepts
A basic InfoProvider is based on a simple aggregation level.
Complex Aggregation Level
A complex aggregation level is based on InfoProvider containing at least one basic InfoProvider suitable for
planning, but no simple aggregation level.
 Example
You want to copy current data from an actual basic InfoCube to a plan basic InfoCube with a planning
function of type Copy. To do this, you use an aggregation level based on an InfoProvider that includes the
plan and actual InfoProviders.
Aggregation levels cannot have a nested structure.
With a complex aggregation level, it is important to note how data records from the basic InfoProvider are
embedded in this InfoProvider, which contains the basic InfoProvider, (and also embedded in the aggregation
level), and how the system writes changes to the data records of the aggregation level back to the basic
InfoProvider.
The following conditions apply for both aggregation level types:
● The aggregation level must contain at least one key figure.

● The key figures used here must have the database aggregations SUM, MIN, MAX or NO2. With MIN or
MAX, key figure values can only be displayed. They cannot be changed using manual planning or planning
functions.
● For key figures of type date or time, only data type DEC is supported.
● Referencing key figures (and therefore non-cumulative key figures or elimination of internal business
volume too) are not supported in aggregation layers.
● If a characteristic is compounded and used in an aggregation level, the aggregation level must also contain
all compounding "parent" characteristics.
● If a key figure is used in an aggregation level and does not have a fixed unit of measure or currency, the
aggregation level must contain the associated characteristic for the unit.
● If a key figure with exception aggregation is used in an aggregation level, the aggregation level must also
contain the characteristic for exception aggregation if it occurs in the underlying InfoProvider.
● The aggregation level inherits a navigation attribute from the underlying InfoProvider if it includes the basic
characteristic of the navigation attribute.
● A complex aggregation level cannot be created if a characteristic of a basic InfoProvider supplies two
separate characteristics in the higher-level InfoProvider.
● If a characteristic on the InfoProvider that serves as the basis for an aggregation level is constant, this
characteristic has to be included in the aggregation level.
● An aggregation level that uses a direct update DataStore object or a plannable InfoObject (in either direct
or indirect conjunction with an InfoProvider) must contain enough characteristics to fill the key of the
DataStore object or InfoObject. If the key fields are not all directly included in the aggregation level, then
characteristic relationships are required to derive the missing key fields from the characteristics included
in the aggregation level.
 Note
In some cases, this condition cannot be fully checked in the aggregation level modeling, because the
derivation steps are only performed at runtime. Therefore the situation might occur where the system
Planning Concepts
only checks incomplete modeling at runtime and cannot change the data using planning functions
(cells in queries are no longer input-ready).
● In the following cases, a CompositeProvider cannot be used as the basis for an aggregation level (see
2091885 ):
○ The CompositeProvider contains a JOIN with a plannable basic InfoProvider.
○ The CompositeProvider contains characteristic A, which is assigned to additional characteristic B from
another contained InfoProvider. Here, A does not reference B and B does not reference A.
○ The CompositeProvider contains a navigation attribute, which is not supplied by a plannable basic
InfoProvider.
○ The CompositeProvider contains a plannable basic InfoProvider with the Criteria filter.
Conditions that apply to an aggregation level, which uses characteristics as key figures
If you add a characteristic A from the data part of a direct update DataStore object or a plannable InfoObject to
the aggregation level with 1KYF_A as the key figrue and A as the characteristic, you cannot add characteristic A
in a query to queries as a free characteristic. You can only use use it in the filter or in restricted key figures.
Planning functions cannot use aggregation levels like this.
● DataStore Object as Base InfoProvider

Exposure of characteristics from the data part as key figures is only possible in a direct update DataStore
object.
 Example
If A is a characteristic, 1KYF_A is the name of the associated key figure.
Please note that unit characteristics must always be contained in the key of the plannable DataStore
object. It is therefore not possible to expose unit characteristics as key figures.
The following rules apply for compound characteristics in the data part of a DataStore object, if you want
these characteristics to be included as key figures in an aggregation level.
○ If characteristic C is compounded to characteristic A and 1KYF_C is to be added to the aggregation
level, then either; A must be in the key of the DataStore object and A must be added to the aggregation
level, or A must be in the data part of the DataStore object and then added as 1KYF_A to the
aggregation level.
○ If characteristic is compounded to characteristic B and 1KYF_B is to be added to the aggregation level,
then 1KYF_C must also be added to the aggregation level.
● InfoObject (characteristic) as basic InfoProvider
In an aggregation level that is to be used for master data planning, only characteristics that have attributes
or texts can be changed using an input-ready query.
If such an InfoObject is marked with modeling properties Usable as InfoProvider and Planning Mode, and is
running in planning mode, its attributes and texts are exposed as key figures.
 Example
If B is an attribute of the InfoObject, 1KYF_B identifies the associated key figure. If an object has time-
dependent attributes and/or texts, an additional pair of key figures is generated for the due date
interval of attributes and/or texts (for example 1KYF_1TXTDATEFROM and 1KYF_1TXTDATETO)
Note that you cannot plan master data with the planning functions.
Planning Concepts
Related Information

Simple Aggregation Level [page 25]
Complex Aggregation Level [page 26]
Master Data Planning [page 150]
This link takes you to the documentation for the task of editing an aggregation level.
This link takes to the documentation for an analysis function, which requires an aggregation level as an
InfoProvider and an input-ready query for editing short texts in a query.
1.3.1 Simple Aggregation Level
Use
The following example demonstrates how the system works when a key figure value is changed (manually or
automatically).
Assuming there is an basic InfoProvider suitable for planning with the characteristics product, product group,
version and year, along with the key figure revenue. The aggregation level ALVL includes the same objects with
the exception of the characteristic, product.
Product Product Group Version Year Sales
P1 PG1 V1 2017 10
P2 PG1 V1 2017 20
P3 PG2 V1 2017 42
The key figure revenue includes the database aggregation SUM. Therefore, we get the following result when the
transaction data for the aggregation level ALVL is read from the database without restriction:
Product Group Version Year Sales
PG1 V1 2017 30
PG2 V1 2017 42
Planning Concepts
If the revenue is changed from 30 to 40 and is saved as a new value, the system writes a new record with the
difference of the key figure value to the basic InfoProvider:
# PG1 V1 2017 10
In this type of delta records, all characteristics of the basic InfoProvider, that are not included in the
aggregation level, are assigned the initial value (not assigned: #). (Here we assume that no derivations were
used. For more information on this concept, see Characteristic Relationships [page 9]).
1.3.2 Complex Aggregation Level
Use
The following examples show:
● how the system embeds data records from the basis InfoProviders in the InfoProviders that contain these
● how the system writes new or changed data records from the InfoProvider back to the basis InfoProviders
contained in it
Example: Characteristic product in InfoProvider IP
Let there be an InfoProvider IP, which contains the basis InfoProvider BIP_I and the plan basis InfoProvider
BIP_P. The actual basis InfoProvider BIP_I contains the characteristics product, product group, version and
year, as well as the key figure profit. The plan basis InfoProvider BIP_P contains the same objects with the
exception of the Product characteristic. An aggregation level ALVL_MP is defined on the InfoProvider IP,
containing all characteristics of the InfoProvider.
The following two data records of the underlying basis InfoProvider yield the following data records in
InfoProvider IP:
Data record in actual basis InfoProvider BIP_I
Product Product Group Version Year Profit
P1 PG1 V1 2017 10
Data record in plan basis InfoProvider BIP_P
Product Group Version Year Profit
PG1 V1 2017 30
Data records in InfoProvider IP (or ALVL_IP)
Planning Concepts
InfoProvider Product Product Group Version Year Profit
BIP_I P1 PG1 V1 2017 10
BIP_P # PG1 V1 2017 30
The data records in InfoProvider IP are generated from the records of the underlying InfoProvider using a
UNION operation. The InfoProvider is always included so as to ensure that the "origin" of the relevant data
record is known at the data record level.
If new data records are generated during manual planning or using the planning functions, the system ensure
that every record of the InfoProvider can be assigned back to the InfoProviders contained in the InfoProvider
uniquely and without loss of information.
The following table shows an example of a data record that could not be assigned.
Example of a record in InfoProvider MP that could not be assigned
InfoProvider Product Product Group Version Year Profit
BIP_P P1 PG1 V1 2017 43
The data record belongs to InfoProvider BIP_P. This InfoProvider does not returns a product in the
CompositeProvider however. This means that P1 is not permitted.
In manual planning, data cells that could lead to this type of record are not input ready. In planning functions,
the system ensures that data records like these cannot be saved.
 Note
The same situation can occur for key figures in complex aggregation levels. If K is a key figure in
InfoProvider IP and is supplied from the actual basis InfoProvider BIP_I, but not from plan basis
InfoProvider BIP_P, this key figure is always initial in a data record in InfoProvider IP with the plan basis
InfoProvider BIP_P. This value also cannot be changed.
1.4 Filter
A filter is an object that describes a multidimensional extract of data from a data set.
Use
Filters are used in reporting, analysis and planning, to restrict data to a certain business area, certain product
groups, or certain time periods for example. By segmenting the data set, you can ensure that users or user
groups only have access to the data that is relevant to them and can only see the relevant data areas in an
application scenario.
Planning Concepts
In the SAP Business Planning and Consolidation, version for SAP BW/4HANA (Embedded) planning, the filters
specify the data selection for which a planning function is executed. A planning sequence comprises a set of
planning functions. A filter is assigned to each of these functions.
 Example
You want to revaluate the transaction data in your InfoProvider by 10%. However, you only want the
revaluation to be applied to specific customer groups. You can do this by creating a filter that contains the
customer groups that you want to revaluate.
Filters can be reused in planning functions and queries.
Integration
You can create multiple filters for an InfoProvider in the BW Modeling Tools.
Prerequisites
To create a filter and use it in the planning, you need an aggregation level.
Features
The filter definition contains those characteristics of an aggregation level that you want to restrict. A filter is
made up of the following:
Element Description
Characteristic Restrictions In the restriction dialog, you restrict the characteristic using
single values, value ranges, hierarchy nodes and variables.
These characteristic restrictions define the selection of data
for a filter.
Suggested values Default values are only relevant in queries. They can be de
fined in the same way as characteristic restrictions. They de
fine the initial filter status of the query when it is executed.
To specify selections of data that are time dependent for example if you want to determine a time-dependent
hierarchy for time-dependent hierarchy node selections, you specify a Filter Key Date.
 Note
You use the delivered variable 0PLANDATA with characteristic 0CALDAY to synchronize key dates in
queries, filters, characteristic relationships, data slices and planning functions. This allows you to ensure
that the same key date is used in these objects.
Planning Concepts
The function of a filter depends on whether you use it in a planning function or in a query.
Filters in Planning Functions
In planning functions, a filter on the characteristic restrictions describes the data for which a planning function
is executed.
Selections in the default values are ignored when the planning function is executed.
You also use a key date for the filter to find time-dependent selections.
Filters in a Query
The values defined in the characteristic restrictions restrict the data that is available for filtering at query
runtime. You cannot apply a filter to a characteristic value that is not part of this value set.
The default values define the initial filter state of the query.
The Changeable upon Execution and Only Single Value settings generally refer to using filters with a query.
Changeable upon Execution defines whether you can change the values selected in the characteristic
restrictions when executing the query. This setting is a prerequisite for defining default values for a
characteristic.
If you select the Changeable upon Execution option, you can use the Only Single Value option to specify that
you want to use a single value only to filter the query.
1.5 Variable
Use
Variables are used to parameterize a query, a filter, a characteristic relationship, a data slice or a planning
function. When a query or planning function is executed, it is filled with values.
Depending on the objects that you want to define variables for, there are various variable types. Variables are
placeholders for characteristic values, hierarchies, hierarchy nodes, texts and formula elements.
The processing type determines how a variable is filled with a value for the runtime of the query or planning
function.
 Example
Variables allow you to use a single planning function definition as the basis for many different queries. You
want to create a planning function of type Copy that copies your current data from the current version to
another one. You use a variable for the Version characteristic in the To parameters of the planning function.
Before executing the planning function, decide which version you want to copy the current data to.
 Note
For formula variables that are used in planning functions, for conversion functions for example, processing
type Replacement Path cannot be used. Only the Number dimension is supported here.
You can make unrestricted use of text variables in input-ready queries.
Planning Concepts
Validity Area of Variables
Variables and reusable objects are dependent on the corresponding InfoObject only, not on an InfoProvider. A
variable that you define for an InfoObject is available in all InfoProviders that use this InfoObject.
The same variable can have different values in different locations. A separate instance of the variable is created
whenever a variable is filled with a value. In some cases different instances (and therefore the values) of
variables are merged into a single instance. This means that the variable has the same value in all the objects
involved. This happens, for example, when a variable is used in two different queries. However, this is only the
exception.
Features
Variables help you to flexibly set or parameterize your objects. The following objects support the use of
variables:
Object Using Variables
Queries (especially input-ready queries) ● To parameterize characteristic restrictions in the query

● In formulas, conditions, exceptions
● As placeholders for texts
When a query is started, variables can be assigned using a

default value or values entered by a user.
Filter To parameterize characteristic restrictions that describe the

filter.
Planning Functions To parameterize conditions and parameters, for example, to

parameterize the conversion factor in planning functions of
type Conversion.
Variables can be assigned to values using a pre-defined

value or a command in the application:
Characteristic Relationships To parameterize the hierarchy used
Data Slices To parameterize characteristic restrictions that describe the

data slice.
Variables that are used in characteristic relationships and data slices must have a pre-defined value when the
query is executed.
Times of Variable Calls
The different ways in which variables are used result in different times at which variables are executed and at
which they are assigned new values.
Planning Concepts
Use Time of Variable Call
Query 1. The variable is processed each time the application is

restarted.
2. When the Change Values for Variables is called. This
forces the query to be restarted.
If you end the Variables Screen with OK, the value of the
variable does not change if you have not made any ac
tive changes. In the case of input-ready variables of type
Exit, this means that the Exit is not executed. This en
sures that the default value in the dialog box is rede
fined (since it could overwrite the value that is already
defined). Variables in the area of the default values and
variables for defining the presentation hierarchy take on
the value of the current filter state of the characteristic
or the currently defined presentation hierarchy.
Explicitly set variable values have priority over implicitly
set variable values.
Planning function When excecuting the planning function
Explicitly set variable values have priority over implicitly set

variable values. This results in the following conditions for
defining the priority when filling a variable:
1. Is the variable set explicitly in the command?

2. Is there a default value?
Planning sequence See Planning Function
Filter in planning sequence Every time the planning sequence is executed
Data slice The first time it is called
You cannot change data slices by changing variables.
 Note
It must be possible to replace variables used in data sli
ces automatically.
Characteristic relationship See Data Slice
Merging Variables
If there are two variables with the same name in two different objects, the system creates instances of these
variables. From then on there are physically two variables. In certain constellations, the system automatically
merges these instances so that all variable instances have the same value.
Constellation Merge
Variables with same name in two queries Yes
Planning Concepts
Constellation Merge
Variables with same name in planning function and query Depends on client
Variables with same name in planning sequence and query See Planning Function
Filter and planning function within a planning sequence Yes
Data slice or characteristic relationship with any other object No
1.6 Planning Functions
Planning functions allow system-based processing or generation of data.
Use
A planning function describes how the transaction data of a specific aggregation level is changed. This entails
making a number of settings:
● The name of the aggregation level

● The planning function type
● How characteristics are used
● The parameter values
The planning function type determines how data is changed by a planning function. SAP offers you a number of
standard planning function types [page 40]:
● Unit Conversion
● Generate Combinations
● Formula
● Setting Key Figure Values
● Copy
● Delete
● Delete Invalid Combinations
● Forecast
● Repost
● Repost by Characteristic Relationships
● Revaluation
● Distribute by Reference Data
● Distribution by Keys
● Currency Translation
You can also implement customer-specific planning function types.
Planning Concepts
Prerequisites
The system contains the following objects:
● Aggregation levels that planning functions are created on. Planning functions can be created and
executed on each active aggregation level.
 Note
If a function related to data from a DataStore object runs on an aggregation level containing
InfoProviders that are updated with deltas (such as a data mart DataStore object), the key figures are
only set to zero. This affects the following planning function types:
○ Delete DSO Records

○ Physically Delete Invalid Data in the DSO
○ Repost DSO Data and Physically Delete Source Data
○ Repost DSO Data on the Basis of Characteristic Relationships
Note that you cannot create all types of planning functions on aggregation levels, which contain
characteristics used as key figures. The following planning function types are supported:
○ Delete DSO Records
○ Generate Combinations
○ Copy
○ Copy (Ignore Zero Records)
○ Delete
○ Repost
○ Repost DSO Data and Physically Delete Source Data
● Filters that are required when the planning function is executed. A filter determines the data that the
planning function is performed for. The planning function locks the data defined in the filter in the planning-
relevant InfoProviders belonging to the aggregation level. The filter has to be defined on the same
aggregation level as the planning function.
Features
You determine the planning function type and the aggregation level that you want the planning function to work
on. You can also change the characteristic usage, the conditions and the parameter sets. You can define how
the changed data will be processed.
The following section explains the functionality using an example of creating a planning function of type Repost.
The table below shows the data for the InfoProvider before the planning function is executed:
Before execution of the planning function
P1 PG1 V1 2017 10
Planning Concepts
P2 PG1 V1 2017 20
All records in version V1 need to be reposted to version V2. You can do this by reposting all key figures. The
table below shows the status after the planning function has been executed:
After execution of the planning function
P1 PG1 V1 2017 0
P2 PG1 V1 2017 0
P1 PG1 V2 2017 10
P2 PG1 V2 2017 20
After reposting, records that contain zeros only (empty records) remain in V1, while the required records
appear in V2.
Characteristic Usage
The planning function type defines the options for using characteristics and the parameters of the planning
function. Together, the parameters of the planning function type define the parameter set.
With characteristic usage, the characteristics of the aggregation level are divided into Characteristics to Be
Changed and Block Characteristics (characteristics that are not used). This allows you to specify the
characteristic values that are changed when the planning function processes a data record. Block
characteristics remain constant.
 Example
When you create a planning function of type Repost for the case described above, you first check which
characteristic values should be changed and set the to be changed flag accordingly. Since you want to
repost the data from version V1 to version V2, you set the flag for the Version characteristic as To Be
Changed (which in this case means to be reposted).
You can also select block characteristics as condition characteristics.
Parameter Sets and Conditions
You can now change the parameter records. With most planning functions, all transaction data is processed
with the same set of parameters. In this case, a block characteristic has not been selected as a condition
characteristic, and only one parameter set has to be entered.
 Example
The parameter set for planning function type Repost includes a table for selecting the key figures to be
reposted and a table where you can enter the From-To Value Pairs for the characteristics to be reposted. In
key figure selection, you set the flag for Select All Key Figures. In the From and To Values for Reposting table,
you choose Create Row and enter the value V1 under From and V2 under To. The planning function is ready
for reposting.
Planning Concepts
If you want to use different parameter sets to execute different transaction data records, you have to work with
conditions. You have to select at least one block characteristic as a condition characteristic.
 Example
If you want to increase the planned production for products in product group PG1 by 5% and the products
of product group PG2 by 10%, choose the product group as the condition characteristic.
In the parameters, you can create multiple pairs of conditions and parameter sets. For each pair, use a filter to
select condition characteristics. You can change the associated parameter set for each pair.
 Note
From a technical viewpoint, the method that the planning function actually executes is called more than
once. The data that was selected with the filter is divided into blocks. Each combination of characteristic
values in the block characteristic forms a separate block (which explains the name block characteristics).
Planning function types that work with reference data can also have additional blocks (such as Copy). The
method is then called once for each block with a table of records. The table includes data records that
correspond to the characteristic combination for the block in the block characteristics.
For each block, the system checks for a condition/parameter set pair so that the block meets the condition.
The system tests the block against the conditions along the sequence of pairs. The system uses the first
pair where the block meets the condition. The method for the planning function type is executed for the
block and the parameter set that meets the condition. Subsequent pairs are ignored. The method is
therefore executed just once for each block.
Variables in Planning Functions
The usual SAP BW∕4HANA variable types are available in many planning function types (see Variables [page
29]).
Working with Empty/Zero Records
Almost all planning function types do not read empty/zero records and do not write these to the buffer. Copy
and Generate are exceptions: both of these types read and write empty/zero delta records.
The function type Formula with Processing of Zero Records (0RSPL_FORMULA_ZERO) can also process records
in which all key figures are zero (empty records).
Processing Changed Data
The selected planning function type determines whether the planning function processes the data in blocks or
processes all the data at once. A planning function, that processes data blocks, can be parameterized so that
blocks (or a small superset) are only processed, if they contain data that has been changed by the user in the
same session. These planning functions only process small quantities of data. This significantly reduces the
runtime.
Here the user may have changed data in the filter or data that is used as reference data.
 Example
An example of this is the copy function that copies data from version V1 to V2. In this example, the data
blocks are constructed so that all the data is grouped into blocks that have the same characteristic value in
all characteristics (except in the version characteristic). The reference data originates from version V1. The
Planning Concepts
data to be changed is in version V2. The function only processes the blocks in which data from version V1 or
version V2 has been changed.
With a planning function, the filter defines the data that is allowed to be changed. You can tell from the
parameters which reference data is required. Now the changed data is also read. The characteristic values of
the block characteristics are collected for every changed data record in the filter and in the reference data.
These values replace the original selection. This procedure may mean that more data blocks are processed
than necessary. However, this should not change the result of the planning function.
The changes made since the data was last saved are processed.
The system usually determines on the aggregation level of the planning function which data has been changed.
It is also possible to specify a different aggregation level, for example the aggregation level of the query that
was used to change the data.
 Note
The behavior can also be configured for a planning sequence.
 Recommendation
We recommend that you use the setting, where only blocks with changed data are processed, in the
following scenario:
At the start of the session, the user's data is in a consistent state. This is guaranteed by the administrator.
During the session, the user changes some of the data. The user then executes planning functions that
check whether the data is consistent or perform calculations that convert the data to a consistent state.
Planning functions can be used where the data is not changed from the second execution onwards. The
filter should be restricted so that it includes data that the user is allowed to edit during the session. The
planning function should be able to edit all data. The way that the selection is made ensures that the
system always processes the smallest possible quantity of blocks. However, it may be the case with the
resulting intersections that a quantity larger than the minimum quantity is processed.
The filter of the planning function should not contain any variables that change during the session.
Otherwise, the system might only process changed data with the previous variable assignment in the filter.
Therefore there is a danger that not all of the changed data is recorded.
It is advisable to set this type of planning function for the Save pushbutton, as changes are only stored up
to the previous save.
Related Information
Process Flow of Planning Function: Distribution by Key [page 37]

Standard Planning Function Types [page 40]
Creating Planning Functions [page 179]
Implementing a Planning Function Type [page 106]
Planning Concepts
1.6.1 Process Flow of Planning Function: Distribution by Key
The data of an InfoProvider can be changed by using a planning function of type Distribution by Key. A step by
step guide is displayed to show how the system works during process flow of the planning function.
Use
For year “2017“, version "V1", you want to distribute the planned quantity for each product to the available
factories "W1" and "W2". The total quantity of each product stays the same. However, you want to distribute the
total evenly between the factories.
The table below shows the data for the InfoProvider before the planning function is executed:
Year Version Product Plant Quantity
2017 V1 P1 W1 10
2017 V1 P1 W2 20
2017 V1 P2 W1 60
2017 V1 P2 W2 40
The following table shows the result after the planning function has been executed:
2017 V1 P1 W1 15
2017 V1 P1 W2 15
2017 V1 P2 W1 50
2017 V1 P2 W2 50
The planning function only writes delta records to the InfoProvider. The following table shows the delta records
that were actually written:
2017 V1 P1 W1 5
2017 V1 P1 W2 -5
2017 V1 P2 W1 -10
2017 V1 P2 W2 10
Planning Concepts
Creating the Planning Function
When you create the planning function, you first have to specify the characteristics in which the values change.
With regard to the characteristics Year, Version and Product, the total of the values should not change; these
characteristics remain constant and become block characteristics. The key figure values are distributed using
the characteristic values. Therefore, in characteristic usage, you have to select the Factory characteristic and
set it to to be changed.
The parameters for the distribution function are set as follows (see Distribution by Key [page 92]).
● Use the table for key figure selection to specify that the only key figure to be distributed is the Quantity key
figure.
● Because the total sum is always to be distributed each time within a block (characteristic combination
{year, version, product}), the distribution type Top Down Distribution is applied with the setting Distribute
All.
● The factories "W1" and "W2" are entered as To values and receive identical keys (such as 1).
Process Flow of the Planning Function
You want to execute the planning function with a filter that is restricted to year “2017” and version “V1”. The
planning function executes the following steps:
1. First the system loads the filter and the planning function.
2. It replaces the variables.
3. It checks the filter and the planning function for consistency.
4. Using the filter, the system requests the selected data and loads it into the buffer. In this example, we
assume that the records displayed above in the "before execution of the planning function" table are
selected by the filter and transferred to the planning function. Whether the system reads or ignores the
existing empty records depends on the type of planning function. In the case of the distribution function
type, the system does not read empty records.
5. Based on the characteristic usage, the system divides the transaction data into blocks. This can be seen in
the tables below the process flow. Two blocks are created. They are defined by the characteristic
combinations shown here.
Block No. Year Version Product
1 2017 V1 P1
2 2017 V1 P2
6. For each block, the system uses the characteristic combinations to look for the correct parameter set from
the condition/parameter set pairs. Since no conditions were created in this example, both blocks are
executed with the only available parameter set.
7. The system runs the actual process (distribution, in this case) for each block. The tables after the process
flow show the before-after values and the resulting delta records for each block.
8. Depending on the type of planning function, the system either processes any empty records that it finds or
ignores them. In this example there are no empty records.
9. The system checks
○ Whether the resulting records are consistent with regard to master data and characteristic
relationships.
○ Whether they are protected by data slices.
Planning Concepts
○ Whether they are located within the transferred filter.
For performance reasons, the system does not check all the characteristic relationships. It only checks the
relationships that relate to characteristics to be changed. This is possible because the system assumes
that the records read from the database satisfy the characteristic relationships and that errors can only
occur in connection to the fields to be changed. Incorrect records should be deleted or reposted to valid
combinations. To do this, you can use the planning function types Delete Invalid Combinations or Repost by
Characteristic Relationships.
 Note
If a planning function is working with zero records (for example, planning function type Copy), the
system checks all possible characteristic relationships because the relevant record may have been
canceled.
10. Once the system has successfully processed all blocks, it writes the delta records it has collected back to
the buffer. Derivation is performed in the buffer, as required (see Characteristic Relationships [page 9] and
Aggregation Levels [page 22]).
 Note
If one of the generated records is inconsistent, the entire planning function writes nothing to the buffer.
Overview: Block 1
2017 V1 P1 W1 10
2017 V1 P1 W2 20
2017 V1 P1 W1 15
2017 V1 P1 W2 15
2017 V1 P1 W1 5
2017 V1 P1 W2 -5
Overview: Block 2
2017 V1 P2 W1 60
2017 V1 P2 W2 40
Planning Concepts
2017 V1 P2 W1 50
2017 V1 P2 W2 50
2017 V1 P2 W1 -10
2017 V1 P2 W2 10
1.6.2 Standard Planning Function Types
The standard planning function types are part of the system. When using a standard planning function type for
a particular aggregation level, you have to define a planning function of this type.
Use
SAP delivers the following standard planning function types:
● Uploading Files [page 41]

● Unit Conversion [page 42]
● Generate Combinations [page 42]
● Formula [page 43]
● Formula with Processing of Zero Records [page 70]
● Set Key Figure Values [page 70]
● Copy [page 71]
○ Copy (Ignore Zero Records) [page 72]
● Delete [page 72]
○ Delete DSO Records [page 73]
● Delete Invalid Combinations [page 73]
○ Physically Delete Invalid Data in the DSO [page 74]
● Forecast [page 74]
● Displaying the Log of a Process Chain [page 87]
● Start Process Chain [page 88]
● Start Process Chain [page 88]
● Repost [page 88]
○ Repost DSO Data and Physically Delete Source Data [page 89]
● Repost by Characteristic Relationships [page 89]
Planning Concepts
○ Repost DSO Data on the Basis of Characteristic Relationships [page 90]
● Revaluation [page 90]
● Distribution by Reference Data [page 91]
● Distribution by Keys [page 92]
● Currency Translation [page 93]
1.6.2.1 Uploading Files
You can use planning functions of type (File Upload from AO, 0RSPL_FILE_UPLOAD_AO) to upload CSV files
from your local device to your SAP Analysis for Office application Version 2.7 or higher. When a planning
function of this type is executed, a dialog box appears where you can select a file. This is then transferred to the
back end and further processed.
If you edit the planning function, you first need to define file settings that describe the format of the data in the
CSV file. These are as follows: Separator (CSV), field separator character, date format, and decimal notation.
Further settings affect the overwrite mode and the existence of duplicate records in the file:
● In overwrite mode, you can specify whether existing data is completely overwritten (O= OVERWRITE),
merely updated (U = UPDATE) or added (C = COLLECT).
● In the check for duplicate records, you can specify that detection of such records generates an error
message (X) or that the key figures of the records are added together (# or space).
It is also necessary to specify which row the data in the CSV file begins in.
There can be mapping information before the first row with data. The mapping information is the name of an
InfoObject in a column. Under (Map InfoObjects to File Columns)), you can specify which row the mapping
information is contained in. A table with the assignment of column number in the file and the name of the
InfoObject can also be edited here.
Under (Filter Values from File)), you can synchronize the data in such a way that the values in the filter are
exactly those that are in the file. This ensures that only data that is in the file is overwritten. For characteristics
that are selected here, the single values are read from the file and added to the filter. The total number of single
values is limited to 100 in order to prevent too many locks from being set.
You can use the BADI BADI_RSPLFA_FILE_UPLOAD to programmatically customize the CSV file.
You can also include a planning function of type File Upload from AO in a planning sequence.
Related Information
Planning Concepts
1.6.2.2 Unit Conversion
Use
You use function type Unit Conversion to convert units of key figures into other key figures using unit
relationships.
In the Source/Target Key Figure Conversion Type table, you can enter multiple conversions. For each
conversion, you have to select the unit or quantity conversion type. The value in the target key figure is
overwritten. This also applies if the source key figure is empty. The value of the source key figure is not changed
during unit conversion. This means that the function can be executed more than once without the results
changing. A special logic ensures this if the source key figure and target figure are identical, and the source unit
of the data record is used: If the target unit already contains a value, this is ignored if the source unit contains
values that do not have the target unit. Otherwise the value in the target unit is used.
With this function, only the unit fields can be characteristics to be changed.
1.6.2.3 Generate Combinations
Use
You use the Generate Combinations function type to generate empty records in an aggregation level for all
permitted combinations according to the master data and characteristic combinations. These are the
combinations that are valid during the check on this aggregation level.
This function type does not allow any additional settings. Since new data records are continuously generated
for the whole aggregation level, all characteristics must have status to be changed. The function type therefore
works without block characteristics.
The function type writes empty records (like with Copy).
Related Information

Copy [page 71]
Planning Concepts
1.6.2.4 Formula
The planning function type Formula provides you with a simple programming language for manipulating
transaction data.
As in many other macro languages for business applications, it contains the following components:
● Variable concept including DATA statement for data declarations and help variables
● Expressions
● Operations and functions
● Conditional statements
● Loop constructs
● Notification output
● Calling function modules
● Internal tables
● Subroutines
● INCLUDE of Formulas
● Accessing InfoProviders
● Comment function
You can use line notes, the starter mark (at the start of the line) is '*'.
 Note
By using SAP HANA-optimized processing in SAP Business Planning and Consolidation, version for SAP
BW/4HANA, (embedded configuration) you can achieve far better performance, especially in the case of
planning functions of type formula. See SAP Note 1637199 .
Related Information
Internal Data Objects [page 44]

Reference Data [page 44]
Formula or User-Defined Planning Function Type? [page 47]
Data Declaration [page 48]
Expressions [page 49]
Operators and Functions [page 50]
Conditional Statements [page 56]
Loop Constructs [page 57]
Notification Output [page 59]
Calling Function Modules [page 60]
Internal Tables [page 61]
Subroutines [page 61]
INCLUDE of Formulas [page 62]
Accessing InfoProviders [page 63]
Examples of Formula Applications [page 64]
Planning Concepts
1.6.2.4.1 Internal Data Objects
A formula is normally executed multiple times, once for each internal data object:
When you execute a planning function, first select a filter. This filter describes a set of transaction data. The set
of transaction data is divided into smaller data objects. If a formula needs reference data, these data objects
are also formed directly from this reference data.
 Caution
If no data objects can be formed, no formulas are executed.
The only difference between the data objects is the characteristic values of the characteristics to be changed.
The values of the other characteristics are the same. If no characteristics are selected for changing, the
formula is executed once for each transaction data record. Each key figure value in the data object can be
addressed uniquely by entering the characteristic values of the characteristic to be changed and the key figure
name and can be changed using functions.
 Note
To better understand how to work with a formula, you can define a query where all the characteristics to be
changed are in the lead columns, and the remaining characteristics are in the header. The formula is then
processed for all combinations. You might have to add columns with reference data to the query.
 Recommendation
We recommend limiting as far as possible the values in the filter relating to the characteristics in the
formula that are not to be changed, so that few data objects are created.
 Note
For planning functions of type Formula, a debugging script Script (RSPLFC_DEBUGGING_SCRIPT_FOX)

can be used to analyze formulas.
Related Information
1.6.2.4.2 Reference Data
Access to Reference Data
You have two possibilities for accessing reference data:
Planning Concepts
1. The field you take to change is the field where the reference data for the data in the active planning filter is
different, version (0VERSION) for example. You then write the operands as follows:
{ REVENUE, 002 } = { REVENUE, 001 }.
If there is no data in version 002, the internal data objects are formed from the data from version 002 and
version 001. When the formula is executed, data is created in version 002.
This syntax is intended for formulas for creating new data from reference data.
2. You address reference data explicitly. To do this, you enter the name of the characteristic and the value in
the operand:
{ REVENUE } = { REVENUE | 0VERSION = 001 }.
The formula will only run for records in version 002, as it is not possible to tell from the formula how the
records from version 001 should be transformed into records from version 002. If no records are found, the
formula does not run. No records are created.
The syntax is intended for formulas that need reference data to evaluate existing data.
 Example
In the following example, the data from version 002 is in the active planning filter. The formula is run for
each record of the active filter. As there are no fields to be changed, the data objects consist of one
record.
0VERSION 0COSTCENTER REVENUE
001 4711 3
001 0815 2
002 4711 9
The following table shows the results from: { REVENUE, 002 } = { REVENUE, 001 }.
001 4711 3
001 0815 2
002 4711 3
001 0815 2
The following table shows the two data objects that are formed by using the formula:
0COSTCENTER
4711
0815
The following table shows the results from: { REVENUE } = { REVENUE | 0VERSION = 001 }.
Planning Concepts
001 4711 3
001 0815 2
002 4711 3
The following table shows the data object that is formed by using the formula:
0VERSION 0COSTCENTER
002 4711
Before executing the parameter group, the system uses the formula to ascertain which reference data
is required. For the reference data selection, the original selection is added to. If the planning filter only
contains data from version 002 for example, "Version 001" is added to the selection in accordance with
formula row { REVENUE, 002 } = { REVENUE, 001 }..
Deleting the Selection
The system cannot always decide which reference data is required before starting a planning function of type
Formula. If this is the case, the system deletes the selection. This can occur in the following cases:
● Function TMVL is used to change the value of a time characteristic

● Function ATRV or ATRVT is used to read attribute values
● Calling Function Modules
The selection can then only be deleted if the results of the function for addressing reference data have been
used. Example:
 Sample Code
DATA FISCPER TYPE 0FISCPER.

DATA ACTPER TYPE 0FISCPER.
ACTPER = VARV( AKTPERIO ).
FISCPER = ACTPER.
FISCPER = TMVL( FISCPER , -12 ).
{ ERLOES, ACTPER } = { ERLOES, FISCPER }.
In this example, formula variable ACTPER is filled from global variable AKTPERIO. This value is then assigned to
the FISCPER variables. Function TMVL is then used to reduce the value of ACTPER by 12. Finally, the value of key
figure ERLOES in period FISCPER is assigned to the value of key figure ERLOES in period ACTPER.
There are cases in which you want to have the selection, even if the reference data cannot be currently read for
a specific reason (for example, you would need to read data for which you have no authorization). You can
influence the selection of the reference data by using the KEEP and the ENHANCE statement.
● By using the KEEP statement, you can prevent the system from deleting the reference data:
Planning Concepts
KEEP REFDATA SELECTION FOR 0FISCPER.
● To explicitly request additional reference data, you can use the ENHANCE statement:
ENHANCE REFDATA SELECTION FOR 0FISCPER: 2015001, 2016001, #.
You can also use global variables in this list:
ENHANCE REFDATA SELECTION FOR 0FISCPER: 2015001, VARIABLE FISCPERVAR.
To request all available data that corresponds to the deletion of the filter, write the following:
ENHANCE REFDATA SELECTION FOR 0FISCPER: *.
You can use navigation attributes in the KEEP statement and in the ENHANCE statement. Navigation attributes
are noted as follows: basic characteristic name, followed by two underscores and the name of the attribute. For
example: 0MATERIAL__0GROUP.
Related Information
Accessing InfoProviders [page 63]
1.6.2.4.3 Formula or User-Defined Planning Function Type?
In addition to using function type Formula, you can also create your own planning function types to manipulate
transaction data using a programming language. Weigh up the following points to decide which function type to
use.
● Planning functions of type Formula are not difficult to learn for end-users in controlling for example, who
can already use an algorithmic programming language or a macro language and can solve the majority of
problems with the formula language.
● You therefore always need to write your own planning functions if you need new features.
 Example
To calculate costs, it is necessary to access customer-specific tables. You need a special function to
access formulas in all tables.
● Function modules can be called in formulas. This means part of the logic can be in function modules and
part in formula logic.
● Generally, every planning function type you create yourself will run more efficiently than the formula
calculation. The main reason for this is that more complex formulas read every operand and result
separately from an internal table. If you write your own program, you would of course optimize this. This
performance perspective is a major deciding factor for larger amounts of data.
Related Information
Formula [page 43]
Planning Concepts
1.6.2.4.4 Data Declaration
A declaration is a definition of aspects of a variable. Data declarations are initiated with the word DATA, followed
by the name of the help variable.
Use
The name of a data declaration must start with a letter and can contain alphanumeric characters, but no
special characters.
Variable names must be different to keywords like DATA, ELSEIF or SIN.
 Example
DATA HELPVAR TYPE I.
DATA KEYRA TYPE KEYFIGURE_NAME.
 Caution
If new key words are added to the formula syntax at a later point in time, any variables with the same name
will become invalid.
 Recommendation
To avoid errors, we advise you not to name variables like characteristic values or to enclose characteristic
values in quotation marks.
The following variable types are available:
● I (Integer Numbers) for index operations

● F (Floating Point Numbers) for calculations
● D (Date) for date calculations
● STRING
● Variables of the same type as the characteristics to be changed.
The technical name of a characteristic serves as the type description here. If you want to set key figure
names using variables, you can also define variables of type KEYFIGURE_NAME. You can view the valid data
types by choosing Data Types.
If the type name contains special characters such as @ or &, the entire name must be enclosed in single
quotation marks.
You can also create data types for attributes. If the attributes are of type “Key Figure”, you have to create help
variables of type F or I for them. If you want to read attribute values with function ATRV, you need the technical
name of the attribute.
You can also use any InfoObjects of your choice for data definition, even if these InfoObjects does not belong to
the aggregation level.
Planning Concepts
 Example
DATA COSTCTR TYPE 0COSTCENTER
This is possible even though 0COSTCENTER in this example does not have any relation to the aggregation
level.
1.6.2.4.5 Expressions
The following section provides you with an overview of which components you can use in expressions.
● Constants, made up of digits and a decimal point.

● Variables that you have declared with the DATA statement.
● Operands that you can select using the input help.
○ If characteristic values appear in operands that are not addressed using the key figure name, operands
have to be enclosed in curly brackets { and } so as to avoid operands being confused with constants. If
no characteristics have changed, you can add the key figure name as an operand without parentheses.
The system shows the valid syntax and, in particular, the correct order of characteristics above the
editor. Using the input help you can easily combine valid operands.
○ If the characteristic values in operands contain blanks or symbols such as +, -, *, the characteristic
values have to be enclosed in apostrophes.
○ There is an internal and external format for each characteristic value. Date values are shown externally
as 3.12.1963 and internally as 19631203 for example. Always use the internal format in formulas. In
operands, you can also use variables instead of characteristic values.
○ If key figure name is the only characteristic to be changed, and you have defined a variable of type
KEYFIGURE_NAME to be able to change key figures, you also have to enclose this in curly brackets. The
following statement sets all flags to 1. Construct FOREACH fills variable KENNZ with all key figure names
of the key figures on this level:
 Sample Code
DATA KENNZ TYPE KEYFIGURE_NAME.

FOREACH KENNZ.
{ KENNZ } = 1.
ENDFOR.
● Operators
● Functions with either one, several or no operands
Related Information
Data Declaration [page 48]

Operators and Functions [page 50]
Planning Concepts
1.6.2.4.6 Operators and Functions
Use
You can use a series of operators and mathematical functions to calculate key figures.
Functions can work with either one operand, multiple operands or without any operands at all. If no special
operators are specified, you can also specify constants alongside the valid operators.
The operands Interest Rate and Percentage are given in percent, 10% as 10 therefore, not as 0.1.
 Note
All functions return a simple score, no time series. With a depreciation, it would be preferable to get a time
series with the depreciations. To achieve this, you have to fill a formula for each time period.
Related Information
Mathematical Operators [page 50]

Relational Operators [page 51]
Logical Operators [page 51]
Functions with One Operand [page 52]
Functions with Two Operands [page 53]
Functions with Three Operands [page 54]
Functions with Four Operands [page 55]
Function with Five Operands [page 55]
Function Without Operands [page 55]
1.6.2.4.6.1 Mathematical Operators
Mathematical Operator Meaning
+ or - Used as a sign (single-figure operators)
+ Addition
- Subtraction
* Multiplication
/ Division
Planning Concepts
Mathematical Operator Meaning
DIV Integer division
MOD Modulo operation
** Raise to a power
1.6.2.4.6.2 Relational Operators
Relational Operator Meaning
> Greater than
< Lesser than
>= Greater than or equal to
<= Less than or equal to
= Equal to
<> Not equal to
Relational operators are used for conditional statements.
Related Information
Conditional Statements [page 56]
1.6.2.4.6.3 Logical Operators
Logical Operator Meaning
AND And
OR Or
NOT Not
Planning Concepts
1.6.2.4.6.4 Functions with One Operand
Function Meaning
CEIL Smallest integer that is not smaller than x
FLOOR Largest integer value that is not greater than x
TRUNC Integer part of x
FRAC Decimal part of x
ABS Amount (absolute value) |x| of x
SIGN Sign of x
ACOS Arccos(x) in area [-pi/2, pi/2], x from [-1, 1]
ASIN Arcsin(x) in area [0, pi], x from [-1, 1]
ATAN Arctan(x) in area [-pi/2, pi/2] (pi = 3.1415926535897932)
COS Cosine of an angle specified in radian measure.
SIN Sine of an angle specified in radian measure.
TAN Tangent of an angle specified in radian measure.
COSH Hyperbolic cosine
SINH Hyperbolic sine
TANH Hyperbolic tangent
EXP Exponential function for basis e = 2.7182818284590452
LOG Natural logarithm (i.e. for basis e)
LOG10 Logarithm from x for basis 10, x > 0
SQRT Square root of a non-negative number
STRLEN Length of a string
VARV Variable value (argument = variable name)
VARC Number of values of a variable (argument = variable name)
DECIMALS Decimal places (argument = key figure name)
CONVERT Converts all letters preceded by ! into lowercase letters
Planning Concepts
 Note
The CONVERT function converts all letters preceded by a ! character in your argument into lowercase
letters. If the argument already contains a ! character, this must in turn be preceded by a further !
character. The function is needed because formulas are automatically converted into uppercase letters
during editing.
1.6.2.4.6.5 Functions with Two Operands
Function Meaning Operand1; Operand2
MAX Maximum
MIN Minimum
ATRV Read attribute Attribute type; Variable
TMVL Read time characteristic Value; Offset
PERP Perpetual bond Key figure; Interest rate
The unit for the Interest Rate operand is

percent (10% is represented as 10, not
as 0.1)
C2DATE Determine date Time characteristic;'S'tart value/'E'nd

value
Enter S or E for the start or end value of

a period
CONCAT Concatenate operands <Operand1>; <Operand2>
VARI N-th variable value Variable, Index
ROUND Rounding Key figure; Decimal places
 Note
● The PERP function calculates the perpetual bond from a capital stock using the following formula:
Result = Key figure value * ( interest rate / 100 )
● In the C2DATE function, entries have to be made for the end value E and the start value S of a period.
Planning Concepts
1.6.2.4.6.6 Functions with Three Operands
Function Meaning Operand1; ... ; Operand3
DISC Discounting Key figure; Interest rate; Years
Formula for discounting an amount: Re

sult = key figure value / ((1 + interest
rate / 100) ** years)
DECD Declining-balance depreciation Start value; Percentage; Years;
This functions calculates according to

the following algorithm:
1. "Perform [number of years] times:

Intermediate value = intermediate
value + (start value - intermediate
value) * percentage / 100"
2. Result = start value - intermediate
value
ATRVT Read time-dependent attribute Attribute type; Variable; Date
SUBSTR Read substring Variable; Offset; Length
REPLACE Replace character Source string; Pattern; Replacement
 Note
● Function DISC discounts an amount according to the following formula:

Result = key figure value / ( ( 1 + interest rate / 100 ) ** years )
● Function DECD calculates a declining-balance depreciation according to the following algorithm:
1. Perform [number of years] times.
Intermediate value = intermediate value + ( start value - intermediate value ) * percentage / 100.
2. Result = start value - intermediate value
Planning Concepts
1.6.2.4.6.7 Functions with Four Operands
DECL Straight-line depreciation Start value; Net book value; Percentage;

Years;
Straight-line depreciation is calculated
using the following formula: Result = Display for operand Percentage: 10% as
start value - ((start value - rest value) * 10, not as 0.1
percentage / 100 * years).
 Note
Function DECL calculates a straight-line depreciation according to the following formula:
Result = start value - ( ( start value - rest value ) * percentage / 100 *

years )
1.6.2.4.6.8 Function with Five Operands
CURC Currency conversion Amount; Date; Exchange rate type;

Source currency; Target currency
 Note
Function CURC converts an amount into a target currency. Note that minor rounding differences can occur
when using floating point-type key figures, as nine decimal places are calculated internally.
1.6.2.4.6.9 Function Without Operands
Function Meaning
OBJV Read characteristic value
Planning Concepts
1.6.2.4.7 Conditional Statements
Use
You create conditional statements using an IF statement. Further conditional statements can follow an IF
statement in an ELSEIF statement. The ELSE statement is for dealing with the remaining cases within a chain
of conditional statements. The schema is as shown in the following example.
 Example
IF <Expression1>.
<Statement1>.
ELSEIF <Expression2>.
<Statement2>.
ELSE.
<Statement3>.
ENDIF.
Expressions in the IF statement consist of operands, variables and constants, relational operators and logical
operators (see Operators and Functions [page 50]).
 Note
Note that constants can only be positioned to the right of a comparison operator.
 Example
To check the special case of whether an operand <oper1> has the initial value, you can write:
IF <oper1> IS INITIAL. or IF <oper1> = '#'.
 Example
Example of a construction with logical operators: IF NOT <oper1> < <oper2> AND <oper3> =
<oper4> OR <oper5> > <oper2>.
Working with Character-Type Operands
You can use the following operators when working with character-type operands.
Operator Meaning in Expression
CP ( C ontains P attern) The whole of string c1 matches pattern c2.
Wildcards can also be contained in pattern c2 where '*' stands for a

string and '+' for a symbol.
Planning Concepts
Operator Meaning in Expression
CO ( C ontains O nly) c1 only contains characters from character set c2 .
If c1 or c2 is of internal type C, the complete length of the field is in

cluded in the comparison, meaning that means blanks at the end are
also taken into account.
If c1 is of type STRING and is empty, the result of the comparison is

always positive.
If c2 is of type STRING and is empty, the result of the comparison is

always negative unless c1 is also an empty string.
CA ( C ontains A ny) c1 contains at least one character from character set c2.
If c1 or c2 is of internal type C, the complete length of the field is in

cluded in the comparison, meaning blanks at the end are also taken
into account.
If c1 or c2 is of type STRING and is empty, the result of the compari

son is always negative.
CS ( C ontains S tring) c1 contains character string c2. If the relevant field is of type C, the
final blanks in c1 and c2 are ignored.
An empty c2 string (only blanks for type C or an empty string for

type STRING) is contained in any c1 string and in the string itself.
Otherwise there is no non-empty character set c2 in an empty char
acter string c1.
1.6.2.4.8 Loop Constructs
Use
DO Loops
● Statements between DO and ENDDO can be repeated an unlimited number of times.

● The loop is interrupted by the EXIT statement.
● The number of loop passes can also be controlled by a constant or a variable of type I. DO <n>TIMES.
FOREACH Loops
● The FOREACH <Variable>. statement uses all the values of a variable for iteration. The characteristic
values concerned are the ones in the transaction data of the current data object (therefore not necessarily
all the master data values defined for this characteristic). This loop construct is completed with the
ENDFOR statement.
● The characteristic values are processed in ascending order. If you need combinations of characteristic
values, you can implement the statement in the form FOREACH <Variable1,Variable2>.. This
construct delivers the existing combinations of characteristic values for the current data object.
Planning Concepts
 Note
Comments on runtime behavior: Before entering the FOREACH loop, all characteristic values in the
data object are collected and sorted. They are then delivered in the FOREACH loop one after the other.
If a new value is created in the loop and written to the transaction data, this is not taken into account
until the next FOREACH loop.
The FOREACH construct requires a lot of processing time and should be used sparingly. Always
consider the alternative of using a construct of type FOREACH <Variable1, Variable2>. instead
of two nested loops. This would improve system performance at runtime.
● Further variants of the FOREACH loop:

○ FOREACH <Variable> IN REFDATA uses all characteristic values in the reference data for iteration
○ FOREACH <Variable> IN SELECTION uses all characteristic values in the active planning filter for
iteration.
○ FOREACH <Variable> IN VARIABLE Var uses all characteristic values in a global variable (Var) for
iteration.
Example
The following is an example of a badly designed program:
 Sample Code
DATA COUNTRY TYPE 0BPS_CNTRY.

DATA PRODUCT TYPE 0BPS_PRODU.
FOREACH COUNTRY.
FOREACH PRODUCT.
FOREACH FISCPER.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY, PRODUCT,
FISCPER} * 2.
ENDFOR.
ENDFOR.
ENDFOR.
The following is an example of better program design: Note that that new values are only generated if they are
not equal to zero. Values that can occur in variables PRODUCT and FISCPER do not have to be refreshed, thus
saving a considerable amount of time during calculation. Values are only refreshed if the loops FOREACH
PRODUCT. and FOREACH FISCPER. both run again. If a formula generates zero values, the system does not
write these back to the internal buffer. These zero values are not visible in subsequent planning functions or in
manual planning. This also means that the value 0 is not assigned to existing data. Zero values do not therefore
have to be generated explicitly.
 Sample Code

FOREACH COUNTRY.
FOREACH PRODUCT.
FOREACH FISCPER.
Planning Concepts
IF {REVENUE, COUNTRY, PRODUCT, FISCPER} <> 0.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY,
PRODUCT, FISCPER} * 2.
ENDIF.
ENDFOR.
ENDFOR.
ENDFOR.
The following is an example of the recommended program design:
 Sample Code

FOREACH COUNTRY, PRODUCT, FISCPER.
IF NOT {REVENUE, COUNTRY, PRODUCT, FISCPER} IS INITIAL.
{REVENUE, COUNTRY, PRODUCT, FISCPER} = {REVENUE, COUNTRY, PRODUCT,
FISCPER} * 2.
ENDIF.
ENDFOR
1.6.2.4.9 Notification Output
Use
You can output notifications using statement MESSAGE Tnnn(<Klasse>). or MESSAGE Tnnn(<Klasse>)
WITH <Operand1> ... <Operand4>.
● T is the of notification type ('E' = Error, 'I' = Information). If an error of type 'E' is triggered, the results of the
planning function are not copied to the internal transaction data buffer.
● nnn is a three-digit number.
● Klasse is the message class.
● Up to four operands can also be entered. Operands can either be variables or strings enclosed in
apostrophes.
The messages are gathered and displayed after the function has been executed.
 Recommendation
Rather than using the notifications delivered by SAP, we recommend creating a message class of your own
for error messages. Note that you have to transport your message class from the test system to the
production system.
Planning Concepts
1.6.2.4.10 Calling Function Modules
Use
You can use the CALL FUNCTION statement to call function modules. To do this, enter the name of the function
module in transaction SM30, in table RSPLF_FDIR.
EXPORTING, IMPORTING and CHANGING parameters can be specified for the function modules. The
parameters have to have simple types ((F, I, D, STRING and types of characteristics and attributes). Class
references, structures, and table parameters are not permitted.
All compulsory IMPORTING parameters of a function module have to have data.
If the function module triggers an exception, you have to work with the MESSAGE ... RAISING construct.
Class-based exceptions are also allowed. The function module notifications are copied to the log.
Example
In the following example, function module UPF_DISTR_RATE_GET is called.
 Source Code

DATA FISCYEAR TYPE 0FISCYEAR.
DATA RATE TYPE F.
DATA KYF TYPE KEYFIGURE_NAME.
FOREACH FISCYEAR, KYF.
FISCPER = OBJV( ).
CALL FUNCTION UPF_DISTR_RATE_GET
EXPORTING
I_FISCPER = FISCPER
I_VERSION = 'OPTIMISTIC'
IMPORTING
E_RATE = RATE.
{KYF,FISCYEAR} = { KYF, FISCYEAR } * RATE.
ENDFOR.
The following example shows how to use the MESSAGE ... RAISING statement when an exception is
triggered.
 Sample Code
FUNCTION UPF_DISTR_RATE_GET.
*"----------------------------------------*"
*"Lokale Schnittstelle:
*"IMPORTING
*" REFERENCE(I_FISCPER) TYPE /BI0/OIFISCPER
*" REFERENCE(I_VERSION) TYPE STRING DEFAULT 'OPTIMISTIC'
*"EXPORTING*" REFERENCE(E_RATE) TYPE F
*" REFERENCE(E_FISCYEAR) TYPE /BI0/OIFISCYEAR
*"EXCEPTIONS
*" ERROR*"----------------------------------------*"
DATA: L_FISCPER_3 TYPE N LENGTH 3.
Planning Concepts
L_FISCPER_3 = I_FISCPER+4(3).
IF I_VERSION = 'OPTIMISTIC'.
E_RATE = l_FISCPER_3 / 5.
ELSE.
E_RATE = l_FISCPER_3 / 7.
ENDIF.
E_FISCYEAR = I_FISCPER(4).
IF L_FISCPER_3 IS INITIAL OR E_FISCYEAR IS INITIAL.
MESSAGE E001(UPF) WITH 'Initiale Werte'(TIV) RAISING ERROR.
ENDIF.
ENDFUNCTION.
1.6.2.4.11 Internal Tables
You can define and use internal tables:
TABLE INTTAB { YEAR TYPE 0CALYEAR KEY, ZAHL TYPE F, COSTCENTER TYPE 0COSTCENTER }.
Internal tables consist of fields. Data types, which are permitted for variables, can be used for these fields. A
field followed by KEY is a key field. There must be at least one key field and one field that is not a key field.
There is only one entry per key in the table.
Tables can be filled by assigning a value:
INTTAB.{ZAHL,2011} = 25.
INTTAB.{ COSTCENTER, 2013 } = 00004711.
They can access values as follows:
{ 0VCPL_INT, 2013 } = INTTAB.{ ZAHL, 2013 }.
The following special functions are available for internal tables:
● Set number of rows: CNT = LINES( INTTAB ).

● Specify if a value exists: CNT = EXISTS( INTTAB.{ 2013 } ). The variable CNT is type I; it is set to the
value 1 if the entry exists, or set to 0 if the entry does not exist.
● Delete specific value: DELETE( INTTAB.{ 2014 } ).
● Delete all values: CLEAR INTTAB.
● FOREACH loop for values: FOREACH YEAR IN INTTAB.
1.6.2.4.12 Subroutines
To better structure complex formulas, you can modularize them.
Subroutines begin with FORM and end with ENDFORM. FORM is followed by a unique name. You can specify
IMPORTING and CHANGING parameters. The IMPORTING parameters are specified as a value and therefore
do not change if another value is assigned to them in the routine. For both of these parameters, you have to set
a type. For internal tables, take a table that has already been defined with TABLE.
The following example shows a subroutine called COLLECT_REFDATA together with the preceding DATA und
TABLE declarations of a planning function of type Formula.
Planning Concepts
 Sample Code
...
DATA SUM_REF TYPE F.
DATA REF_CNT TYPE I.
DATA PLUS_CNT TYPE I.
DATA MINUS_CNT TYPE I.
...
TABLE REFDATA_TAB {
PRO TYPE 0PRODUCT KEY,
REF TYPE F
}.
FORM COLLECT_REFDATA IMPORTING REF_RATIO TYPE KEYFIGURE_NAME
CHANGING REF_TAB TYPE REFDATA_TAB
SUM_REF TYPE F
PLUS_CNT TYPE I
MINUS_CNT TYPE I.
DATA M_PRODUCT TYPE 0PRODUCT.
DATA REF_DATA TYPE F.
SUM_REF = 0.
PLUS_CNT = 0.
MINUS_CNT = 0.
CLEAR REF_TAB.
FOREACH M_PRODUCT IN REFDATA.
IF M_PRODUCT <> '#'.
REF_DATA = { REF_RATIO, M_PRODUCT | 0VERSION = V00 }.
IF REF_DATA <> 0.
REF_TAB.{ REF, M_PRODUCT } = REF_DATA.
SUM_REF = SUM_REF + REF_DATA.
IF REF_DATA > 0.
PLUS_CNT = 1.
ELSEIF REF_DATA < 0.
MINUS_CNT = 1.
ENDIF.
ENDIF.
ENDIF.
ENDFOR.
ENDFORM.
Subroutine COLLECT_REFDATA has IMPORTING and CHANGING parameters. Parameter REF_TAB is an

internal table. The associated type REFDATA_TAB has to be declared before as a table in the formula. In
subroutines, it is not possible to access variables from the formula. All required information must be specified
in the parameters.
This is called up in the formula as follows:
 Sample Code
COLLECT_REFDATA( REF_RATIO, REFDATA_TAB, SUM_REF, PLUS_CNT, MINUS_CNT ).
1.6.2.4.13 INCLUDE of Formulas

You can use the INCLUDE statement to include formulas from various aggregation levels.
 Sample Code
INCLUDE FOX1.
Planning Concepts
The following parts are taken over from the formula:
● Definition of internal tables as types

● InfoProviders
● Forms
 Sample Code
DATA CALDAY TYPE 0CALDAY.

TABLE KURSTAB { DAY TYPE 0CALDAY KEY, KURS TYPE F }.
FORM INIT_KTYPE IMPORTING KTYPE TYPE ZJSKTYP.

DATA CALDAY TYPE 0CALDAY.
FOREACH CALDAY.
{0KURS,CALDAY,KTYPE} = 0.
ENDFOR.
ENDFORM.
…
INIT_KTYPE( 06 ).
INIT_KURSTAB( 05, KURSTAB ).
CALCULATE_KURS( 06, KURSTAB, 10 ).
Only the definition of TABLE KURSTAB and the FORM INIT_KTYPE can be referenced by included planning
functions. Global DATA statements and the formula itself are not taken into account.
1.6.2.4.14 Accessing InfoProviders
In BW Integrated Planning, additional data can be read from any aggregation levels and non-plannable
DataStore objects. This is declared using the InfoProvider statement.
 Example
INFOPROVIDER DSO_REF.
The following expression is required for access:
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR }.
When the InfoProvider is accessed, the name of the Provider and the character `.` are inserted in front of the
curly brackets. In this example, 0CALYEAR is the characteristic to be changed. With InfoProviders, all the
characteristics to be changed must be specified as well as the characteristics that are not available in the
aggregation level. Block characteristics can be accessed using the known notation.
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR | 0PLANT = PLANT }.
You cannot set any values. However, the system use the values assigned to a block for iteration:
FOREACH YEAR IN DSO_REF.

{ 0VCPL_INT, 2013 } = { 0VCPL_INT, 2013 } + DSO_REF.{ 0VCPL_QUAV, YEAR }.
ENDFOR.
Planning Concepts
The system determines which data is to be read in the same way as with reference data in a formula. For
example, the system adds the value PLANT01 to the selection for characteristic PLANT0, if the formula
contains the following:
{ 0VCPL_INT, 2013 } = DSO_REF.{ 0VCPL_QUAV, YEAR | 0PLANT = PLANT01 }.
You can influence the selection of the reference data by using the KEEP and the ENHANCE statement.
● By using the KEEP statement, you can prevent the system from deleting the reference data:
KEEP REFDATA SELECTION FOR INFOPROVIDER DSO_REF FOR 0CALYEAR.
● To explicitly request additional reference data, you can use the ENHANCE statement:
ENHANCE REFDATA SELECTION FOR INFOPROVIDER DSO_REF

FOR 0CALYEAR: 2015, 2016.
You can also use global variables in this list:
ENHANCE REFDATA SELECTION FOR INFOPROVIDER DSO_REF

FOR 0CALYEAR: 2015, 2016, YEARVAR.
Related Information
1.6.2.4.15 Examples of Formula Applications
Use
The following examples are used to demonstrate how to apply formulas:
1. Price planning
2. Price planning with prices in master data
3. Proportional planning
4. Copying with a condition for the value of a key figure
5. Copying with condition and iteration using a key figure name
6. Data plausibility check
7. Rolling planning
8. Depreciation
9. Calculating with data type 'D'
10. Working with character strings
1. Price planning
Prices are planned in version 1. In version 2, the prices are stored in the transaction data. The following
characteristics are changed:
● Version (0VERSION)
Planning Concepts
● Fiscal Year (0GJAHR)
● Customer (0CUSTOMER)
Note the special feature of these records: the characteristics Customer and Fiscal Year have the value Not
Assigned and must therefore be included in the group of characteristics to be changed. Also every object to be
planned in version 1 must have a corresponding object in version 2, from which the price can be determined. If
an article does not have a planned price, a message appears. The calculation is only executed when the
combination {MENGE,1, GJAHR,CUSTOMER} is scheduled (greater than zero).
 Sample Code
DATA CUSTOMER TYPE 0CUSTOMER.

DATA GJAHR TYPE 0GJAHR.
DATA ARTICLE TYPE 0ARTICLE.
IF {PREIS,2,#,#} = 0.
ARTICLE = OBJV( ).
MESSAGE I001(/SEM/003) WITH ARTICLE.
ELSE.
FOREACH GJAHR, CUSTOMER.
IF {MENGE,1,GJAHR,CUSTOMER} > 0.
{ERLOS,1,GJAHR,CUSTOMER} = {MENGE,1,GJAHR,CUSTOMER} * {PREIS,2,#,#}.
ENDIF.
ENDFOR.
ENDIF.
It seems surprising that the characteristic 'Article' (0ARTICLE) is missing from the list of characteristics to be
changed, because the prices used for calculating refer to 0ARTICLE. If the characteristic 0ARTICLE were
explicitly included, the example would look as follows:
 Sample Code

DATA GJAHR TYPE 0GJAHR.
FOREACH ARTICLE, GJAHR, CUSTOMER.
IF {PREIS,2,#,#,ARTICLE} = 0.
ELSE.
IF {MENGE,1,GJAHR,CUSTOMER,ARTICLE} > 0.
{ERLOS,1,GJAHR,CUSTOMER,ARTICLE} = {MENGE,1,GJAHR,CUSTOMER,ARTICLE} *
{PREIS,2,#,#,ARTICLE}.
ENDIF.
ENDIF.
ENDFOR.
The 0ARTICLE characteristic is not actually necessary for the formula, as the values of the characteristic are
not changed. When calculating the planned revenue, the same article is referred to on both sides of the
relational operator.
 Recommendation
In this case, SAP recommends that you do not include the characteristic in the quantity of characteristics
to be changed, as it is not required for the calculation and it reduces performance when the system
accesses the values. Another way to accelerate the formula is to save the value of the element {PREIS,
2,#,#} in an auxiliary variable and then work with this variable. If the value of a characteristic is required to
issue error messages or determine attribute values, the value can be read by function OBJV().
Planning Concepts
You can make the formula even shorter by accessing the reference data explicitly. Apart from the key figure
name there are no characteristics to be changed. The formula is run (depending on the data record). A
FOREACH loop through the characteristics to be changed is not necessary.
 Sample Code

IF {PREIS | 0VERSION = 2,0GJAHR = #,0CUSTOMER = #} = 0.
ARTICLE = OBJV( ).
ELSE.
ERLOS = MENGE * { PREIS | 0VERSION = 2,0GJAHR = #,0CUSTOMER = #}.
ENDIF.
2. Price planning with prices in master data
How does price planning work when the price is stored in the master data? Use the function OBJV to get the
value of the article. The value of attribute ATRV is read using function 0PRICE. The ATRV function includes 2
arguments, in the simplest form. The first argument has to be the name of a master data attribute; the second
argument has to be a variable. The value of the attribute is read using the variable value in the master data
table. It is important to differentiate between two cases with compound characteristics:
● If the higher-level characteristics are fields to be changed, the values of these characteristics have to be
specified for the function in the form of variables. The number of arguments of the function is determined
in this case by how many fields have to be specified.
● If the parent characteristics are not included in the quantity of fields to be changes, the values are
automatically removed from the values of the current package. In the following example, only the key figure
name is a characteristic to be changed.
 Sample Code

ARTICLE = OBJV().
ERLOS = ATRV( '0PRICE', ARTICLE ) * MENGE.
3. Proportional planning
Characteristics to be changed are key figure name, version 0VERSION and customer 0CUSTOMER.
 Sample Code
DATA GESERLOS TYPE F.

DATA GESMENGE TYPE F.
FOREACH CUSTOMER.
GESERLOS = GESERL0S + {ERLOS,2,CUSTOMER}.
GESMENGE = GESMENGE + {MENGE,2,CUSTOMER}.
ENDFOR.
FOREACH CUSTOMER.
{ERLOS,1,CUSTOMER} = {MENGE,1,CUSTOMER} * GESERLOS / GESMENGE.
ENDFOR.
4. Copying with a condition for the value of a key figure
The characteristic to be changed is Version. The key figure name is selected as the characteristic for
conditions. ERLOS is selected as the value for key figure names. The following formula copies the revenue from
Planning Concepts
version 1 to version 2 if the revenue in version 1 is greater than 500. We cannot implement the planning function
of type Copy [page 71] in this example as it is not possible to formulate conditions for key figure values here.
Normally it is more beneficial to use special planning functions instead of formulas, as these are implemented
more efficiently.
 Sample Code
IF {1} > 500.

{2} = {1}.
ENDIF.
5. Copying with condition and iteration using a key figure name
Characteristics to be changed are key figure name and version. In contrast to the example above, all key figures
are now copied to version 2 if the revenue is greater than 500. To avoid having to assign all key figures, we
define a RATIO variable of type KEYFIGURE_NAME and iterate across all key figures of the planning level using
the FOREACH construct.
 Sample Code
DATA RATIO TYPE KEYFIGURE_NAME.

IF { ERLOS, 1 } > 500.
FOREACH RATIO.
{ RATIO, 2 } = { RATIO, 1 }.
ENDFOR.
ENDIF.
6. Data plausibility check
Characteristics to be changed are key figure name, version and article. We check whether the planned revenue
has reached at least 90 percent of the revenue of version 1. If the limit is exceeded, the system gives a warning
message.
 Sample Code

DATA MINERLOS TYPE F.
FOREACH ARTICLE.
MINERLOS = { ERLOS, 1, ARTICLE } * 0.9.
IF { ERLOS, 2, ARTICLE } < MINERLOS.
* Der geplante Erlös für Artikel &1 unterschreitet den vorgegebenen
Mindesterlös
MESSAGE I034(ZSEM) WITH ARTICLE.
ENDIF.
ENDFOR.
7. Rolling planning
Characteristics to be changed are version and fiscal year/period. The actual data of the current period is copied
to the plan version. The difference is distributed over the remaining periods. The current period is determined
from a variable.
 Sample Code
DATA ACTPER TYPE FISCPER.

DATA FISCPER TYPE FISCPER.
DATA SUM TYPE F.
Planning Concepts
DATA DELTA TYPE F.
* Periode aus der Variablen mit dem technischen Namen PERIODE lesen
ACTPER = VARV( 'PERIODE' ).
* Summe zum Gewichten besorgen
FOREACH FISCPER.
IF FISCPER > ACTPER.
SUM = SUM + { 1, FISCPER }.
ENDIF.
ENDFOR.
* Delta zwischen Planwert und Istwert bestimmen
DELTA = {1, ACTPER} - {0,ACTPER}.
* Planwert auf Istwert setzen
{1,ACTPER} = {0, ACTPER}.
* Delta gewichtet verteilen
FOREACH FISCPER.
IF FISCPER > ACTPER.
{1,FISCPER} = {1,FISCPER} + DELTA * {1,FISCPER} / SUM.
ENDIF.
ENDFOR.
8. Depreciation
Characteristics to be changed are key figure name and fiscal year. The value of key figure 0AMOUNT is
calculated for 5 years. The cost price is 1000. Residual value is 100. Depreciation percentage rate is 20 percent.
Straight-line depreciation is calculated. In this example, the DECL (straight-line depreciation) function is not of
importance, but the TMVL function. As its first argument, the function has the value of a time characteristic. As
a second argument it has an offset. The offset specifies which of the next largest values the function should
return. You can also transfer negative offsets. Then the corresponding smaller values are returned. It is not
possible to set the same effect with a FOREACH loop because not all years have to be included in the
transaction data.
 Sample Code
DATA JAHRE TYPE I.

DATA GJAHR TYPE 0FISCYEAR.
GJAHR = VARV( 'ACTYEAR' ).
DO.
JAHRE = JAHRE + 1.
GJAHR = TMVL( GJAHR, 1 ).
{0AMOUNT, GJAHR} = DECL( 1000, 100, 20, JAHRE).
IF JAHRE = 5.
EXIT.
ENDIF.
ENDDO.
9. Calculating with data type 'D'
You can also perform calculations with data type 'D'. A short example is explained below. In the FOREACH loop,
the date of the first day is specified in D1 in FISPCER and the last day in D2 in FISPCER. The difference between
D1 and D2 is formed in I1 and two days are subtracted. I1 has type I. If the date format in D1 and D2 is invalid,
the result 0 is returned. When calculating with fields of type D, the constant operands are also checked for valid
date formats. Therefore, we cannot write I1 = D2 - D1 - 2.. An auxiliary variable I2 must be used instead.
 Sample Code
DATA D1 TYPE D.
DATA D2 TYPE D.
DATA I1 TYPE I.
DATA I2 TYPE I.
Planning Concepts
FOREACH FISCPER.
* Calculate 1st day of FISCPER
D1 = C2DATE( FISCPER, S ).
* Calculate last day of FISCPER
D2 = C2DATE( FISCPER, E ).
* Calculate the difference between last and 1st day minus two days
I2 = 2.
I1 = D2 - D1 - I2.
MESSAGE I001(UPF) WITH 'DIFFERENCE' I1.
ENDFOR.
10. Working with character strings
In the following example. the system checks whether the characteristics fiscal year/period (0FISCPER), fiscal
year (0FISCYEAR) and the three-figure posting periods (0FISCPER3) are filled consistently. Fiscal year/period
is seven characters long, the first four represent the fiscal year and the characters five to seven represent the
posting period. Using function SUBSTR (character value, offset, length), the appropriate values are
read from the value for fiscal year/period. If the characteristic value for fiscal year/period is initial, it is filled with
the concatenated value of fiscal year and posting period. The CONCAT function is used.
 Sample Code

DATA FISCPER_CMP TYPE 0FISCPER.
DATA YEAR TYPE 0FISCYEAR.
DATA PER TYPE 0FISCPER3.
DATA PER_CMP TYPE 0FISCPER3.
DATA YEAR_CMP TYPE 0FISCYEAR.
DATA KYFNM TYPE KEYFIGURE_NAME.
YEAR = OBJV( ).
PER = OBJV( ).
FISCPER_CMP = CONCAT( YEAR, PER3 ).
FOREACH KYFNM, FISCPER.
IF FISCPER IS INITIAL.
{KYFNM,FISCPER_CMP} = {KYFNM,FISCPER}.
ELSE.
PER_CMP = SUBSTR( FISCPER, 4, 3 ).
YEAR_CMP = SUBSTR( FISCPER, 0, 4 ).
IF YEAR <> YEAR_CMP OR PER <> PER_CMP.
* Fehlermeldung
MESSAGE E021(/SEM/003) WITH YEAR YEAR_CMP PER PER_CMP.
ENDIF.
ENDIF.
ENDFOR.
Planning Concepts
1.6.2.5 Formula with Processing of Zero Records
Function type Formula with Processing of Zero Records (0RSPL_FORMULA_ZERO) is different to planning
function type Formula (0RSPL_FORMULA) in that it also processes records whose key figures are all zero (zero
or empty records).
Use
With this planning function type, it is also possible to create zero records. Since zero records can be records
that have been canceled due to them containing errors, the system checks all records against the
characteristic relationships when reading the data, and only processes records which are valid.
This applies for filter data, reference data, and data that is read from other InfoProviders. If parameter
RS_DEBUGLEVEL is set to a value greater than 1, the system also determines how many records can be skipped
during database processing. Otherwise, corresponding messages are only output when the planning function is
executed on the application server.
1.6.2.6 Setting Key Figure Values
Use
You can use function type Set Key Figure Values to set values for key figures and distribute them according to
reference data.
Setting Key Figure Values
To set key figure values, you can enter a selection condition on block characteristics, together with the name of
the key figure and the value to be set.
Distribution by Reference Data
Distribution is not performed if no characteristics have been selected for modification.
The system provides various parameters for distribution of key figure values. These parameters correspond to
the parameters for selecting reference data of function type Distribution by Reference Data.
Comparison with Function Type Distribution by Reference Data
Function type Set Key Figure Values only works with empty records. Empty records are records whose key
figure values are empty from the point of view of the aggregation level. This distinguishes this function type
from function type Distribution by Reference Data, which does not process empty records. If there is no
reference, meaning that Distribute Evenly to Existing Objects is set, planning functions of type Set Key Figure
Values are distributed evenly to a larger number of objects than planning functions of type Distribute by
Reference Data.
Planning Concepts
Related Information
Distribution by Reference Data [page 91]
1.6.2.7 Copy
Use
You use the Copy function type to copy key figure values from one characteristic combination to another.
 Example
If you want to copy values from 2015 to 2017 for example without changing other characteristics, set the
Will Be Changed flag for characteristic Year.
You use the table for key figure selection to specify which key figures you want to copy.
In the From and To Values for Copying table, you can either create one or more copying processes in a planning
function.
The function type also allows complicated copying processes: Both the From and To values can be
characteristic restrictions on the characteristics that you want to change. The system continually totals the
values of the From key figures using all the records in the block that correspond to the characteristic
restriction; it continually writes the To totals for each individual characteristic combination.
You can also copy values from one From value to multiple To values.
 Example
You copy data from the year “2015“ in version “ACTUAL” to the combinations {“2016“, “PLAN01“} and
{2017, „PLAN02“}.
The function type reads and writes empty records.
The following rules apply:
● The From values are read as reference data and do not need to in the filter that is submitted to the planning
function.
● The To values are changed. They therefore have to be in the filter.
● The key figure values for the To values are always overwritten during copying. This also applies if the From
values are empty.
● If there are no values to form a block for a characteristic restriction on the From side, the subprocess is not
executed.
● Combinations are generated on the To side for the specified characteristic restrictions. This is consistent
with the master data and the characteristic relationships defined for the InfoProviders. If the system
cannot find a target for a block and a subprocess, no data is created.
● If a target has been specified in one or more subprocesses, the target contains the relevant totals once the
function has been executed.
The copying function also forms blocks of reference data.
Planning Concepts
Related Information
Copying (ignoring zero records) [page 72]
1.6.2.7.1 Copying (ignoring zero records)
Use
You use the Copy (ignore zero records) function type to copy key figure values from one characteristic
combination to another. Unlike the Copy function, this function does not read or write any zero records.
 Note
The Copy (ignore zero records) planning function can result in better performance than the Copy function,
because usually fewer characteristic relationships need to be checked.
More Information
Copy [page 71]
1.6.2.8 Delete
Use
You use the Delete function type to delete key figure values from the selected data records.
No characteristic values are changed during this process. In characteristic value usage, you can only select
characteristics as condition characteristics.
You can use a table to select the key figures that you want to delete.
Related Information
Delete DSO Records [page 73]
Planning Concepts
1.6.2.8.1 Delete DSO Records
Use
Function type Delete DSO Records is used to physically delete records from direct update DataStore objects. In
the case of a data mart DataStore object, they are set to zero.
 Caution
Note that either the aggregation level that you create the planning function on contains all fields of the
DataStore object, or that the fields that are not contained there are filled by derivation.
Characteristics that are data fields must be usable as key figures. You can make this setting on the
DataStore object maintenance screen. The key figures (and not the data fields) must then be added to the
aggregation level that serves as the basis for the planning function.
More Information
Delete [page 72]
1.6.2.9 Deleting Invalid Combinations
Use
You use function type Delete Invalid Combinations to delete all key figure values from records whose
combination of characteristic values does not correspond to the characteristic combinations defined in the
underlying planning-relevant InfoProvider.
 Note
The following condition applies: A planning function of this type can only be created on an aggregation level
that has been directly created on a planning-relevant InfoProvider (a simple aggregation level, see
Aggregation Level [page 22]). The aggregation level must contain all valid InfoObjects of the InfoProvider in
aggregation levels.
 Note
Since normal use of a direct update DataStore object does not allow you to completely delete combinations
of characteristics (records) the planning function just resets all key figures to zero. The same applies for a
local provider in the BW Workspace.
Planning Concepts
1.6.2.9.1 Physically Delete Invalid Data in the DataStore
Object
Use
You use function type Physically Delete Invalid Data in the DSO to physically delete the key figure values from all
records whose combination of characteristic values does not correspond to the characteristic combinations
defined in the underlying planning-relevant DataStore object. In the case of a data mart DataStore object, they
are set to zero.
 Caution
More Information
Delete Invalid Combinations [page 73]
1.6.2.10 Forecast
Use
You can use a forecast procedure to predict the future development of key figure values. The default planning
function type Forecast offers a number of strategies and statistical methods for calculating forecasting future
values on the basis of historical data.
Integration
The strategies and methods of this planning function type are based on the same statistical methods used in
demand planning.
 Note
For more information about forecasting in demand planning, see http://help.sap.com SAP Business Suite
SAP Supply Chain Management SAP APO 3.1 Application Help Demand Planning Demand
Planning Concepts
Planning Process Definition/Redefinition of Forecast Models Creating a Forecast Profile Univariate
Forecasting .
Prerequisites
● Past data must be available to serve as historic data for the forecast calculation.
● The aggregation levels where you create a forecast planning function have to contain at least one time
characteristic (Fiscal Year/Periods for example). The forecast only works with one time characteristic. Only
values for this characteristic can be changed. The other characteristics, especially redundant time
characteristics, are not adapted by the forecast function. Time characteristics always need to assume
consistent values to one another, however. Value 2017 for time characteristic Calendar Year (0CALYEAR)
therefore matches the values 01.2017 to 12.2017 for characteristic Calendar Year/Month (0CALMONTH). If
you want to forecast values beyond a single year, however, the calendar year must assume different values
in the records to be forecast. The planning function does not do this. It is done by the derivation instead,
which automatically fills the redundant time characteristics.
 Note
Note that you cannot add any redundant time characteristics such as Calendar Year/Month
(InfoObject 0CALMONTH) and Calendar Year (InfoObject 0CALYEAR) or Fiscal Year/Period (InfoObject
0FISCPER) and Fiscal Year (InfoObject 0FISCYEAR) to the aggregation level,. Only add time
characteristics with the finest level of granularity to the aggregation level.
In the examples specified, you should therefore use 0CALMONTH or 0FISCPER. The values for the
"parent" time characteristic 0CALYEAR or 0FISCYEAR can then be derived automatically.
Features
Planning function type Forecast covers various univariate forecast procedures. In a forecast procedure, only the
time series of the selected forecast key figure is taken into account. No further information is entered in the
forecast calculation to interpret the development of the key figure.
Time Series Patterns
You can create forecasts for the following time series patterns:
Constant
Planning Concepts
The historic data is essentially constant and varies very little from a stable mean value. In the graphic below,
this base value is represented by a red line:
Trend
The time series rises or falls continuously. In the graphic below, this trend is represented by a red line:
Seasonal
The values show periodically recurring peaks and troughs (on an annual basis). There is a stable mean value. In
the graphic below, this base value is represented by a red line:
Seasonal Trend
Planning Concepts
This time series is a combination of the trend and seasonal patterns. The seasonal variation increases for an
upward trend.
Intermittent
The value is zero at most points in the time series. The values that are not zero fluctuate around a mean value.
Forecast Strategies
The forecast strategy defines which forecast procedure is used. To choose a suitable forecast strategy, base
your decision on the time series pattern. The various forecast procedures are based on the different forecast
models (time series models). They therefore produce different results.
The following forecast strategies are available:
● Average
● Floating Average
● Weighted Floating Average
● Linear Regression
● Seasonal Linear Regression
● Simple Exponential Smoothing (Constant Model)
● Simple Exponential Smoothing with Alpha Optimization (Constant Model)
● Linear Exponential smoothing (Trend Model)
● Seasonal Exponential Smoothing (Season Model)
● Seasonal Trend Exponential Smoothing (Seasonal Trend Model)
Planning Concepts
● Croston Model
● Automatic Model Selection
The automatic model selection forecast strategy allows you to let the system select the forecast model that
best matches the time series of the historic data.
If you already know that a particular forecast model is well suited to the time series pattern, or if you explicitly
want to use a particular forecast model for other reasons, you can select another particular forecast model
instead.
Additional Functions for Forecast Strategies
The forecast strategies offer the following additional functions and options:
● Outlier Correction
● Logging Statistical Key Figures
● Ignoring Initial Zero Values
For exponential smoothing:
● Optimization of smoothing factors for exponential smoothing
For forecast models with trend components:
● Trend Dampening
Gaps in the Forecast or in the Historic Time Frame
Gaps can occur in both the forecast and the historic time frame. These gaps are taken into account. The
selected points in time are therefore not displayed without gaps. Gaps in the forecasting period are handled so
that the values of this period are not changed. Gaps in the historic time frame are included in the forecast
calculation with value 0.
 Note
Note that the times before the first forecast time belong in the past.
 Example
You want to generate forecast data for the months 1-3 and 5-7 (month 4 is handled separately). The system
calculates forecast values for all months 1-7, but does not change month 4. A linear trend in the forecast
result with the values 1010, 1020 produces the following result:
Month Planning
1 1010
2 1020
3 1030
5 1050
6 1060
7 1070
Planning Concepts
Related Information
Forecast Strategies [page 79]

Automatic Model Selection [page 83]
Outlier Correction [page 84]
Trend Dampening [page 85]
Logging Statistical Key Figures [page 86]
Ignoring Initial Zero Values [page 87]
1.6.2.10.1 Forecast Strategies
The forecasting strategy defines how forecast values will be computed.
Use
All forecast strategies are based on statistical forecast procedures and forecast models that represent the time
series mathematically. The exponential smoothing methods are currently the most widely used time series
patterns. If you expect historic values to continue to develop as they have in the past, choose a forecast model
that fits the time series pattern.
 Note
The Automatic Model Selection strategy allows you to let the system select the forecast model that best fits
the trend of historic data.
Features
The following forecasting strategies can be used:
Average: The forecast value is calculated from the mean of the historic values.
Optional Forecast Parameters:
Floating Average: The forecast value is calculated according to the order.
Obligatory Forecast Parameters:
● Order of Floating Average:

The order of the floating average is a number N that determines the length of the time interval for
calculating the average. This is the number of chronologically sequential historic values. The forecast value
is calculated simply as the average of the last N historic values.
Planning Concepts
Enter a positive number for the order.
Weighted Floating Average: When the system calculates the floating average, each historic value is given a
particular weight.
Obligatory Forecast Parameters:
● Order of Floating Average:

The order of the floating average is a number N that determines the length of the time interval for
calculating the average. This is the number of chronologically sequential historic values.
Enter a positive number for the order.
● Weighting Factors:
The weighting factors specify the relationship between the individual historic values and the average
calculation. The sequence is important: Weighting factor 1 refers to the previous periods, while weighting
factor 2 refers to the periods before that and so on.
 Example
You want to create a forecast based on monthly values and select the weighted average for order 6.
While doing this, you want to weight the most recent monthly values more strongly than the older ones.
The past data comes from months 5 to 10. The six weighting factors and the relevant months are as
follows:
No. Weighting Factor Month
1 3.00 10
2 2.00 9
3 2.00 8
4 1.00 7
5 1.00 6
6 1.00 5
Linear Regression: Simple linear regression (method of smallest quadrats).
● Trend Dampening
Planning Concepts
Seasonal Linear Regression: Seasonal linear regression is based on the same statistical procedures as used in
demand planning.
 Note
For more information, see http://help.sap.com/ SAP Business Suite SAP Supply Chain Management
SAP APO 3.1 Application Help Demand Planning Demand Planning Process Definition/
Redefinition of Forecast Models Creating a Master Forecast Profile Univariate Forecasting Forecast
Strategies Seasonal Linear Regression
Obligatory Forecast Parameters: Periods per Season
● Trend Dampening
Simple Exponential Smoothing (Constant Model): Simple exponential smoothing is suitable if the historic
data shows a constant trend.
Smoothing factor settings: Alpha (base value)
Simple Exponential Smoothing with Alpha Optimization (Constant Model): This procedure is the same as
the “simple exponential smoothing“ described above with just one difference: The system also calculates the
Alpha smoothing factor. The Alpha value is variegated in the interval using the defined step size and a forecast
calculation (for the historic time frame) is performed in each case. The optimum value for Alpha is the value
that produces the smallest error in the forecast results.
Smoothing factor settings: Optimization Variable, Alpha from, Alpha tos, Alpha Step Size
Linear Exponential smoothing (Trend Model): The forecast is calculated according to Holt’s method and is
suitable if historic values display an upward or downward trend.
Smoothing factor settings: Alpha (Base Value), Beta (Trend Value),
● Trend Dampening
Seasonal Exponential Smoothing (Season Model): Choose this strategy if your historic values show seasonal
fluctuations (for example, annual fluctuations) from a constant base value.
Planning Concepts
Smoothing factor settings: Alpha (Base Value), Gamma (seasonal components),
Seasonal Trend Exponential Smoothing: Forecasting is based on Winter/Holt's multiplicative method and is
appropriate if historical values fluctuate on a seasonal basis from an increasing or decreasing trend. The
fluctuation increases with an upward trend.
 Example
Ice cream sales in summer: Assume that ice cream sales rise by a trend of 10% annually. A seasonal
increase of 30% each summer then leads to ever greater absolute fluctuations.
Smoothing factor settings: Alpha (Base Value), Beta (Trend Value), Gamma (seasonal components).
● Trend Dampening
Croston Method
The Croston method was developed specifically for sporadic trends. This procedure uses exponential
smoothing to calculate a mean time interval between the values in the time series that are not equal to zero.
 Note
For more information, see http://help.sap.com/SAP Business SuiteSAP Supply Chain ManagementSAP
APO 3.1Application HelpDemand PlanningDemand Planning ProcessDefinition/Redefinition of Forecast
ModelsCreating a Master Forecast ProfileUnivariate ForecastingForecast StrategiesCroston Method
Check whether it might be possible to aggregate the data in order to remove the gaps in the time series. This
would make it possible to use procedures that take account of trend or seasonal time series patterns. You can
aggregate data in this way by choosing a rough time characteristic (month instead of day) or by forecasting
values for product groups instead of individual products.
Related Information
Automatic Model Selection [page 83]

Outlier Correction [page 84]
Trend Dampening [page 85]
Logging Statistical Key Figures [page 86]
Planning Concepts
Ignoring Initial Zero Values [page 87]
1.6.2.10.2 Automatic Model Selection
Use
With automatic model selection, you can let the system decide which forecast model best matches your
historical data.
 Recommendation
We recommend using automatic model selection if you do not know how your historical data has
developed, if you cannot estimate how your data will develop or if you do not want to specify a model.
Features
The system performs a number of tests and uses the results to find the model to use (see Forecast Strategies
[page 79]). If the model chosen is exponential smoothing, the system optimizes the relevant smoothing factors
( Alpha, Beta, Gamma).
 Note
Note that automatic model selection requires a high level of calculation. This is particularly true of the
seasonal trend model. The level of calculation required also depends on the size of the search space and
the level of detail for the stepsize selected.
Activities
1. First the system tests for sporadic historic data by determining the number of periods that do not contain
any data for the history key figure. If this number accounts for more than 66% of the total number of
periods, the system automatically uses the Croston method.
2. The system then tests for white noise. If there is white noise, the system automatically uses the constant
method.
3. If both tests are negative, the system tests for seasonal and trend effects.
1. First the system deletes existing trends. To test for seasonal effects, the system determines the auto-
correlation coefficients. If the auto-correlation coefficient is greater than 0.3, the test is positive.
2. To test for trend effects, the system determines the trend significance parameters. If the seasonal test
is positive, the system removes possible seasonal effects. If no seasonal tests are determined, the
system runs the test using the number of past periods minus 2. If seasonal effects are determined, it
runs the test using the number of periods in a season plus 1.
Planning Concepts
 Note
Since the results of these tests determine the model that the system checks in the next step, the
Periods per Season parameter is particularly significant. If your historical data contains a season
with seven periods for example, and you enter "3" for Periods per Season, the seasonal test will
probably be negative. In this case, the system does not check the seasonal model but checks the
trend and constant models only.
4. The system uses the selected model (see the table below) and performs the forecast. It calculates all error
measures. In models that use forecast parameters ( Alpha, Beta, Gamma), these parameters vary to reflect
the areas and step sizes specified in the forecast profile.
Test for White Test for Sporadic Seasonal test Trend test
Noise Data
Croston model X
Trend X
Seasonal X
Trend Season A A
Linear Regression o X
Seasonal linear regression A A
Legend for the characters in the table:

X - The model is used if the test is positive.
A - The model is used if all tests are positive.
o - The model is used if the test is negative.
The constant model always runs, unless the test for sporadic data is positive. In this case, the Croston
model is used exclusively (as a special variant of the constant model).
The system chooses the model with the parameters that produce the lowest number of errors. The
number of errors is selected in the "Error Measure" field in the forecast profile.
1.6.2.10.3 Outlier Correction
Use
"Outliers" are anomalous values that cannot be explained by the forecast model. They can heavily influence the
forecast result.
The system can identify and replace outliers in the historical data. To do this, the forecast procedure calculates
forecast values in the past period and compares them to the historical values. If the difference (the residual)
exceeds a specific threshold value, the historical value is replaced by the ex-post-forecast value for the
corresponding point in time. After this correction has been made, the forecast calculation is performed again
using the amended historical data.
Planning Concepts
To set the threshold value, you can define a Sigma factor.
Integration
Outlier detection depends on the forecast model because the forecast value is calculated using a model and its
related algorithm.
Features
In the forecast function, outliers in the historical values are defined by the Sigma factor. The greater the Sigma
factor, the more tolerance the system is with regard to anomalous values, meaning that the system will identify
fewer outliers.
Sigma factor fac defines outlier detection as follows: An observed value y is declared as an outlier if the
difference to forecast value e is greater than fac *s. s denotes the standard deviation of the residuals.
Activities
Activate outlier correction if you think that outliers are having an unfavorable effect on the forecast result.
Avoid using outlier correction if you always want to take account of anomalous values when calculating
forecasts.
1.6.2.10.4 Trend Dampening
Use
For forecast models with a trend component ( linear regression, the trend models for exponential smoothing
with or without seasonality, and, in some cases, automatic model selection), you can dampen the trend for
future forecast values by specifying a trend damping factor.
Use the trend dampening factor if you expect the past growth rate to slow down or intensify in future.
Features
The trend dampening factor is a number that is multiplied by the trend value (growth rate) when the forecast
value is calculated. This makes it possible to slow down or intensify growth in a long-term trend.
Planning Concepts
● With a trend dampening factor of less than 1, a type of saturation effect is produced. The trend value will
exponentially converge to 0.
 Example
A trend dampening factor of 0.9 decreases the growth rate for each period by 10% recursively.
If the number of cars sold is currently growing by 1000 per period for example, the growth in the
number of cars sold in the next period would be 0.9 * 1000 = 900, and would be 0.9 * 900 = 810 in the
period after that.
● To achieve the reverse effect, you can enter a trend dampening factor greater than one.
Activities
To perform trend dampening, choose this option and specify a trend dampening factor in accordance with your
expectations.
1.6.2.10.5 Logging Statistical Key Figures
Use
This function logs statistical information about the forecast calculation.
Once the forecast function has been executed, the system displays the corresponding statistical information
and the error messages for the forecast calculation in the log.
Features
The following statistical information is logged:
● Error totals
● Mean absolute deviation (MAD)
● Mean absolute percent error (MAPE)
● Mean percentage error (MPE)
● Mean square error (MSE)
● Root of the mean square error (RMSE)
● Number of outliers (when outlier correction is active)
● Selected forecast model (with automatic model selection)
● Smoothing factors (with optimization of smoothing factors)
Planning Concepts
Activities
Choose this option in order to log statistical information about the forecast result.
1.6.2.10.6 Ignoring Initial Zero Values
Use
You use this function to set whether a string of zero values at the beginning of a selected period in the past are
included in the forecast.
 Example
You want to calculate forecast values for your products. The historical period is the last 24 months. The
time series of products that have only existed for a few months therefore begins with a sequence of zero
values. You do not want the forecast values to be influenced by these values, so you select Ignore Initial Zero
Values.
Activities
Choose this option if you want to exclude initial zero values from the forecast calculation.
1.6.2.11 Displaying the Log of a Process Chain
You can use the function type Display Log of a Process Chain(0RSPL_GET_PC_LOG) to read the log of the most
recently started process chain.
The system displays overview information without details. For planning functions of this type as well, the data is
neither read nor locked in the filter.
Related Information
Start Process Chain [page 88]
Planning Concepts
1.6.2.12 Start Process Chain
You can use the function type Start Process Chain (0RSPL_START_PROCESS) to start a process chain from the
planning environment.
The only parameter you need is the name of the process chain.
You can define the process chain in Customizing. The planning function must as usual be started together with
a filter, but no lock is set, and no data is read.
The process chain runs asynchronously.
To view the result of the process chain, you can use the function type Display Log of a Process Chain
(0RSPL_GET_PC_LOG).
Related Information
Displaying the Log of a Process Chain [page 87]
1.6.2.13 Reposting
Use
iAs with Copy [page 71], you use the Repost function type to post key figure values of characteristic
combinations to other combinations. Unlike when copying, the key figure values for the From values are
deleted. For an introductory example, see Planning Functions [page 32].
You use the table for key figure selection to set which key figures you want to repost.
In the From and To Values for Reposting table, you create either a simple reposting process or multiple
reposting processes in a planning function.
● Both the From and To values for reposting have to be single values.
● Both the From and To values are changed and have to be included in the filter submitted to the planning
function.
● During reposting, the key figure values are always added to the To values.
Planning Concepts
1.6.2.13.1 Repost DSO Data and Physically Delete Source
Data
Use
You use function type Repost DSO Data and Physically Delete Source Data to post the key figures of existing
characteristic combinations to other combinations. All source data from a direct update DataStore object is
deleted. In the case of a data mart DataStore object, the source data is canceled.
 Caution
More Information
Repost [page 88]
1.6.2.14 Reposting by Characteristic Relationships
Use
You use the Repost by Characteristicv Relationship function to repost transaction data so that it is consistent
with the characteristic relationships. The original records are deleted and reposted to the correct characteristic
combinations.
In characteristic usage, you can specify which characteristics should be corrected. This only makes sense for
characteristics that can be derived in accordance with the characteristic relationships.
 Note
The following condition applies: A planning function of this type can only be created on an aggregation level
that has been directly created on a planning-relevant InfoProvider (a simple aggregation level, see
Aggregation Level [page 22]). The aggregation level must contain all the InfoObjects of the InfoProvider
that are valid in aggregation levels.
 Note
Since normal use of a direct update DataStore object does not allow you to completely delete combinations
of characteristics (records), the planning function simply resets all key figures to zero. The same applies for
a local provider in the BW Workspace.
Planning Concepts
1.6.2.14.1 Repost DSO Data on the Basis of Characteristic
Relationships
Use
You use the Repost DSO Data on the Basis of Characteristic Relationship function to repost transaction data so
that it is consistent with the characteristic relationships. Unlike function type Repost by Characteristic
Relationship, this function deletes all source data from a direct update DataStore object and reposts the data to
the correct characteristic combinations. In the case of a data mart DataStore object, the source data is
canceled.
More Information
Repost by Characteristic Relationships [page 89]
1.6.2.15 Revaluation
Use
You use the Revaluation function type to increase or decrease key figures by a percentage rate of your
choosing.
No characteristic values are changed during this process. In characteristic value usage, you can only select
characteristics as condition characteristics.
You can either enter a common percentage for all key figures or revaluate key figures with individual
percentages.
In both cases you can either enter the percentage directly or use variables. The percentage is interpreted as
delta; the system does not expect you to enter a percentage sign.
 Example
If you enter 15.4, the system performs the following calculation:
new value = old value + 15.4% * old value.
Planning Concepts
1.6.2.16 Distribution by Reference Data
Use
You use the Distribution by Reference Data function type to create the characteristic combinations that data is
distributed to in accordance with the reference data. The key figure values are distributed by percentage in
accordance with the reference data.
You use the table for key figure selection to select the key figures that you want to distribute.
The system provides two parameters for the Selection of Reference Data:
Parameters Description
Reference key figure (optional): You determine a key figure to use in the reference data to
calculate the distribution key.
● IWhen you have chosen this key figure, the system dis
tributes all of the key figures to be distributed according
to this key, i.e. according to this reference key figure.
● If no reference key figure is selected, the system calcu
lates a key individually for each of the key figures to be
distributed. The same key figure is used in the reference
data that is distributed.
Reference Values on Any Block Characteristics You set a reference value for one or more block characteris
tics. While reading the reference data for each block, the sys
tem overwrites the characteristic value of the block in the
characteristic with this reference value.
 Example
An InfoProvider provides data for the years 2005 and
2006. You want to change transaction data for the year
2006. The data from 2006 is selected in the filter that is
transferred to the planning function. All the blocks
therefore have year 2006. If the reference value is 2005
however, you can ensure that the keys are calculated ac
cording to the data from 2005.
You can control the distribution process in various ways:
● Distribution with a top-down variant

○ Distribute All: The entire block is totaled.
○ Only Distribute Non-Assigned: Values are only distributed if they have the characteristic value Not
Assigned [#] in the current block for all of characteristics to be changed.
● Distribution using manually created entries in the From and To Values for Distribution table.
You can create one or more distribute operations by manually entering the characteristic restrictions for
the characteristics to be changed.
The system continually totals the values of the key figures on the From side over all the records in the block
corresponding to the characteristic restriction, and distributes this total to the To values.
Planning Concepts
The system distributes data to the characteristic combinations in the reference data and that match the
characteristic restrictions in the To values.
The percentage distribution corresponds to the percentage distribution in the reference data.
In top-down distribution, the system distributes to all characteristic combinations in the reference data. Data
records that have Not Assigned [#] set for characteristic values of the fields to be changed are excluded.
If there is no reference data for a subprocess, the key figure values for this subprocess are not distributed, and
a warning message is displayed.
 Note
The order in which the system executes the distribute function is the same as the order in which the
Distribution by Key function is executed. The same rules apply. More information: Distribution by Key [page
92].
1.6.2.17 Distribution by Keys
Use
You use the Distribution by Keys function type to create the characteristic combinations that data is distributed
to in accordance with the master data and characteristic relationships. The key figure values are distributed
according to the expressly specified distribution keys. These are distribution functions that determine the
weighting of the distribution.
 Note
For an introduction to how a planning function of type Distribution by Keys works, see Planning Function
Process Flow: Distribution by Keys [page 37].
You use the table for key figure selection to select the key figures that you want to distribute.
You can control the distribution process in various ways:
● Distribution with a top-down variant

○ Distribute All: The entire block is totaled.
○ Only Distribute Non-Assigned: Values are only distributed if they have the characteristic value Not
Assigned [#] in the current block for all of characteristics to be changed.
● Distribution using manually created entries in the From and To Values for Distribution table.
You can create one or more distribute operations by manually entering the characteristic restrictions for
the characteristics to be changed.
The system continually totals the values of the key figures on the From side over all the records in the block
corresponding to the characteristic restriction, and distributes this total to the To values.
In the From and To Values for Distribution able, you can either enter a specific value in the Factor column or
select a formula variable from the input help for the To values. The system displays them in the Factor Variable
Text column.
If the characteristic restriction of a To value is not a single value, this key is valid for every characteristic
combination that corresponds to the characteristic restriction.
Planning Concepts
The keys are normalized during processing; they are converted into percentages. The system first totals the
distribution factors that are assigned to the individual characteristic values and then distributes the values
relatively. This results in percentages that always add up to 100 %.
The same key applies to all the key figures to be distributed for each planning function.
Combinations are generated on the To side for the specified characteristic restrictions. This is consistent with
the master data and the characteristic relationships defined for the InfoProviders. If the system cannot find a
target for a block and a subprocess, it aborts and displays an error message.
 Note
To execute a planning function of type Distribution, the system performs the following steps:
1. The total amount to be distributed is determined.

2. For the data records affected by the From values, the key figure values are deleted.
3. In accordance with the distribution keys, the totals are added together with the key figure values of the
data records selected by the To values.
● Both the From and To values are changed and have to be included in the filter submitted to the planning
function.
If the From value is created in such a way that it can select data records that are not in the filter, the system
does not produce an error message. The data records are not distributed.
If the To value is created in such a way that it can select data records that are not in the filter, the system
terminates the entire planning function and produces an error message.
If a target has been specified in one or more subprocesses, the target contains the relevant totals once the
function has been executed.
● Rounding differences are distributed evenly to those target data records that are not equal to zero.
1.6.2.18 Currency Conversion
Use
You use the Currency Translation function type to convert currencies from key figures to other key figures.
In the Key Figures and Currency Translation Types table, you can specify multiple translations. For each
translation, you have to select a currency translation type as well as a source and target key figure. The value in
the target key figure is overwritten. This also applies if the source key figure is empty. The value of the source
key figure is not changed during currency translation. This means that the function can be executed more than
once without the results changing. A special logic ensures this if the source key figure and target figure are
identical, and the source unit of the data record is used: If the target unit already contains a value, this is
ignored if the source unit contains values that do not have the target unit. Otherwise the value in the target unit
is used.
 Example
The currency translation converts the key figure Amount with the source currency in the data record into
the fixed target currency EURO. The key date 01.01.2001 was selected as time reference. There are two
Planning Concepts
data records for different companies. Company 4711 is planned in CHF. Company 0815 is already planned in
EUR.
Amount Currency Company
10 CHF 4711
4 EUR 0815
10 CHF 4711
6,3 EUR 4711
4 EUR 0815
A new data record is created.
10 CHF 4711
6 EUR 4711
9 EUR 0815
10 CHF 4711
6,3 EUR 4711
9 EUR 0815
The value for company 4711 is overwritten by the currency translation.
Within the planning functions, some of the time references of the currency translation types are not supported.
Selection upon Translation and Query Key Date are not supported. You can use variables in place of these time
references. You can use the variable 0PLANDAT for the query key date. If you want to enter the date when you
execute the planning function, use the input variable.
The changed characteristics can be those characteristics that contain the currency key. By default, all the
characteristics that contain the currency key are selected. You can usually use this setting.
 Note
Note of the following remarks about modeling:
If you want to enter plan data in different currencies, you can use key figures with their own fields for the
currency key for each purpose. Examples for such purposes are Entry of Original Amounts in Company
Planning Concepts
Currency and Consolidation of Amounts in Group Currency. With characteristic relationships you can make
sure that only one suitable currency key can be entered for a company. The aggregation levels can be easily
modeled so that you work with different sets of data for each purpose.
Only those key figures that are used are included in the aggregation level. If you use a key figure for different
purposes, you must define the data with selections in filters.
1.6.3 Default Key Date in Planning Functions
The default key date is a key date that is used in the entire planning model. You can specify a default key date
for each basis InfoProvider.
Use
The following options are available for setting a key date:
● Unspecified (default value is the system date, if all of the involved InfoProviders have the key date =
unspecified).
● Fixed Date
● From Variable
All objects that depend on the key date - such as the filter, hierarchies used in the filter or hierarchies used in
the 'from' and 'to' values of the copy/distribute functions - can be set to the default key date.
When a planning function is executed, the system calculates the default key date as follows:
● If the aggregation level is created directly on a planning-relevant InfoProvider, the default key date is the
same key date that is set for this InfoProvider.
● If the aggregation level has been created on a CompositeProvider, all the involved planning-relevant
InfoProviders below the CompositeProvider are checked. If all these InfoCubes have the setting
unspecified, the default key date is the current system date. If one of the planning-relevant InfoProviders
has a different setting for its key date, the first InfoCube that returns a specific value is the 'winner'.
Variables are evaluated when they are returned.
You also have the option of using a different key date with every time-dependent object.
 Example
This can be useful in certain situations. For example: You want to use a specific hierarchy that is to be read
with another key date than the master data attributes.
Planning Concepts
Related Information

For information about the setting for the key date for planning, see the relevant section in the documentation
for the BW Modeling tools.
1.7 Planning sequence
Planning sequences serve to group planning functions. They allow you to save groups of planning functions in a
sorted sequence and execute groups of planning functions sequentially.
Features
A planning sequence can be made up of one or more steps. There are various types of steps:
Type Description
Planning function Based on an aggregation level, the system saves a planning

function and a filter with which the planning function is exe
cuted.
Input template You can embed input templates in the sequence to test plan
ning functions. Input templates are defined by an aggrega
tion level and a filter.
If a planning sequence is executed in its entirety, the embed

ded input templates are ignored.
Activities
Activity
Test By choosing Execute, you can test planning sequences either

in their entirety or step by step.
Execution in a process chain You can embed a planning sequence in a process chain as
process type Execute Planning Sequence. The planning se
quence can be linked with a stored variant for variable val
ues.
Planning Concepts
Related Information
Scheduling Planning Sequences in Process Chains [page 97]

Planning Sequence for Bottom-Up Planning [page 103]
Creating a Planning Sequence [page 181]
1.7.1 Scheduling Planning Sequences in Process Chains
Use
By integrating planning sequences into process chains, you can execute planning sequences in the
background.
You can include a planning sequence in a process chain by including a process of process type Execute planning
sequence in an existing process chain. In the detailed maintenance of the process, select the required planning
sequence and possibly a suitable variable variant.
For planning sequences that are executed in the background, you can specify whether and how the planning
sequences are to be divided into smaller packages. These packages can be executed in parallel as separate
subjobs in multiple work processes.
You can monitor and analyze the parallel execution using background management (transaction RSBATCH).
Prerequisites
● To schedule a planning sequence in a process chain, you must first create the planning sequence in the BW
Modeling tools.
● You created the required process chain in the process chain maintenance transaction (transaction RSPC)
and defined the behavior of the process chain during execution, if necessary. More information: and
● If your planning sequence contains variables that can only be filled with user entries, or if you want to
overwrite variables with user entries, you can store a variable variant in the BW Modeling tools. You can
refer to this variable variant in the maintenance of the process with which you schedule the planning
sequence.
 Note
You can store variable variants either locally for one user or as global variable variants. If you want to
use a local variable variant, you must also use the user for which the variable variant was created for
the definition of the process and as the user for background execution. More information: Variables
[page 29] and
> Executing User.
Planning Concepts
 Note
Note that changes that were made shortly before execution on an application server are not
necessarily active immediately on all application servers. This depends on the settings for database
buffering in your system and applies for many SAP BW∕4HANA objects as well as for changes to
customer exits. In production systems, you must make sure that at least the time that you selected for
updating database buffering has elapsed between the last change to any objects and scheduling the
process chain.
Procedure
1. In the process chain maintenance, create an application process of type Execute a planning sequence.
 Note
Note that some SAP BW∕4HANA objects use the table buffer for read access. If you want to schedule
planning sequences distributed on more than one server, you therefore have to make sure that the
default time you defined for the table buffer has elapsed between the scheduled start and the last
change (delivery default is 120s).
2. Select the required planning sequence and, if necessary, a variable variant.

3. Choose Apply.
4. In the screen area Activate or deactivate packaging, define whether the planning sequence should be
executed in its entirety or if it should be processed by package.
Option Description
Process Without Packaging The entire planning sequence is executed. The system
only saves all the data on the database when all the con
tained functions have been executed without errors.
No further settings are required for this option.
Process in Packages The planning sequence is executed step by step. The sys
tem writes the modified data to the database after each
step and deletes it from the buffer.
For each step you can set whether and how it should be
packaged. When a step is packaged, the system writes
each individual package that was processed without er
rors to the database.
If you want to process the planning sequence by package, the system reads the steps of the planning
sequence from the database and fills a table. Only those steps of the planning sequence that execute a
planning function are displayed.
Planning Concepts
 Note
The step numbers are copied from the database. Since the steps for input masks are missing, the
numbering is not sequential.
5. If you selected the option Process in packages, you can select which of the following packaging types
should be used for each step.
Option Description
No packaging Precisely one subjob is scheduled with background man

agement for this kind of step. It executes the planning
function for the entire filter of the step.
Automatic packaging The characteristic with which the step is packaged is de
termined automatically when it is executed. You can de
fine the number of packages into which the filter should be
broken down in the last column of the table.
You can also define if the values should be determined

from the master data table or from the dimension table.
(More information is available in section Determining Val
ues for a Characteristic.)
Configured packaging The characteristic with which the step is packaged must
be selected. You can use two kinds of help in selecting the
characteristic.
1. There is a value help for the InfoObject field that permits

you to estimate the number of values for all the character
istics that are possible for the packaging.
2. You can select some steps and display a proposed char

acteristic for them. You can first define how many pack
ages should be created in the last column.
You can also define if the values should be determined

from the master data table or from the dimension table.
(More information is available in section Determining Val
ues for a Characteristic.)
You can define how many individual values of the charac

teristic should be included in a package for the selected
InfoObject.
The system computes the number of packages from the

number of all values divided by the number of values for
each package. It rounds this number up in accordance
with the formula: Number of packages = ceil (number of
all values / number of values per package).
Determining Values for Characteristics
Planning Concepts
There are two ways to determine the values that are relevant for a characteristic. In both cases the
characteristic restriction from the filter is used for the characteristic to be examined.
With this characteristic restriction, either the master data table or the dimension table is read. The master data
table contains all the values for this characteristic. The dimension table contains all the values that are already
stored in the relevant InfoProviders.
 Note
In both cases you can change the values in the tables by running a planning function.
Values can be written to dimension tables for all characteristics that were not yet contained in the
InfoProvider.
The system accesses the SID table for the read type master data for characteristics that do not have a
master data table. In this case new values can occur during execution of a planning function.
Function of the Master Lock
To prevent parts of a planning sequence from not being exIecuted because other users are locking data, the
system locks the data for all steps in advance. When the planning sequence in packages is being processed,
master locks are used. The master process passes a master lock ID to the subjobs.
When execution starts, the master process locks all filters for the lock server. This sets a privilege lock, releases
the normal locks again, and returns an ID for the master lock. From now on, only those work processes that can
certificate themselves using this master lock ID may change the data within the filter. The subjobs certificate
themselves using the master lock, and save the data using a normal lock. When the planning sequence has
been completely processed, the master process releases the master lock.
You can monitor the master locks in BW lock management (transaction RSPLSE). More information: Lock
Concept and Lock Management [page 160]
 Note
In rare cases (for example if the administrator cancels the master process on purpose), the system might
not release the master lock. You can then delete the master lock manually in the lock management
transaction. This assumes, however, that you have authorization to execute the planning sequence. If
subjobs are still open, the system cannot execute them any longer.
Determining the Characteristics in Question for Packaging
Some of the characteristics of an aggregation level on which a planning function is created cannot be
packaged.
● You can only package those characteristics that cannot be changed.

As described above in the section about how the master lock works, the subjobs for the filter packages
request real locks from lock management. In lock management, you can configure the characteristics that
should be relevant for locking for each planning-relevant InfoProvider. To prevent subjobs from mutually
locking one another because their filter packages cannot be separated with regard to lock management,
only selected characteristics can be used for packaging.
● Only certain characteristics can be packaged with respect to lock management. The table below shows
how they are defined.
Planning Concepts
Definition of Characteristics Permitted for Packaging at
Type of Aggregation Level this Aggregation Level
Simple Aggregation Level [page 25] (created directly on a Only the locking-relevant characteristics of the planning-
planning-relevant InfoProvider) relevant InfoProvider are permitted.
Complex Aggregation Level [page 26] (created on a Com A characteristic is permitted if the following rule is satis
positeProvider) fied for all planning-relevant InfoProviders involved: if the
characteristic gets its data from a planning-relevant Info
Provider, it must be relevant for locking.
The figure below shows a complex aggregation level:
Planning function F1 is created on aggregation level A1.

Aggregation level A1 is created on CompositeProvider CP1.
This is provided with data from InfoProviders IP1, D1 and D2.
InfoProvider DIP1 is not a planning-relevant basis InfoProvider. It provides the data for characteristics A, B,
C, D and E in CompositeProvider CP1. However, it does not manage any locks. It is therefore not relevant for
further discussion.
InfoProvider D1 is a data mart DataStore object. It provides the data for characteristics A, B, C, D and F in
CompositeProvider CP1. Characteristics A, B, D and F are entered as relevant for locking in the lock
management.
InfoProvider D2 is a data mart DataStore object. It provides the data for characteristics A, D, E and F in
CompositeProvider MP1. Characteristics A, E and F are entered as relevant for locking in the lock
management.
Planning Concepts
According to the rule described above, the characteristics of the CompositeProvider result in
characteristics A, B, E and F being permitted for packaging:
○ A and F get their values from D1 and D2 and are relevant for locking in both of these. A and F are
therefore permitted.
○ B only gets its data from D1 and is relevant there for locking. B is therefore permitted.
○ C only gets its data from D1 and is not relevant there for locking. C is therefore not allowed.
○ D gets its data from D1 and D2, but is not relevant for locking in D2. D is therefore not allowed.
○ E only gets its data from D2 and is relevant there for locking. E is therefore permitted.
Since the aggregation level does not contain F, the characteristics A, B and E are not used.
In the planning function, E is used as the characteristic to be changed. Therefore only A and B are available
for packaging.
Automatic Selection of Characteristics
If you want to select a characteristic automatically, the required number of packages and how the values
should be determined must be defined.
The system then defines the characteristics permitted for packaging. The number of characteristic values
contained in the relevant characteristic restriction is determined one after the other for these characteristics.
When a characteristic is detected for which the system found more characteristic values than packages were
requested, it is proposed or used for packaging.
Segmenting Filters in Packages
If you want to segment a filter for a step in a package, you must first define which characteristic is used for
packaging and how the value is to be determined. Either the number of packages or the number of values per
package is also defined for each package.
The values are distributed randomly (but can be reproduced) amongst the set of packages so that each
package contains at least one value but does not contain more than the number of values for each package.
Settings for Physical Parallelism
With Parallel Processing in the maintenance for the process of type Execute a planning sequence, you can
overwrite the default values for process type PLSEQ for this process.
The default values for a process type can be stored in background management.
With these settings you can define
● the number of parallel work processes in which the subjobs should be executed
● the servers on which these work processes should be executed
● the priority with which the subjobs should be executed
Step-by-Step Processing of the Planning Sequence
If you selected the Process in packages option, the planning sequence is processed step by step.
Each step is segmented into the required number of subjobs. All subjobs for one step are then scheduled by
background management. The master process checks whether all the subjobs from the last step have been
executed. The next step begins when this check has been completed and if all subjobs were successful. If a
subjob terminates with an error, the planning sequence is not executed. The master process then schedules an
additional subjob to inform background management that the reserved physical work processes can be
released. The master process then releases the master lock.
Planning Concepts
Related Information

Planning Sequence for Bottom-Up Planning [page 103]
1.7.2 Planning Sequence for Bottom-Up Planning
Use
Defining the Planning Sequence
We will investigate an example of a planning sequence that prepares a bottom-up planning process. This
consists of three steps.
1. A linear regression is computed for all existing products and regions based on the actual data for a number
of sales items; this results in the data Forecast for the months of the following year. This version of the data
is stored under the version PLAN_LIN.
2. The sales figures are derived for two new products from similar products. This is done using a copy
function.
3. In bottom-up planning, the planners responsible for the individual regions should adjust the forecasted
numbers to their estimates. However, since you want to get the forecast data for comparison purposes, an
additional version of the data is provided for this planning session. This is also done using a copy function.
All three functions in this example work on the same aggregation level.
● Characteristics: Version, Calendar Month, Region and Product.

● Key figure: Number of items sold.
All characteristics in all the basis InfoProviders are relevant for locking and therefore can be used as a
packaging characteristic.
Overview of the Functions Contained in the Planning Sequence
Step 1. 2. 3.
Function Type Forecast Copy Copy
Comment Writes the data for forecast Copies data in version Copies the forecast data
period to version PLAN_LIN. PLAN_LIN to two new prod from version PLAN_LIN to an
Reference data is read from ucts based on similar prod additional working version
version ACTUALS. ucts that have already been PLAN_BOTTOM for the BOT
sold. TOM-UP planning.
Filter Version = PLAN_LIN, Month Version = PLAN_LIN Version = PLAN_BOTTOM

= Jan 2017–Dec 2017
Characteristics of function Month Product Version

to be changed
Planning Concepts
Step 1. 2. 3.
Function parameters Past: Jan 2015 – Dec 2016, Activity 1: Activity 1:
Past filter: Version = AC From product 77 From version PLAN_LIN

TUALS,
To product 105 To version PLAN_BOTTOM
Forecast period: Jan 2017 –
Activity 2:
Dec 2017,
From product 93
Forecast Parameter: Linear
Regression To product 106
Scheduling the Planning Sequence
The planning sequence should be scheduled within a process chain.
The planning sequence is selected in the detailed maintenance of the process, but no variable variant is
selected because all the contained variables can be replaced without user interaction.
Since the data volume is of medium size, the setting Process in packages is selected. For reasons of clarity, the
steps in the example are divided into few packages, but very different packaging types are selected for these
packages.
Dividing the Planning Sequence into Packages and Packaging Types
Step 1. 2. 3.
Type of Packaging Configured No packaging Automatically
InfoObject Region
Method for dividing into Dimension Dimension

packages
Estimated number of values 10
Package Size 4
Number of packages 3 1 3
Processing
The following graphic provides an overview of the master process that links the planning sequence into the
process chain. It manages the execution of the planning sequence, schedules the subjobs, and collects the
results of the subjobs. The filters of the steps are divided into packages according to the settings and executed
in parallel background processes using the background management.
Planning Concepts
Master process step 1:
● The master collects all the filters and sets a write lock for the SAP BW∕4HANA lock server. The SAP
BW∕4HANA lock server grants it a master lock. The real lock is then released.
● The first filter is divided into three packages with a maximum of four values with the predefined
characteristic Region.
● Three subjobs are scheduled in the background management.
● The master waits until the background management has executed all three subjobs. The system only
performs the next step when all the subjobs have been executed.
● No packaging is configured for step 2 of the planning sequence. For this reason, only one subjob is
scheduled with the entire filter.
● The master waits until the background management has executed the subjob. The system only performs
the next step when this subjob has been executed.
● Automatic packaging with three packages is defined for step 3. The master looks for a characteristic that
has at least three characteristic values and accordingly breaks the filter down into three packages.
● Three subjobs are scheduled in the background management.
End of Master Process:
● The overall status of the planning sequence is recorded and the logs are written for the last time.
● The system removes the master lock.
Planning Concepts
1.8 Implementing a Planning Function Type
A planning function typ is a parameterizable kind of behavior used to modify transaction data. The system
offers you a number of standard planning function types. You can also implement customer-specific planning
function types, in order to implement specific procedures and apply them to transaction data.
Structure of a Planning Function Type
Every planning function type comprises the following parts:
● a definition part (metadata) that is created and changed in the maintenance transaction for planning
function types (RSPLF1),
● an ABAP-OO class in which the actual procedure is programmed. The class name forms part of the
definition.
● If you want to use your own planning function types in the SAP HANA database, you need to implement an
SQLScript procedure and generate the required SAP HANA objects.
 Remember
If you have implemented the customer-specific planning function types for the SAP HANA database, we
recommend making sure that the business logic is also implemented for ABAP runtime. This is mainly for
technical reasons, though it can also be advantageous for example if you are using the SAP HANA database
in your production system but not in your test system and still want to use the same planning function
types.
Integration
In the maintenance transaction for planning function types (RSPLF1), you can display, change, create and copy
customer-specific planning function types.
In terms of transport, Business Content and activation, planning function types behave like other metadata
objects in the SAP BW∕4HANA system. With planning function types in the SAP HANA database however, you
need to transport the SAP HANA objects yourself.
The active planning function types are visible in the BW Modeling Tools and can be used to create and execute
planning functions.
Procedure
1. To call planning function type maintenance, enter transaction RSPLAN.

2. Enter a technical name for the planning function type.
Planning Concepts
3. Choose Create. The screen for creating a planning function type appears.
4. Enter a description for the planning function type and make the required settings on the Properties and
Parameters tab pages.
The next steps in the procedure depend on whether you want to work with the SAP HANA database, or
whether you want the function type to run both in ABAP and on the SAP HANA database.
5. If you want to reuse a customer-specific planning function type and you only want to make slight
modifications, choose Copy.
 Note
For example, you have created a customer-specific planning function type, in order to load data from a
flat file into SAP BW∕4HANA-integrated planning by using a planning function. In this case, the
parameters for this type of upload planning function can be very long, depending on the structure of
the flat file. If you want to use a new flat file with a slightly modified structure for uploading, you need a
new planning function type and the parameter list of this type must be adjusted to suit the structure of
the flat file. Choose Copy to create a new planning function type that copies the parameters from an
existing planning function type. Choose Change to modify the defaults as required. This process is
often quicker than creating all the parameters again as new parameters.
Related Information
Implementing Business Logic for a Planning Function Type in ABAP Classes [page 107]
Implementing Business Logic for Planning Function Types on the SAP HANA Database [page 111]
Parameters of Interface Method execute_sql_script [page 114]
Example of the Implementation of an Interface Method in SQLScript [page 116]
1.8.1 Implementing Business Logic for a Planning Function

Type in ABAP Classes
If you implement and define an ABAP class, you can implement a customer-specific planning function type.
Prerequisites
● You have created a planning function type.
Context
You want to implement an ABAP class for the new planning function type and define its parameters.
Planning Concepts
Procedure
1. You are in the Properties tab page. Create an ABAP class and implement the relevant interface.
Screen Area Description
Implementation Enter the name of the ABAP class that implements the
procedure. The ABAP class has to implement one of the
two interfaces:
○ IF_RSPLFA_SRVTYPE_IMP_EXEC
○ IF_RSPLFA_SRVTYPE_IMP_EXEC_REF
The latter interface is relevant if you need reference
data for your procedure. Implementing methods of
the specified interfaces is optional, with the exception
of method EXECUTE.
The class can also implement specific test methods
that are executed at runtime. This is done using inter
face IF_RSPLFA_SRVTYPE_IMP_CHECK.
You can select the following indicators:
○ Reference Data If this flag is set, reference data is
needed when you execute the planning function.
○ Without Blocks: If this flag is set, the transaction data
is processed without creating blocks, meaning that all
characteristic values in the transaction data can be
changed.
 Note
In this case you cannot create conditions since
the selection table for each condition may only
contain characteristics that can also be used to
create blocks.
○ Process Empty Records: If this flag is not set, all

empty records are ignored during processing.
Characteristic Usage Interface Display Using Web Dynpro and development components, you can
create your own user interface instead of the standard
user interface for characteristic usage. You can also set
the following flags:
○ Hide Column of Characteristics To Be Changed: Set

ting this flag is recommended if you want to perform
processing without blocks, or if the characteristics
you want to change are the result of other settings.
○ Display First When Creating: If this flag is set, the user
interface of the characteristic usage is displayed
firstly when a planning function is created. Otherwise,
the user interface with the parameter values is dis
played.
Planning Concepts
Screen Area Description
Parameter Interface By using Web Dynpro and development components, you

can create your own user interface instead of the standard
user interface for parameters.
2. Go to the Parameters tab page.
Create the required parameters using Create Parameters or Create Components in the context menu for an
object in the parameter hierarchy. You can change the details of existing parameters by choosing
Properties in the context menu. With and , you can change the sequence of the parameters. The
sequence of the parameters is taken into account when you create a planning function for this planning
function type.
With the Parameter is Tabular indicator you can mark a parameter as a table; it will then behave like an
internal table. In this table, each row of the tabular parameter has the properties that correspond to the
selected parameter type. The flag is valid for all parameter types (in the context menu with Properties) with
the exception of Key Figure Selection or if parameters are used as components of a structure parameter.
Parameter Type Description
Elementary The value of an elementary parameter is the value of a

specific InfoObject. This means that every elementary pa
(Elementary Parameter)
rameter is based on an InfoObject and thus inherits its
technical properties. If the InfoObject is a characteristic,
the system automatically checks the validity of a value en
tered by the user based on the master data.
InfoProvider InfoObject The parameter can include the name of an InfoObject

from the current InfoProvider (aggregation level). You can
define the valid InfoObjects by selecting Restrict.
InfoObject:
○ Key Figures Only are valid.

○ All characteristics
Only characteristics are valid, but these have no re
strictions.
○ Block Characteristics Only
Block characteristics are used to group the transac
tion data (see Without Blocks above)
○ Characteristics To Be Changed Only
Only characteristics that are changed by a planning
function are valid. Block characteristics are therefore
not valid.
○ Condition Characteristics Only
Only characteristics that are used in the planning
function to define the condition are valid.
Data Selection Data selection parameters can include selection critera

from a number of characteristics, depending on which are
Planning Concepts
Parameter Type Description
needed for defining filters. This is therefore a special se

lection table. You define the characteristics that are valid
for the data selection by selecting Chars. Restriction:
○ All Characteristics
All characteristics of the InfoProvider are valid.
○ Block Characteristics Only
Block characteristics are used to group the transac
tion data (see Without Blocks above)
○ Characteristics To Be Changed Only
Only characteristics that are changed by a planning
function are valid. Block characteristics are therefore
not valid.
○ Condition Characteristics Only
Only characteristics that are used in the planning
function to define the condition are valid.
Structure With a structure parameter, you can declare other param

eters as components of the structure parameter and thus
(Structure Parameter)
combine them into a structure. Parameters of type Ele
mentary, InfoObject of the InfoProvider and Data Selec
tion are valid as components.
To declare a parameter as a component, choose either

Create Component in the context menu of a structure pa
rameter or its components, or Properties Structure
Parameter in the context menu of another parameter.
Key Figure Selection This parameter type selects the key figures to be proc
essed. It is therefore a special case of the type InfoObject
of the InfoProvider.
Example
The planning function types delivered by SAP are based on the same technical concept as the customer's own
planning function types and can thus be viewed in the maintenance of the planning function types.
 Example
The function type Delete( 0RSPL_DELETE) is a simple example. There is only one parameter (KYFSEL) for
selecting key figures to delete. In the associated ABAP class, interfaces IF_RSPLFA_SRVTYPE_IMP_CHECK
and IF_RSPLFA_SRVTYPE_IMP_EXEC are implemented.
Planning Concepts
1.8.2 Implementing Business Logic for Planning Function
Types on the SAP HANA Database
You can execute an optimized customer-specific planning function type on the SAP HANA database by
implementing an SQLScript procedure.
Prerequisites
● You have created a planning function type.

● You are using SAP HANA-optimized processing in SAP Business Planning and Consolidation, version for
SAP BW/4HANA, (embedded configuration).
Context
You want to create an ABAP class for the new planning function type in the SAP BW∕4HANA system, implement
and parameterize the relevant interface, as well as create the required objects on the SAP HANA database from
the SAP BW∕4HANA system. You can implement the die SQLScript procedure in the SAP HANA Studio.
Procedure
1. Create an ABAP class in Class Builder (transaction SE24) and implement one of the following interfaces:
○ IF_RSPLFA_SRVTYPE_TREX_EXEC must be implemented if no reference data is used,

○ IF_RSPLFA_SRVTYPE_TREX_EXEC_R must be implemented if reference data is required during
execution.
As with ABAP, the class can also implement specific test methods that are executed at runtime. Interface
IF_RSPLFA_SRVTYPE_IMP_CHECK serves this purpose. You can set the flag for reference data: If this flag
is set, reference data is needed when you execute the planning function.
Implementing methods of the specified interfaces is optional, with the exception of method
trex_execute.
Method init_and_check (of interface IF_RSPLFA_SRVTYPE_TREX_EXEC or

IF_RSPLFA_SRVTYPE_TREX_EXEC_R) must set exporting parameter E_TREX_SUPPORTED to ‘X’ or
rs_c_true, so that the SQLScript procedure is called.
For method if_rsplfa_srvtype_imp_exec_ref->get_ref_data_sel, at least one empty method

must be created if using reference data.
 Caution
Unlike with ABAP implementation, you have to implement block creation of transaction data in the
SQLScript procedure yourself, meaning that all characteristic attributes in the transaction data can be
changed without the need for further implementation.
Planning Concepts
2. From your implementation, call interface method if_rspls_sql_script -> execute_sql_script,
which calls the SQLScript procedure.
3. Implement the SQLScript procedure that should be called by interface method if_rspls_sql_script -
> execute_sql_script.
 Caution
Parameter I_SQL_SCRIPT_RETURNS_AI (of method if_rspls_sql_script ->

execute_sql_script) can be used to define whether the result table of the procedure should be
further processed as delta records or as result records. If delta records are required, the values from
the result table are aggregated to the starting values.
 Note
Note that the SQLScript procedure requires an IN table and an OUT table. Both of these must have the
structure of the aggregation level. If you have implemented interface
IF_RSPLFA_SRVTYPE_TREX_EXEC_R, the SQLScript procedure requires another table with the same
structure for the reference data. The SQLScript procedure can also contain elementary IN parameters.
○ We recommend implementing the SQLScript procedures as AMDPs (ABAP Managed Database

Procedures), in order to integrate these implementations into the Transport Management System in
AS ABAP. For SQLScript procedures, you can therefore use the Transport and Lifecycle Management
that you are familiar with from working with ABAP development objects. This also simplifies
development because access to SAP HANA Studio is not required.
 Note
For more information about AMDP, see the ABAP key word documentation at
○ http://help.sap.com/abapdocu_740/en/index.htm?file=abenamdp.htm
○ http://help.sap.com/abapdocu_740/de/index.htm?file=abenamdp.htm
○ Alternatively, you can implement the SQLScript procedures in SAP HANA Studio.
4. The program RSPLS_SQL_SCRIPT_TOOL (transaction code SE38) helps you to implement the class for the
planning function type or to implement an SQLScript. SQLScript requires a typed interface. The
SQLScript must know the aggregation level, which the SQLScript is operating on. For SQLScripts you can
use custom parameters. You can specify a structure type for these parameters. The components of the
structure are passed to the SQLScript where they can be used.
○ On the Display SQLScript Implementations tab, you see an overview of the existing planning functions,
for which an SQLScript is executed.
○ On the Sample Planning Function Type tab, you can create sample code for AMDP implementations for
planning function types. You can then copy this code into the implementing class.
An iterative process is used for implementation, in order to create the implementing class and the
planning function type. The planning function type needs this class. The implementation of class must
take the settings in the planning function type (parameters of the planning function type) into
consideration.
Depending on where you are in the iterative process, you can create a code suggestion for an ABAP
class or for a planning function type.
Besides passing parameters via a structure, you can also pass parameters in a list (name, InfoObject,
value) for planning function types. In the sample code, this option is suggested (call of l_r_sql_script-
>get_parameter_values), in order to collect the values of the elementary parameters of the planning
function with the values of the planning function in table l_t_iobj_param.
Planning Concepts
 Note
If you set the user parameter (transaction SU3) SEO_SOURCEBASED_AMDP to the value "X", you can
also edit AMPD methods in the source-code-based class editor (SE24 or SE80).
○ We recommend implementing the SQLScript procedures as AMDPs (ABAP Managed Database

Procedures) in order to integrate these implementations into the Transport Management System in
AS ABAP. For SQLScript procedures, you can therefore use the Transport and Lifecycle Management
that you are acquainted with from working with ABAP development objects. This also simplifies
development because access to SAP HANA Studio is not required.
For AMDPs only the source code sections, which you need to insert into the implementing class, are
created as a list.
○ If you do not use AMDP, you must create the following objects in SAP HANA Studio:
○ A table with a structure that matches the structure of the aggregation level. This table can be used
to set the type of the table parameters in your SQLScript procedure.
○ The body of the SQLScript procedure. This procedure body contains the table parameters for the
data that this procedure should change, and the return table with the result of the procedure. All
elementary parameters of the function are added to the parameter list too, together with the
relevant types.
 Note
For table types and procedures, objects are created in SAP HANA, if the test parameter is
deactivated. On the SAP HANA Objects tab, you can display structure types and SQL procedures
defined on SAP HANA (including, for example, the AMDP methods and the structure types used in
the AMDP interface). If you want to write SQLScripts for planning functions directly to SAP HANA,
you can create an empty procedure body with the required types and then delete them again later
on.
Related Information

These two sections explain the second step in the procedure: creating the parameterization of the interface
method for Studio: execute_sql_script.
Planning Concepts
1.8.2.1 Parameters of Interface Method execute_sql_script
Interface method if_rspls_sql_script -> execute_sql_script calls the SQLScript procedure. The
table below provides an overview of the parameters of this method.
Parameter Type Parameter Type Description
I_VIEW Type Importing Set i_view. This is the import

ing parameter of method
TREX_EXECUTE.
I_VIEW_REF Type Importing If you are using

IF_RSPLFA_SRVTYPE_TREX
_EXEC_R, set i_view_ref. This
is the importing parameter
of method TREX_EXECUTE.
I_T_IOBJ_PARAM Type Importing Every row in this table repre

sents a parameter in the SQL
script procedure. The fields
are as follows:
● NAME: Name of the pa

rameter
● IOBJNM: InfoObject
that sets the type of the
parameter.
● VALUE: Parameter
value
I_DB_SCHEMA_NAME Type Importing Schema in which the

SQLScript procedure was
created.
With AMDP, do not. pass this

parameter.
I_PROC_NAME Type Importing Name of the SQL script pro

cedure
I_R_MSG Type Ref To Importing Set i_r_msg. This is the im

porting parameter of method
TREX_EXECUTE.
Planning Concepts
Parameter Type Parameter Type Description
I_SQL_SCRIPT_RETURN Type Importing Default value is ‘ ‘. If you keep

S_AI the default value or explicitly
pass ‘ ‘, the system handles
the result as a delta. - The
data calculated by the proce
dure are aggregated to ag
gregation level data that is
stored in the planning buffer.
If you pass the value ‘X’, the

result is handled as an After
Image.
I_T_ABAP_DATA Type Importing ABAP table with a flat struc

ture without components of
type reference.
I_T_AGGR_VIEW Type Importing You also have the option of

passing a list of aggregation
levels together with selection
criteria. In SQLScript you can
access these aggregation
levels as reference data. If
the data of an aggregation
level is changed in the same
session, the system access
the changed data.
I_T_HAAP_PARAS Type Importing You have the option of pass

ing a list of SAP HANA HANA
analysis processes.
I_T_HAAP_PARAMETER_ Type Importing To access the views of the

MAPPING SAP HANA HANA analysis
processes, you need to use
placeholders in the SQL
statement. With this table
you can specify parameter
names that can be used to
pass placeholders to the
SQLScript.
R_RESULT_VIEW Type Returning Copy over the return value of

interface method
if_rspls_sql_script ->
execute_sql_script to
return value r_s_view-view of
implemented method
TREX_EXECUTE.
Planning Concepts
Related Information
1.8.2.2 Example of the Implementation of an Interface

Method in SQLScript
The following section provides an example of how method if_rsplfa_srvtype_trex_exec_r ~

trex_execute can be implemented.
You can find the example below in program RSPLS_SQL_SCRIPT_TOOL.
 Caution
Note that you have to implement a public class, so that this class can be assigned to the planning function
type.
 Sample Code
METHOD if_rsplfa_srvtype_trex_exec_r~trex_execute.
DATA: l_r_sql_script TYPE REF TO if_rspls_sql_script,
l_procedure_name TYPE string,
l_srvtypenm TYPE rsplf_srvtypenm,
l_t_iobj_param TYPE if_rsr_pe_adapter=>tn_t_iobj_param.
l_r_sql_script =
cl_rspls_session_store_manager=>get_sql_script_instance( i_r_store =
i_r_store ).
* The method if_rspls_sql_script~get_parameter_values returns a table of
parameters
* with the values given in the function definition
l_r_sql_script->get_parameter_values(
EXPORTING
i_r_param_set = i_r_param_set
i_para_name_for_procedure = 'HANA_PROCEDURE_NAME'
IMPORTING
e_procedure_name = l_procedure_name
e_t_iobj_param = l_t_iobj_param ).
* The function parameter given method paramenter i_para_name_for_procedure
* will not be returned in the table e_t_iobj_param but the value of this
* function parameter will be returned int the method parameter
e_procedure_name
* This mechanisme can e.g. be used to define function specific SAP HANA
procedure names.
* Other examples to get the name of the SAP HANA procedure name which will
be called can be
* - you use the technical name of the planning function type:
l_srvtypenm = p_r_srv->get_srvtypenm( ).
l_procedure_name = l_srvtypenm.
* - or you simply give the SAP HANA procedure name in a string:
l_procedure_name = 'MY_HANA_PROCEDURE'.
r_s_view-view = l_r_sql_script->execute_sql_script(
i_view = i_view
i_view_ref = i_view_ref
i_t_iobj_param = l_t_iobj_param
i_proc_name = l_procedure_name
Planning Concepts
i_r_msg = i_r_msg ).
ENDMETHOD. "IF_RSPLFA_SRVTYPE_TREX_EXEC_R~TREX_EXECUTE
Related Information
1.9 Input-Ready Query
Use
You can use input-ready queries to create applications for manual planning. These can range from simple data
entry scenarios to complex planning applications. Input queries at runtime still enable you to edit short texts in
the query, in order to change classifications, for example, or enter user-defined comments for key figure values.
Integration
You can use the input-ready queries in different clients and combine them with other queries and planning
functions, in order to make complex planning applications.
Related Information
The following links take you to the documentation for BW Modeling Tools in Eclipse.
This is a link to the documentation for the Analytic Manager analysis functions.
Planning Concepts
1.9.1 Input-Ready Queries at Runtime
In planning applications that use input-ready queries as data providers, you can enter data manually at
runtime. Whether the cells in an input-ready query can be changed at execution depends on the query view and
possibly on other settings (such as settings for data slices and characteristic relationships).
In terms of whether the cells of a query view are input ready, note the following rules:
1. In a query that is used for manual planning, a cell is only input ready if each characteristic value of all the
characteristics included in the aggregation level is unique. This means that any values aggregated for the
aggregation level are not input ready: Totals, subtotals and internal hierarchy nodes are not input ready.
2. To be able to change values for calculated key figures too (Average Price as a quotient of Amount and
Quantity for example), they must be based on formulas, and at least one operand must be input ready.
3. To be able to change aggregated values (for the aggregation value), these values must be disaggregated on
all data records that contribute to them.
4. If a query used for manual planning includes a navigation attribute that is restricted using a fixed or
dynamic filter or a restricted key figure, the system treats the navigation attribute as a normal
characteristic. The rule under point 1 applies here. If the navigation attribute is not restricted, the system
responds as if the navigation attribute was not part of the query.
5. If you have a query defined on a CompositeProvider or a complex aggregation level and you want to use
this query for manual planning, a cell is input-ready if a maximum of one aggregation level is involved on
the route from the InfoProvider of query to the plannable basic InfoProvider.
○ If the query is defined on a complex aggregation level, the PartProvider determined by the cell must be
a plannable basic InfoProvider.
○ If the query is defined on a CompositeProvider, the PartProvider determined by the cell must be a
simple aggregation level on a plannable basic InfoProvider.
The plannable basic InfoProvider must also be in planning mode.
6. If an input-ready query is executed in change mode, but the requested data is locked by another user, the
query starts in display mode.
Related Information
Defining Inverse Formulas [page 130]

Examples: Inverse Formula [page 136]
Inverse Formulas at Runtime [page 138]
Percentage Functions at Runtime [page 141]
Examples: Inverse Formulas at Runtime [page 142]
Disaggregation (Top-Down Distribution) [page 121]
Planning Concepts
1.9.2 Displaying All Valid Characteristic Combinations
You can use characteristic relationships for planable basic InfoProviders to model valid combinations of
characteristic values. The system uses this information to propose combinations of characteristics in input-
ready queries that values have not been saved for yet.
Use
To generate valid combinations, the system uses the current values from the filter of the query and the
relations from the characteristic relationships.
Prerequisites
● You have modeled characteristic relationships.

● You have defined an input-ready query.
Procedure
When you define a query, you can set the access type for the result values going to the characteristic’s
properties and choosing Access Type for Result Values:
● If you want to use the combination proposal for planning, choose Characteristic Relationships. If a
characteristic is not be included in a relation, the system uses the master data to generate the valid
combinations. As characteristic relationships are defined for a planable basic InfoProvider, the system
creates the valid combinations for the planable basic InfoProviders concerned in each case. The technical
characteristic relationships for time characterisics and navigation attributes are also taken into account
here.
● If you select the Master Data option, the system first generates all possible combinations that are only
restricted by time characteristics and navigation attributes. In this case, the InfoObjects are always used
from the InfoProvider that the query is defined on. This process can produce data cells for characteristic
combinations that are invalid according to characteristic relationships. The system checks all cells that are
created. Cells for invalid combinations are not input ready.
 Note
If you choose Characteristic Relationships or Master Data, note that a considerable number of
combinations can be generated. Make the settings in the filter correspondingly restrictive for
characteristics of this kind. You can specify a maximum number of combinations for characteristic
relationships for each planning-relevant basic InfoProvider. Note that characteristic relationhips do not act
as a further implicit filter for the transaction data to be read. The system reads the transaction data
specified by the filter of the query (regardless of whether this is valid or invalid according to the
characteristic relationship) and then possibly also creates further combinations in accordance with the
rules described above.
Planning Concepts
Example
In sales planning, you are planning (rolling) quantities for periods in a predefined time interval (a year for
example). The products are arranged in a Product Hierarchy that you have modeled using the characteristic
relationships. Product belongs to a Product Group which in turn belongs to a Product Line. You use these
characteristics in the rows of an input-ready query. In the columns, you use key figure Sales Quantity, and time
characteristicFiscal Year/Period in the drilldown. Under Access Type for Result Values, you choose
Characteristic Relationships for these four characteristics. The system then generates the valid combinations in
the rows. For characteristic Period/Year, the system detects all the valid periods from the master data in the
filter. It generates the corresponding number of combinations in the key figure structure with the values for the
periods.
The following graphic provides an example of this type of planning:
 Note
In fiscal year variants, note that the special periods are considered valid master data. If you use fiscal year
variant Q4, the system proposes the special periods 13.2006, … 16.2006 and period 0.2007 for the
selection 1.2006 - 12.2007. If you do not want to use these values in planning, you have to remove them
from the selection.
Planning Concepts
Related Information

1.9.3 Disaggregation (Top-Down Distribution)
Disaggregation (also called top-down distribution) helps you to enter data manually in manual planning. It
allows you to make manual entries in input-ready queries, also when using aggregated values related to an
aggregation level.
Input ready queries are always defined in relation to aggregation levels. Without disaggregation functionality,
the following applies: a cell is only input-ready if every characteristic value of all the characteristic values
contained in the aggregation level is determined uniquely. This means that cells, which contain aggregated
values related to the aggregation level, are not input-ready. This includes totals, subtotals and internal
hierarchy nodes.
Disaggregation also allows you to changes values that are aggregated in terms of the aggregation level. To do
this, the changed values must be distributed top-down to all data records that contribute to the aggregated
values of the cell. We call this top-down distribution disaggregation.
 Caution
Please note that disaggregation does not invalidate the current planning modeling: new data records and
delta data records are always created based on the aggregation level. Disaggregation only helps with
manual data input in input-ready queries.
Disaggregation in input-ready queries can have an effect on the application modeling of the planning,
especially in the area of characteristic relationships.
Before a changed value of a query cell can be disaggregated, the system must first determine all data records
that contribute to the cell value. In order to read this data, the system adds all the characteristics of the
involved aggregation levels to the drilldown (in addition to the characteristics already contained in the rows or
columns). If you want to use disaggregation in the query, the data for disaggregation must be available, or you
need to generate them via the query settings for disaggregation.
This can be done for example by the setting for creating combinations in the query (Access Type for Result
Values. Please note that the filter of the query is restricted so that the number of generated combinations
remains within in an appropriate range.
If you choose the Always Disaggregate Unposted Values setting when defining an input-ready query, the system
overwrites the system overwrites the Access Type for Result Values setting for every characteristic. This means
that all valid combinations (in accordance with characteristic relationships) are created for every
disaggregation and then disaggregated on these combinations. This also applies if the query only displays
posted data. This setting can be helpful, for example, if the input-ready cells are empty in the planning because
disaggregation should still be possible without data. Please note that the filter of the query is restricted so that
the number of generated combinations remains within in an appropriate range. A typical use case for this
setting is a query that is only compressed for a time characteristic (cost center planning).
Planning Concepts
 Note
The disaggregation concept in input-ready queries is not designed for mass data. If you want to process
mass data via disaggregation in the query, we recommend that you use the top-down planning function
type.
Disaggregation is only available for basic key figures with aggregation type SUM or NO2, but not for calculated
key figures, key figures with exception aggregation, local aggregations and time key figures. In the query
definition, it is possible to model and parameterize the disaggregation behavior of a specific structure element:
Modeling Functionalities for Disaggregation
Basic Key Figures with Aggregation Basic Key Figures with Aggregation
Option Type SUM Type NO2
No Disaggregation: No disaggregation x x
Disaggregate Entered Value: Disaggre x -

gate entered value
Disaggregate Difference to Entered x -

Value: Disaggregate difference
Disaggregate Copy: Copy the entered - x

value
Type of Distribution
Basic Key Figures with Aggregation Basic Key Figures with Aggregation
Option Type SUM Type NO2
Equally: Equal distribution x -
Same as in reference object (self ref x -

erence): Analogous distribution (to
self)
Same as in reference object: Analo x -

gous distribution (a different structural
element)
Related Information
The following link takes you to the documentation for BW Modeling Tools in Eclipse.
Displaying All Valid Characteristic Combinations [page 119]
SAP Note 994853
These links provide you with further information about the planning concepts.
No disaggregation [page 123]
Planning Concepts
Disaggregate Entered Value, Equal Distribution [page 123]
Disaggregate Entered Value, Analog Distribution (Self-Reference) [page 124]
Disaggregate Value Entered, Analog Distribution (to Following Structural Element) [page 125]
Disaggregate Difference To Value Entered, Equal Distribution [page 125]
Disaggregate Difference to Value Entered Value, Analog Distribution (Self-Reference) [page 126]
Disaggregate Difference to Value Entered, Analog Distribution (with Reference to Following Structure Element)
[page 127]
Copying Disaggregation, Homogenous Values [page 128]
Copying Disaggregation, Inhomogeneous Values [page 128]
Disaggregation with Hidden Reference Data [page 129]
Disaggregation at runtime: These sections contain simple examples, which explain how the system distributes
values according to the configured settings.
1.9.3.1 No disaggregation
Example scenario: The aggregation level contains the following characteristics: Product, Version, Fiscal Year
Variant, Fiscal Year, Currency, and the key figure Amount. Product is drilled down in the rows, and all other
characteristics are limited to one value. In the query, the key figure Amount is defined by the setting No
Disaggregation.
The table below table shows the result without disaggregation:
Amount (Before In Amount (Manual In

Product Amount (Reference) put) put) Amount (After Input)
TFT 17" Monitor 1 20 20 20
TFT 19" Monitor 1 10 14 14
TFT 21" Monitor 1 0 2 2
Result 3 30 30 36
This result row is not input-ready. The result row is only updated when the values in the input-ready cells are
changed, and these values are transferred.
Related Information
1.9.3.2 Disaggregate Entered Value, Equal Distribution

Planning Concepts
characteristics are limited to one value. In the query, settings Disaggregate entered value and Equal distribution
are selected for key figure Amount.
The following table shows the result of this disaggregation:

TFT 17" Monitor 1 20 20 12
TFT 19" Monitor 1 10 10 12
Result 3 30 36 36
This result row is input-ready. The result value was changed from 30 to 36. The value 36 was then distributed
evenly to all three affected cells (36/3 = 12).
Related Information
1.9.3.3 Disaggregate Entered Value, Analog Distribution

(Self-Reference)
characteristics are limited to one value. In the query, settings Disaggregate entered value and Analog
distribution (self-reference) are selected for key figure Amount.

TFT 17" Monitor 1 20 20 24
TFT 19" Monitor 1 10 10 12
Result 3 30 36 36
This result row is input-ready. The result value was changed from 30 to 36. The value 36 was then distributed to
the cells analogously to the weighting of the previously contributing cells. The value for TFT 21" monitor is
unchanged in the result.
Planning Concepts
Related Information
1.9.3.4 Disaggregate Value Entered, Analog Distribution (to

Following Structural Element)
characteristics are limited to one value. In the query, settings Disaggregate entered value and Analog
distribution (with reference to following structural element) are selected for key figure Amount.

TFT 17" Monitor 1 20 20 12
TFT 19" Monitor 1 10 10 12
Result 3 30 36 36
This result row is input-ready. The result value was changed from 30 to 36. As a result of the selected
distribution type, the values in key figure Amount (Reference) are used as reference for the analog
distribution of the changed value. (In this example this produces the same results as with the No
Disaggregation setting.)
You can model most flexibly if you set key figure Amount (Reference) to input-ready. This allows you to set
the weighting for distribution of the values from the reference column.
Related Information
1.9.3.5 Disaggregate Difference To Value Entered, Equal

Distribution
Planning Concepts
characteristics are limited to one value. In the query, the Disaggregate difference to entered value and Equal
distribution are selected for key figure Amount.
The followng table shows the result of this disaggregation:

TFT 17" Monitor 1 20 20 22
TFT 19" Monitor 1 10 10 12
Result 3 30 36 36
This result row is input-ready. The result value has been changed from 30 to 36. This time the new value was
not distributed to the affected cells. Instead, the difference in the value before and after input was distributed,
in this case 6. As equal distribution was selected, all affected cell values are changed by 6/3 = 2.
Related Information
1.9.3.6 Disaggregate Difference to Value Entered Value,

Analog Distribution (Self-Reference)
characteristics are limited to one value. In the query, the Disaggregate difference to entered value and Analog
distribution (self-reference) are selected for key figure Amount.
The followng table shows the result of this disaggregation:

TFT 17" Monitor 1 20 20 24
TFT 19" Monitor 1 10 10 12
Result 3 30 36 36
This result row is input-ready. The result value has been changed from 30 to 36. This time the new value was
not distributed to the affected cells. Instead, the difference in the value before and after input was distributed,
Planning Concepts
in this case 6. The 6 was then distributed analogously to the previous cell values, weighted therefore. The result
corresponds to disaggragation with the settings Disaggregated entered value and Analog distribution (self-
reference).
Related Information
1.9.3.7 Disaggregate Difference to Value Entered, Analog

Distribution (with Reference to Following Structure
Element)
characteristics are limited to one value. In the query, settings Disaggregate difference to entered value and
Analog distribution (to following strucural element) are selected for key figure Amount.

TFT 17" Monitor 10 20 20 20 + 2 = 22
TFT 19" Monitor 0 10 10 10 + 0 = 10
TFT 21" Monitor 20 0 0 0+4=4
Result 30 30 36 36
This result row is input-ready. The result value was changed from 30 to 36. This time the new value was not
distributed to the affected cells. Instead, the difference in the value before and after input was distributed, in
this case 6. As a result of the selected distribution type, the values in key figure Amount (Reference) were
used as the reference for the analog distribution of the changed value.
Related Information
Planning Concepts
1.9.3.8 Copying Disaggregation, Homogenous Values
In this example, disaggregation Copy is used for key figure Price. Price is a basic key figure with aggregation
NO2 (no aggregation) and has homogenous values for all products.
The values for Price are 10 for all products. The result value is therefore also 10.
The table below table shows the result of this disaggregation:
Product Amount (Reference) Price (Before Input) Price (Manual Input) Price (After Input)
TFT 17" Monitor 10 10 10 36
TFT 19" Monitor 0 10 10 36
TFT 21" Monitor 20 10 10 36
Result 30 10 36 36
This result row is input-ready. The result value was changed from 10 to 36. The value 36 was then copied to all
incoming cells in the result value.
Related Information
1.9.3.9 Copying Disaggregation, Inhomogeneous Values
In this example, disaggregation Copy is used for key figure Price. Price is a basic key figure with aggregation
NO2 (no aggregation) and has no homogeneous values for various products.
The values for Price are for all products. Therefore the result value is ‘*’ (or “NOP” or “NONEX”).
Product Amount (Reference) Price (Before Input) Price (Manual Input) Price (After Input)
TFT 17" Monitor 10 10 10 36
TFT 19" Monitor 0 20 20 36
Result 30 * 36 36
This result row is input-ready. The result value was changed from ‘*’ (for inhomogeneous values) to 36. The
value 36 was then copied to all incoming cells in the result value.
Planning Concepts
Related Information
1.9.3.10 Disaggregation with Hidden Reference Data
characteristics are limited to one value. In the query, settings Disaggregate entered value and Equal distribution
are selected for key figure Amount.
All the examples have in common that the reference data for the distribution exists in the query view. This is
rarely the case in a real-life scenario however. This can result in seemingly incorrect results. The following
example contains a seemingly incorrect result, which is actually correct however.
The following data is assumed. All characteristics that are not mentioned have a fixed value.
Product Fiscal Year Amount
TFT 17" Monitor 2007 0
The same query view as above is shown below, with the difference that Fiscal Year characteristic is not
drilled down. The result is:

Result 0 0 6 0
Let us assume that distribution type Equal distribution is selected. If the result row is changed from 0 to 6, the
values will be distributed as in the table, as the system reads all data records that contribute to the result value.
There is a different number of data records for each product. In the result, the values are not distributed
equally in terms of Product after aggregation by Fiscal Year, even though the system uses distribution
type Equal distribution.
Planning Concepts
 Note
In the situation described above, a drilldown by Fiscal Year could have made all the data records used
for the distribution visible. Provided that the query is not too large, this method can help to better
understand the result.
Related Information
1.9.4 Defining Inverse Formulas
Use
Input-Ready Formulas, Inverse Formulas and Formula Groups
This section provides a more precise description of the definition of inverse formulas using mathematical
notation.
 Note
For examples of inverse formulas, see Examples: Inverse Formulas [page 136] and SAP Note 1236347 .
To describe an inverse formula precisely, we start by defining a notation. Let.
F = F(op1, …, opn)
is a formula with the operands op1 to opn. If formula F is input ready, we call it the carrier of a formula group. By
definition, the formula group consists of the operands op1 to opn and the formula F.
Planning Concepts
For input-ready formulas, inverse formulas and formula groups, the following rules apply and are checked in the
query definition or when the query is generated by the system:
FG1: The following objects can be used as operands opi, i = 1, ..., n for an input-ready formula F:
1. Basic or restricted key figures

2. Constants or 'reporting' formulas. These are formulas that do not change if a manual change is made during a server
roundtrip
3. Carriers of another formula group G, where F ≠G and G is not %GT (Percentage of Grand Total), %XT (Scale to Result
Along the Columns), %YT (Scale to Result Along the Rows)
FG2: If operand opi is input-ready, an inverse formula needs to be defined in Query Designer, calculating the opi from the
following operands: F, op1, ..., op(i-1), op(i+1), ..., opn.
FG3: All elements in the formula group must be either in the key figure structure or in exception cells. The latter only applies
for queries with two structures.
Exception: %GT (Percentage of Grand Total), %XT (Scale to Result Along the Columns), %YT (Scale to Result
Along the Rows)
If you want to calculate the percentage of the grand total, choose formula F= %GT. Only one operand is allowed
in this case. This operand must be a basic key figure or a restricted key figure with disaggregation activated.
You do not need to define an inverse formula. The same rules apply for %XT and %YT.
Comments
● If you create inverse formulas, the system checks which operands inverse formulas need to be created for
and creates a list of them. By double-clicking on an inverse formula, you can call the Change Formula
screen. Under Available Operands, the system displays a list of all operands allowed for converting the
formula.
● The inverse formula for an input-ready operand of an input-ready formula is created by resolving the
formula to the input-ready operand.
● It is also possible to define input-ready formulas in a reusable structure. All elements of the formula group
then have to be in the reusable structure.
● In a query with input-ready formulas, the key figures must not be only in the query filter.
● The system supports concatenation of formulas. Formulas can also have intersections and be contained in
other formulas. Nesting must not have a cycle.
 Caution
Note that input-ready or inverse formulas containing a formula of variable type Replacement Path
cannot be nested, thus always allowing the system to replace the variable with the system data
attributes of a characteristic.
● Inverse formulas are technical objects that are needed for inversion of input-ready formulas. On the
General tab for the Display setting, inverse formulas therefore have the setting Always Hide as the default
setting. For debugging purposes, it can be useful to show these technical formulas.
Queries with Two Structures
To provide a precise description of how to use formulas in queries with two structures, we start by defining a
notation.
Planning Concepts
Let a query contain two structures, X and Y:
X contains the elements X1, …, Xm and is displayed in the columns.
Y contains the elements Y1, …, Yn and is displayed in the rows. Y contains the key figures.
The intersection of two structural components Yi and Xk are cells, denoted by Yi/Xk = cik. These cells are
always generated by the system. In the cell editor in the query definition, you can define these cells explicitly as
exceptional cells. Exceptional cells can be of type Cell Reference, Selection or Formula.
The table below shows cells that are created when the two structures X and Y are used:
Y/X X1 ... Xi ... Xm
Y1 C11 C1j C1m
...
Yi Ci1 Cij Cim
...
Yn Cn1 Cni C
nm
Let Yn = F = F(Y1, …, Yk) be the carrier of the formula group, meaning that k < n and Yn is an input-ready
formula. Operands Y1, …, Yk have one of the types named above under rule FG1. As the notation shows, the
input-ready operands all have to be contained in row structure Y. This gives us the first rule:
C1: If a query contains two structures and no exceptional cells, input-ready formulas and inverse formulas can only be defined
in one structure, meaning that all input-ready formulas and inverse formulas have to be contained in the key figure structure.
Rule C1 is a paraphrase of rule FG3.
The actual formulas to be calculated in the cells in row Yn for column Xj in the table above can be obtained by
replacing the operands Y1 … Yk with the corresponding cells c1j …ckj. The same applies for inverse formulas.
Example
Let n = 3 and Y3 = Y2 / Y1, where Y3 is Average Price, Y2 is Sales and Y1 is Quantity. Let m = 3 and X1, X2 be of
type Selection, containing restrictions by characteristic Process Type such as Sales Order and Billing Data in a
profitability analysis scenario. X3 contains the formula X3 = X1 + X2.
Y/X X1 X2 X3 = X1 + X2
Y1 C11 C12 C13 = C11 + C12
Y2 C21 C22 C23 = C21 + C22
Yn C31 = C21 / C11 C32 = C21 / C12 1. C33 = C13 / C23

2. C33 = C31 + C32
Planning Concepts
As this example shows, we have to define whether intersections between input-ready formulas and reporting
formulas can be input ready, and whether inverse formulas can be calculated there.
Using a more general notation, let Xm be a formula. A rule of precedence needs to be defined here for the
intersections Yn = F and Xm. If a rule is not defined, the system takes the structure element that was saved
most recently. On the Advanced tab for the structure element Yn or Xm, you can define whether the system
takes this formula or the formula from the other structure for the calculation.
Yn is an input-ready formula, however, and inverse formulas exist for the input-ready operands Y1,…, Yk. As the
example shows, it makes no difference at the intersection of Yn and Xm whether the system calculates the
formula from Yn or from Xm: Cell Yn/Xm cannot be input ready, as this would also make it necessary to have a
formula inversion for this cell. As Xm is a reporting formula however, and has no inversion, inversion is not
possible here. This gives us the second rule:
C2: The intersection of an input-ready formula and a non-input ready formula results in a non-input ready cell.This does not
depend on the formula precedence settings for the input-ready formula or the formula from the other structure.The system
therefore does not use any inverse formulas for these intersections.
No exception cells were used in the cases shown above. We now want to describe what happens if exception
cells cij are used in the formula F = F(c1j, …, ckj), with the meaning of the variables as follows:
i = 1, …, k are the indexes of the operands for input-ready formula F that is in row structure Y.
j is the index of a structure element in column structure X.
C3:If F is an input-ready formula in key figure structure Y, and Yi is an operand of formula F in structure Y, exception cells can
be defined for the intersections Yi/Xj of Yi and Xj according to the following rules, so that the input-ready formulas cannot be
reset:
1. If Yi is not input ready, exception cell cij can have one of the following types: non-input ready selection, non-input ready
formula
2. If Yi is an input-ready formula (or nested input-ready formulas), rule 1 (above) is applied to the operands of Yi. This is
possible because the operands of Yi are also contained in key figure structure Y (see rule FG3).
With regard to rule FG3 there is another case:
C 4 If there is no input-ready formula in the key figure structure, an input-ready formula F can only be defined in an exception
call.All operands in the formula must be exception cells. For formula F and its operands, rules FG 1, FG 2 and FG 3 apply if the
following replacements are made:
1. Basic or restricted key figure is to be replaced by an exception cell or cell reference of type Selection
2. Non-input ready formula is to be replaced by exception cell or cell reference of type (non-input ready) formula
Comments
● The settings made for input-ready formulas in the query definition can be overwritten by other settings at
runtime. Input-readiness at runtime is inherited from the operands of the formula group carrier. If all
operands in an input ready formula are not input ready for example, this means that the formula cannot be
input ready either.
● A formula as carrier of a formula group does not have its own disaggregation setting. If values for input-
ready formulas are changed, the system always calculates back the underlying basic or restricted key
Planning Concepts
figures. Note that the latter might actually have disaggregation settings.. The disaggregation behaviour of
input-ready key figures is therefore implicitly defined by the basic key figures in the formula definition.
 Recommendation
You are advised to avoid using nested formula groups if possible, as the end user will probably find it
difficult to understand the calculation order.
 Caution
Note that the system rounds up values at runtime when calculating input-ready and inverse formulas.
The display settings do not affect this. This is always performed in accordance with the maximum
precision specified by the relevant fields on the database.
Special Formula Group for Percentage Functions %GT, %XT, %YT
Percentage function %GT (percentage of grand total) is a special formula group that no inverse formulas have
to be defined for. If formula %GT(op) is used, operand op must be input ready, and either a basic or restricted
key figure with disaggregation activated. Input-ready formulas containing percentage function %GT must not
be nested with one another.
The same rules apply for the percentage functions %XT (Scale to Result Along the Columnsl) and %YT (Scale
to Result Along the Rows). These functions calculate the percentage of the operand, taking into account the
next higher subtotal on the X (column) axis or on the Y (row) axis.
 Example
Let us assume that a company sells two products (product 1 and product 2) to two customers (customer A
and customer B):
Sales
Total Sales for All Products
Product 1 Product 2 per Customer
Customer A 20 40 60
Customer B 80 40 120
Total Sales for All Custom 100 80 180

ers per Product
● The value 20 corresponds to a share of 33.3 % of the total for sales of all products for customer A (60).
This is calculated by formula %XT (along the columns).
● The value 20 corresponds to a share of 20 % of the total for sales of all customers for product 1 (100).
This is calculated by formula %YT (along the rows).
 Caution
If a SAP BW∕4HANA hierarchy is used on the X axis, formula %XT calculates the percentage of the operand
on the root node of the hierarchy and does not take into account the next parent node in the hiearchy. The
same applies if a hierarchy is on the Y axis, and formula %YT is used.
Calculation Mode and Formula Priority
Planning Concepts
 Note
The calculation mode defines how the system should go about calculating inverse formulas. You can set the
calculation mode in the query properties in the General tab under Planning.
You have the following options:
Calculating inverse formulas Description
Flag not set Initial calculation mode: This is the default setting. At query
runtime, the system calculates inverse formulas if at least
one value in an input-ready formula has been fixed or
changed manually.
Flag is set Symmetrical calculation mode: At query runtime, the sys

tem calculates inverse formulas if at least one element in an
input-ready formula has been fixed or changed manually.
Depending on the calculation mode selected, you can set the formula priority for all inverse formulas in an
input-ready formula as follows:
Calculation mode Description
Initial calculation mode Under the input-ready formula, you can find all inverse for
mulas that have been created for the input-ready operands
in the carrier formula. The order of the inverse formulas in
this list determines the formula priority. The uppermost ele
ment has the highest priority.
Symmetrical calculation mode: Under the input-ready formula, you can find all inverse for
mulas that have been created for the input-ready operands
in the carrier formula, and the carrier formula itself. The or
der of the inverse formulas in this list determines the for
mula priority. The uppermost element has the highest prior
ity. Unlike in initial calculation mode, where the carrier for
mula always has the highest priority, this means that the car
rier formula can have any priority, even the lowest.
If the system calculates a formula group at runtime, and neither manual entries nor fixed cells nor previous
calculations clearly indicate the order in which the inverse formulas should be calculated, the system first
calculates the inverse formula with the highest priority.
Note for Calculation
The Note for Calculation is a property of the formula group. If you use the same operands in various input-ready
formulas, the order in which the formula groups are supposed to be processed might not be obvious. You can
avoid this problem by setting the priority for the formula group by entering integers in the Note for Calculation
field. The lower the value entered here, the higher the formula group's priority. The same value can be entered
for multiple formula groups. The values entered for various priorities do not necessarily have to be consecutive
numbers.
Planning Concepts
The Note for Calculation should be understood as a relative setting rather than an absolute one. How this
setting defines the order in which the formula groups are processed also depends on the context, for example
on the changed, fixed or calculated cell values. Normally, it is not necessary to set the priority of the formula
group in the Note for Calculation.
Related Information

Input-Ready Queries at Runtime [page 118]
Inverse Formulas at Runtime [page 138]
The following links take you to the documentation for the input-ready query concept.
1.9.4.1 Examples: Inverse Formula
Use
This document contains a few simple examples to show how the system calculates values in accordance with
the inverse formulas defines for an input-ready formula in the query definition.
 Note
To see the description using a mathematical notation, together with the various rules, see Defining Inverse
Formulas [page 130]. More information: SAP Note 1236347
Example 1: Average Price
The first example scenario is as follows: You want to plan with the following key figures: Quantity, Sales und
Average Price. Key figure Average Price is calculated as follows:
‘Average price’= NDIV0(‘Sales’/ ‘Quantity’)
 Note
Data function NDIV0 is used here to avoid division by 0 errors.
As the key figure Average Price is a calculated key figure and should be input-ready, the system needs rules that
describe how a change to the value of the average price is calculated back to either quantity or sales. These
rules are defined using inverse formulas. The system needs an inverse formula for every operand in input-ready
formula Average Price.
Planning Concepts
Let both operands, Quantity and Sales, be input-ready key figures. If this is the case, you need to define the
following inverse formulas:
‘Sales’= ‘Average price’* ‘Sales Quantity’
and
‘Quanity’= NDIV0(‘Sales’/ ‘Average Price’)
 Note
If only the value for the average price is changed, it is not clear at first whether the system should calculate
back to Quantity or Sales. The system will then take the inverse formula with the highest priority. The
priority of the formulas is determined by the alignment of the inverse formulas in the formula group: The
formula with the highest priority occupies the uppermost place in the list of inverse formulas.
Example 2: Percentage
The second example scenario is as follows: You want to plan with the following key figures: Amount and
Percentage pf the amount with regard to the total. The percentage should also be input-ready.
As with example one, this case can also be modeled with an input ready formula and the definition of an inverse
formula. You can also use the ‘%GT’ function (percentage of grand total) with a number of additional functions:
● If you use the %GT function, you do not need to create an inverse formula, as it is already defined in the
system.
● The total for the operand of %GT is fixed automatically during calculation of the inverse formula. This
ensures that the changed % value is still the same after the server roundtrip.
● The %GT function is useful if the underlying basic key figure uses one of the supported disaggregation
settings. For more information about disaggregation settings, see Input-Ready Query [page 117].
Define the following formula:
‘% Percentage’= %GT ‘Amount’
Choose Input-Ready. You do not need to create an inverse formula.
Example 3: Symmetrical Calculation Mode and Average Price
Formulas are always calculated when the OLAP Processor calculates a new result.
If the value of an input-ready formula is changed, the value of the calculated key figure Average Price for
example, the system has to calculate the inverse formula. In this case, the system calculates either the formula
for Sales or the format for Quantity.
If the value of an operand in an input-ready formula is changed however, key figure Sales for example, the
system does not calculated inverse formulas. The system calculates a new average price when the result is
updated by the OLAP Processor.
In some cases, a different behaviour is required: If the value of an operand such as key figure Sales is changed,
the value for the Average price should be retained, and the change to key figure Quantity calculated back. You
can achieve this using symmetrical calculation mode.
Planning Concepts
 Note
To activate the symmettrical calculation mode, select the General tab during query definition and select the
Symmetrical Calculation Mode under Planning.
This mode is particularly useful for depicting the required business logic in complex scenarios that work with a
large number of nested input-ready formulas. In this kind of scenario, it can be useful to be able to explicitly set
the order that the formula groups will be calculated in. The Note for Calcualtion is used for this purpose.
 Note
Once you have activated symmetrical calculation mode, you can set the formula priority for every input-
ready operand, including the input-ready formulas that use them. You do this in the query component
properties. In the Note for Calculation field, you can also define the formula group’s priority in relation to
other formula groups.
1.9.5 Inverse Formulas at Runtime
Use
This chapter provides information about runtime aspects of inverse formulas. We assume that you can create
input-ready and inverse formulas in the query definition.
 Note
You can find examples showing runtime aspects of inverse formulas under Examples: Inverse Formulas at
Runtime [page 142] and in SAP Note 1236347 .
Input-Readiness of Formulas
Formulas inherit their input-readiness from their operands. If you have defined an input-ready formula F =
F(op1, …, opn) in the query definition, the system checks whether at least one operand is input ready at
runtime. If this is not the case, formula F is not input ready either. If an operand opi = G is also an input-ready
formula, the same rule applies.
As with input-ready structural elements, the input-readiness of formulas requires that specific characteristics
are uniquely defined: If an input-ready formula or an operand of this type of formula uses exception
aggregation, all the reference characteristics must be uniquely defined for exception aggregation on cell level,
in order to make the formula input-ready. This also applies for values of master data attributes in input-ready
formulas (formula variables of type Replacement Path, whose variable has been replaced by the attribute value
of a characteristic).
Sequence of Calculations
Calculating inverse formulas can be seen as a kind of "inverted" reporting. As the planning uses input-ready
queries for manual planning, the system calculates the reporting formulas for the result set that is sent to the
front end. In ABAP Dynpro terminology, reporting formulas are therefore calculated in PBO (process before
output). After data has been changed manually in input-ready cells in the query, a server roundtrip is triggered,
known as a PAI (process after input). Inverse formulas are calculated at this point. Changes in input-ready
Planning Concepts
formulas are returned to the basic key figures, while observing any disaggregation settings that have been
made. This creates new delta records that are stored in the delta buffer. In the next, the OLAP processor reads
the delta records in order to refresh its internal status and the result set. The reporting formulas are calculated
again during this process.
For the inverse formulas, this means that there must be inversion of these input-ready formulas in the
mathematical sense. Otherwise, a change in an input-ready formula would be overwritten in the next PBO after
a completed PAI-PBO cycle.
The next section describes the general rules in the implemented computational model.
General Rules
The following section explains the general rules for the implemented initial calculation model and the
symmetrical calculation model, which can be selected as an enhanced calculation mode in the query definition.
Depending on which calculation mode is selected in the query definition, the system triggers calculation of
inverse formulas either when input-ready formulas are changed/fixed, and other operands of input-ready
formulas have been changed (initial - or asymmetrical calculation -mode), or if an element in a formula group
has been manually changed or fixed (symmetrical calculation mode).
Let F = F(op1,..., opn) be an input-ready formula, and op1,..., opk with k < n be input-ready operands. In the
query definition, k inverse formulas have been created in order to calculate operands op1,..., opn:
Fi = Fi(F, op1,…, opi-1, opi+1, … , opk, … , opn) for i = 1,…, k
If F has been changed, for example, the system needs to find the 'best'inverse formula Fi for its calculation. The
result of Fi is passed onto opi. The new value of opi can then trigger other calculations or a disaggregation.
The system uses the following rules for formula inversion.
1. Formula inversions are made based on data records. The values of the characteristics in the drilldown
determine the data record here. Inverse formulas are calculated for each data record for the structural
components defined in the query definition. These calculations are not affected by other data records.
2. If there are nested formula groups, input-ready formulas can be calculated back to input-ready basic or
restricted key figures by inversion of other input-ready formulas. These changes trigger a disaggregation,
provided that key figures use one of the disaggregation settings.
3. In a server roundtrip, just one inverse formula is calculated per formula group. After a calculation, all
elements of this formula group are temporarily fixed, meaning that the elements of a formula group that
has already been calculated cannot be overwritten by calculations from other formula groups during this
roundtrip.
4. To find the inverse formula that needs to be calculated, the system first gathers the elements that trigger
calculations. These are changed or fixed cell values of input-ready formulas or elements in a formula group
(for each data record). The calculation is triggered by different elements, depending on the calculation
mode selected (asymmetrical or symmetrical). If an operand in the formula group was calculated in a
previous step, this operand is also treated as fixed for the new calculation, meaning that it is considered a
known source. Possible targets for calculation are input-ready operands in the current formula group,
which are not changed, fixed or calculated. If one of the inverse formulas cannot clearly be recognized as
requiring calculation, the system takes the inverse formula with the highest formula priority defined in the
query definition.
5. Multiple formula groups can participate in the calculations triggered by manual changes or fixed cell
values. As the formula priority definition relates to all elements in a particular formula group, it is not
possible to tell which formula group is to be calculated first. The system calculates the formula groups in
Planning Concepts
ascending order following the number of "degrees of freedom". The current degree of freedom is worked
out by taking the number of operands and subtracting the number of operands already recognized. These
are operands that are constants, fixed, manually changed or were calculated in a previous step. If the
current degree of freedom of the formula group is the same, the system checks whether the symmetrical
calculation mode is used. If this is the case, the system analyzes the Note for Calculation to clarify the
formula priority. In all other cases, the order in which the formula groups are processed remains undefined.
6. With regard to formula inversion, new rows are treated like existing ones. If the row already exists, changed
or recalculated vales are aggregated by basic key figures.
 Note
The system does not try to find any old solution for the computational problem resulting from manual
changes and other types of Customizing being performed on input-ready queries. The system finds a
solution using the rules listed above. If this is not successful, the system informs you with an error
message.
Error Handling
If the system does not find any inverse formulas for calculation, it means that the entries made by the user are
invalid. The system generates messages providing information about the cause of the problem, such as too
many manual changes or too many restrictions from fixed values.
There are cases where all formula inversions are possible, but the subsequent disaggregation of the values is
not. This can be the case if all individual values in a subtotal, total or a hierarchy node and the subtotal, total or
hierarchy node itself have been changed or calculated. The system generates messages accordingly.
Rounding Rules
Key figure values are saved in the database with a limited number of decimal places. When formulas are
calculated, rounding normally takes place. Inverse formulas can be used to calculate key figures that are stored
on the database. For key figures like this, every calculated key figure value or key figure value created by
disaggregation is therefore rounded to the database decimals. If the system calculates aggregated values using
inverse formulas and disaggregates the calculated values, serious rounding errors can occur. It is therefore
important to realize that a manually changed value can deviate from the value entered after the formula
inversion has been calculated and the result set updated. This also applies for fixed values.
 Recommendation
We therefore recommend using the same number of database decimal places for all operands of inverse
formulas.
Recommendations
We recommend using nested input-ready formulas. As far as possible, model input-ready formulas and formula
inversions in such a way that there are not too many variants for possible calculations. The calculations made
at runtime are then easier to understand.
To avoid formal division errors like divisions by zero for quotients as input-ready formulas, such as Average
Price, use operator NDIV0. If no data has been planned yet for example, and the Master Data for Characteristic
Relationships setting is used for a number of characteristics under Access Type for Result Values, a large
number of empty data cells normally result. If you do not use data function NDIV0 here, the cells will not be
input ready for Average Price. If you do use NDIV0, however, you will get the calculation NDIV0( 0 / 0 ) = 0 for
these types of cells, and Average Price can be changed.
Planning Concepts
Related Information
Input-Ready Queries at Runtime [page 118]
Defining Inverse Formulas [page 130]
The following links take you to the documentation for the input-ready query concept.
1.9.5.1 Percentage Functions at Runtime
Percentage Function %GT (Percentage of Grand Total)
General Rules for Percentage Function %GT at Runtime
At runtime, an input-ready formula with percentage function %GT(op), Percentage of Grand Total, can only
really be input ready if the op Operand is input ready at runtime.
 Note
For more information about general rules on how the "non-input ready" characteristic is inherited for
subtotals, totals and hierarchy nodes, see SAP Note 994853 .
 Example
For a detailed explanation of the rules, see the discussion of example 6, Percentage of Grand Total in
Examples: Inverse Formulas at Runtime [page 142].
Calculating the %GT Percentage Function in New Rows
The system also calculates inverse formulas in new rows. This results in changed values in the basic key
figures: If rows already existed before, the system adds the changed values to the existing ones. There are no
special checks for new rows.
Percentage functions %XT (Scale to Result Along the Columns) and %YT (Scale
to Result Along the Rows).
General Rules for Percentage Functions %XT and %YT at Runtime
Functions %XT and %YT can be used in the same clients as %GT. %XT(op), %YT(op) are only input ready if the
operand op is input ready.
Functions %XT and %YT calculate the percentage based on the next total level on the X or Y axis.
Planning Concepts
 Note
If a SAP BW∕4HANA hierarchy is used on the X or Y axis, the formula calculates the percentage of the
operand on the root node of the hierarchy and does not take into account the next parent node in the
hiearchy.
In the following cases, the system revokes the input-readiness of percentage functions %XT and %YT:
● A hierarchy is used in the affected axis, i.e. function %XT is used at the same time as a hierarchy on the X
axis, function %YT is used at the same time as a hierarchy on the Y axis.
● Subtotals are suppressed in the result set of queries that are however required for calculation of the
percentage functions.
If the value in cell %XT(op) is changed, the system takes over the changed percentage and calculates the new
value of op based on the next total level value of op on the X axis. The system also fixes the value of the subtotal
in order to ensure that the changed percentage is retained after a server roundtrip. The system also performs
the calculations for changed %YT values accordingly.
Calculating Percentage Functions %XT and %YT in New Rows
In new rows, functions %XT and %YT are not input ready. Whether or not the corresponding cells can be
displayed as non input-ready depends on the client.
1.9.5.2 Examples: Inverse Formulas at Runtime
Use
This chapter contains a number of examples that provide information about runtime aspects of inverse
formulas.
Example 1: Average Price
As in the documentation for defining inverse formulas, we will begin with the Average Price example. We
assume that Sales (Sales) and Sales Quantity (Sales Quantity) are restricted key figures (with the currency
restricted to a value and an initial unit of measure for Sales and the opposite for Sales Quantity). Both restricted
key figures use the Disaggregate Value Entered setting under Planning on Totals.
A data slice protects the products Comes after C++ and MMIX by D.E.. Knuth.
As shown in the graphic below, the Tools (Tools) totals row is not input ready, either for restricted key figures
Sales and Sales Quantity or for (input-ready) formula Average Price. The Average Price formula is not input
ready here, as all operands of this formula are non-input ready.
Planning Concepts
Example query: average price
Example 2: Formula inversion triggered by manual changes
We illustrate the general rules using the example of the calculated input-ready key figure Average Price (see
Example 1 above).
We assume that the initial (asymmetrical) calculation mode is used.
Here, Average Price is the carrier of the formula group that contains the following elements: Average Price,
Sales and Quantity. In the query definition, the following inverse formulas have been defined:
1. ‘Sales’= ‘Average price’* ‘Sales Quantity’

2. ‘Quanity’= NDIV0(‘Sales’/ ‘Average Price’)
● We assume that the value for Average Price has been changed. Both inverse formulas can be used for the
formula inversion. The system takes the formula with the highest formula priority, in this case the Sales
formula.
● We assume that the values for Average Price and Sales have been changed. In this case, it is clear that the
system has to calculate the Sales Quantity formula.
● We assume that the value for Average Price has been changed and that the Sales cell has been fixed. In this
case, it is clear that the system has to calculate the Sales Quantity formula.
Planning Concepts
● We assume that the value for Average Price has been changed and that the Sales cell is not input ready, for
example because this key figure is protected by a data slice. In this case, it is clear that the system has to
calculate the Sales Quantity formula.
● We assume that the values for Sales or Sales Quantity have been changed. In this case, inverse formulas do
not come into play. The system calculates the Average Price.
● We assume that the value for Sales has been changed and that the Average Price cell has been fixed. In this
case, it is clear that the system has to calculate the Sales formula.
We assume that the symmetrical calculation mode is used.
Here, Average Price is the carrier of the formula group that contains the following elements: Average Price,
Sales and Quantity. In the query definition, the following inverse formulas have been defined, and the carrier
formula has the lowest priority:
1. ‘Sales’= ‘Average price’* ‘Sales Quantity’

2. ‘Quanity’= NDIV0(‘Sales’/ ‘Average Price’)
3. 'Average price' (carrier formula)
● We assume that the value for Average Price has been changed. Both inverse formulas can be used for the
formula inversion. The system takes the formula with the highest formula priority, in this case the Sales
formula.
● We assume that the values for Average Price and Sales have been changed. In this case, it is clear that the
system has to calculate the Sales Quantity formula.
● We assume that the value for Average Price has been changed and that the Sales cell is not input ready, for
example because this key figure is protected by a data slice. In this case, it is clear that the system has to
calculate the Sales Quantity formula.
● We assume that the values for Sales have been changed. This triggers calculation of the formula group.
Because Quantity has higher priority, Average Price is kept, and an inverse calculation is performed on
Quantity.
● We assume that the values for Quantity have been changed. This triggers calculation of the formula
group. Because Sales has the highest priority, Average Price is kept, and an inverse calculation is
performed on Sales.
● We assume that the value for Sales has been changed and that the Average Price cell has been fixed. In this
case, it is clear that the system has to calculate the Sales formula.
Example 3: Overlapping formula groups
In this example, we use three restricted key figures Sales Plan, Sales Forecast and Sales Actual. We also want to
plan the percentage deviation of planned sales from forecast sales and planned sales from actual sales. We
therefore create two input-ready formulas and the corresponding inverse formulas.
The input-ready formula for calculating the percentage deviation of planned from actual sales is as follows:
%Dev (P,A) = NDIV0( 'Sales Plan'% 'Sales Actual')
The elements of this formula group are '%Dev(P,A)', Sales Plan and Sales Actual.
The input-ready formula for calculating the percentage deviation of planned from forecast sales is as follows:
%Dev (P,A) = NDIV0( 'Sales Plan'% 'Sales Forecast )
Planning Concepts
The elements of this formula group are '%Dev(P,F)', Sales Plan and Sales Forecast.
Both formula groups contain the element Sales Plan. We assume that Sales Actual and Sales Forecast are not
input ready, for example because the forecast was prepared by the planning administrator. In this case, the
following elements are input ready: Sales Plan, '%Dev(P,A)' and '%Dev(P,F)'. The system only requires
inversions from '%Dev(P,A)'to Sales Plan and from '%Dev(P,F)'to Sales Plan.
Product %Dev (P,F) %Dev (P,A) Sales Plan Sales Forecast Sales Actual
PC Medium 0 10 -> 20 110 110 100
PC Small 0 -> 10 10 220 220 200
PC High End 0 -> 10 10 -> 20 330 Error 330 300
Total 0 10 660 660 600
Manual entries are represented by an arrow '->'. To provide greater transparency, this table contains all of the
three examples that will be explained below. However, this does not mean that the changes were made in a
single interaction step.
1. If you change '%Dev(P,A)'for 'PC Medium', the system first calculates the Sales Plan in the PAI (process
after input) and then calculates the percentage deviation '%Dev(P,F)'in the PBO (process before output).
2. If you change '%Dev(P,F)'for 'PC Small', the system first calculates the Sales Plan in the PAI and then
calculates the percentage deviation '%Dev(P,A)'in the PBO.
3. If you change '%Dev(P,A)'and '%Dev(P,F)'in a single step for 'PC High End', the system attempts to
calculate 'Sales Plan'. This is possible for one formula group. For the other formula group, however, the
system also attempts to reconcile Sales Plan at the same time. This produces an error, as the other key
figures are not input ready and therefore cannot be changed by calculating inverse formulas.
Apart from if you get the error described under 3, you will get the following result:
Product %Dev (P,F) %Dev (P,A) Sales Plan Sales Forecast Sales Actual
PC Medium 9.09 20 120 110 100
PC Small 21.00 10 242 220 200
PC High End 0.00 10 330 330 300
Total 4.84 15.34 692 660 600
Example 4: Formula groups that are nested with each other
In this example, we want to plan costs for a number of cost centers. We assume that we have two key figures:
Fixed Costs and Variable Costs. Fixed Costs is not input ready, as we assume that we cannot influence these
costs in this example. Variable Costs are planned. The total costs are the fixed costs plus the variable costs. We
already have the total costs from the previous year in a restricted key figure Costs LY. The fixed and variable
Planning Concepts
costs in this do not interest us. What we would like to do, however, is to plan the percentage deviation of the
total costs from the total costs in the previous year. To do this, we can form two input-ready formulas:
'Total Costs = 'Variable Costs + 'Fixed Costs'
The elements of this formula group are Total Costs, Variable Costs and Fixed Costs.
The other input-ready formula is:
'%Dev(T, LY) = 'Total Costs'% 'Costs LY'
The elements of this formula group are '%Dev(T,LY)', Total Costs and Costs LY.
The two formula groups are nested with each other, as the Total Costs formula is also used in the '%Dev(T,LY)'
formula.
Cost center %Dev (T,LY) Total Costs Variable Costs Fixed Costs Costs LY
4711 10 110 -> 120 100 10 100
4712 10 -> 20 220 200 20 200
4713 10 -> 20 330 -> 400 300 Error 30 300
Total 10 660 600 60 600
Manual entries are represented by an arrow '->'. To provide greater transparency, this table contains all of the
three examples that will be explained below. However, this does not mean that the changes were made in a
single interaction step.
1. If you change the Total Costs for cost center 4711, the system first calculates the Variable Costs in the PAI
and then calculates back to the Total Costs and the percentage deviation with the previous year
'%Dev(T,LY)' in the PBO.
2. If you change the percentage deviation with the previous year '%Dev(T,LY)' for cost center 4712, the
system first calculates the Total Costs in the PAI, as the formula is input ready. This implicit change triggers
the next formula inversion. In the result, the system also calculates the Variable Costs in the PAI. In the
PBO, the system then calculates back to the Total Costs and the percentage deviation with the previous
year '%Dev(T,LY)'.
3. If you change the percentage deviation with the previous year '%Dev(T,LY)' and the Total Costs for cost
center 4713 in a single step, the only input-ready operand of formula '%Dev(T,LY)' will change too at the
same time. This means that formula inversion is not possible for the percentage deviation with the previous
year '%Dev(T,LY)'. The system displays error messages informing you of this.
Apart from if you get the error described under 3, you will get the following result:
4711 20 120 110 10 100
4712 20 240 220 20 200
Planning Concepts
4713 10 330 300 30 300
Total 15 690 630 60 600
Example 5: Calculating inverse formulas and disaggregation
In this section, we will look at an even more complex example, where we change multiple values at various
levels of the result set in a single step. We assume that the formulas has the highest priority.
‘Quanity’= NDIV0(‘Sales’/ ‘Average Price’)
As shown by the arrows ' -> ' in the table below, certain numbers on various summation levels were changed in
a single step. Note that the system calculates the inverse formula for all levels first and then disaggregates
changed or calculated values to the basic key figures.
Product Sales Quantity Average Price
PC Medium 4000.00 3 1333.33 -> 800
PC Small 4000.00 4 -> 3 1000.00 -> 500
PC High End 4000.00 3 1333.33
Total 12000.00 10 1200.00 -> 1000
These changes trigger the following calculations:
PC Medium 4000.00 (temporarily fixed) 4000.00 / 800 (priority) 1333.33 -> 800
PC Small 3 * 500 4 -> 3 1000.00 -> 500
PC High End 4000.00 3 1333.33
Total 12000.00 (temporarily fixed) 12000.00 / 1000 (priority) 1200.00 -> 1000
The intermediate result is as follows:
PC Medium 4000.00 (temporarily fixed) 5 (calculated) 800 (changed)
PC Small 1500 (calculated) 3 (changed) 500 (changed)
PC High End 4000.00 3 1333.33
Planning Concepts
Total 12000.00 (temporarily fixed) 12 (calculated) 1000 (changed)
The Sales Quantity column contains a changed Totals value and changes to values on lower levels. The system
therefore starts the disaggregation of 12 – ( 5 + 3 ) = 4 for the one unchanged value of product ‘PC High End’.
As a result of calculations in the various rows, the Sales column contains temporarily fixed values and a
changed value. The system therefore starts the disaggregation of 12000 – ( 4000 + 1500 ) = 6500 for the one
unchanged value of product ‘PC High End’.
The result of the calculation of the inverse formulas and the disaggregation is as follows:
PC Medium 4000.00 5 800.00
PC Small 1500.00 3 500.00
PC High End 6500.00 4 1625.00
Total 12000.00 12 1000.00
Example 6: Percentage %GT
We provide an explanation of the runtime aspects of the percentage %GT example (see Examples: Inverse
Formulas [page 136], Example 2).
We assume that the amount is a basic key figure whose distribution type for disaggregation is Analog
Distribution (Self-Reference).
A data slice protects the products Comes after C++ and MMIX by D.E.. Knuth.
As shown in the graphic below, the total in the Percentage of the Amount with Regard to the Total (%
Contribution) is not input ready, as the corresponding value is always 100%. All other cells are input ready, with
the exception of the values for Comes after C++ and MMIX by D.E. Knuth and the subtotals for these products.
The basic key figure Amount is protected by a data slice. In the result, input-readiness is also deactivated for
Percentage (% Contribution): The “non-input ready” characteristic was inherited by the %GT formula from the
Amount operand. The "non-input ready" property was also inherited from the Tools subtotal, as all children of
this hierarchy node are non-input ready.
Planning Concepts
The value of %GT for the total is always 100%; meaning that the total result is not input ready. The value for
%GT therefore remains at 100% if you use a filter (on the axis) for Personal Computer. Calculations with %GT
are still possible if no subtotals, totals or hierarchy nodes are displayed. It is also possible to hide key figure op -
Amount in our example. Operand op – Amount in our example – must be input ready though.
If both operand op – Amount in our example – and %GT are changed for the same level in a single interaction
step, the system displays an error message. On the other hand, it is possible to change the total for op
(Amount) and the values for %GT at a deeper level. In this case, the system takes the new value for grand total
and the changed %GT value to calculate the new value for operand op (Amount) at the deeper level. These two
changes trigger a disaggregation for operand op - Amount..
The grand total for Amount must not be zero. If it is, %GT cells are not input ready.
Values for %GT can also be outside the range 0 to 100, which generally produces negative values for the
operand - Amount after disaggregation.
Planning Concepts
1.9.6 Master Data Planning
You can use an InfoObject (characteristic) with a master data table as a basic InfoProvider for master data
planning by exposing all attributes and texts of this InfoObject as well as plannable key figures.
Prerequisites
● InfoObject (characteristic):
As a basic InfoProvider suitable for master data planning, you have created an InfoObject (characteristic)
with a master data table using SAP BW∕4HANA and without the property Enhanced Master Data Update.
To enable master data planning, you have assigned modeling properties Usable as InfoProvider and
Planning Mode to this InfoObject (characteristic), and switched from Load Mode to Planning Mode.
● Aggregation Level:
You have created an aggregation level on this basic InfoProvider. The system has created key figures as
metadata for attributes and texts of the InfoProvider.
● Query:
You have created input-ready queries on the aggregation level.
 Note
All key characteristics, attributes, and texts that are to be plannable must be ready for input. To do this,
in the properties of the structure element on the Planning tab, set the value in the field Input-Ready to
Yes.
You have the option of choosing Copy Dissagregation, homogenous values as the disaggregation
behavior.
Special Features when Planning on Master Data
If you start the query in change mode, you can change master data. All attributes and texts of the InfoObject
that are included in the aggregation level can be used as key figures in the query.
If there are time-dependent attributes and texts, you can also include the following key figures in the
aggregation level and use them in the query:
● Attributes: 1KYF_1DATEFROM, 1KYF_1DATETO

● Texts: 1KYF_1TXTDATEFROM, 1KYF_1TXTDATETO
These key figures can be input-ready or not, depending on whether these fields are to be changeable or not. If
they are to be changeable, the new limits of the time interval must lie within the time interval containing the
query key date. In addition, the lower limit of the time interval must be under (or equal to) the query key date,
and the upper limit must be above (or equal to) the query key date. The query key date itself can be fixed or
variable. The following therefore applies:
● Attributes: DATEFROM(old) < DATEFROM(new) <= KEY_DATE(query key date) <= DATETO(new) <
DATETO(old)
Planning Concepts
● Texts: <sap-technical-name>DATEFROM</sap-technical-name>(old) < TXTDATEFROM(new) <=
KEY_DATE(query key date) <= <sap-technical-name>DATETO</sap-technical-name>(new) <
TXTDATETO(old)
New lines: An InfoObject value in a new line is a new master data value. If the DATEFROM and DATETO fields are
not used as key figures in the query, or are not input-enabled, the system sets the following values:
● *DATEFROM = 01.01.1000
● *DATEFTO = 31.12.9999
 Note
Saving the master data changes: Note that all changes to the master data, attributes and texts are added
to a single request.
Lock concept: Only the key characteristics are relevant for locks. Attributes are not relevant for locks.
Related Information

1.10 Saving Changed Values
If you save your data in a planning application, the system persists the data changed since the last save on the
database. You can check the data before saving with a planning sequence. To log saved values, implement
interface IF_RSPLS_LOGGING_ON_SAVE.
Use
If you save your data in a planning application, the system persists the data changed since the last save on the
database. The changes to the data are always posted (and not the absolute values).
Checking Data Before Saving with a Planning Sequence
To prevent users in a planning application from saving invalid changed data, you can specify that a specific
planning sequence runs after every "Save" event for an InfoProvider, thus checking the data in this InfoProvider.
Logging Saved Values
Using BAdI BADI_RSPLS_LOGGING_ON_SAVE from enhancement spot RSPLS_LOGGING_ON_SAVE, you can

log the data that is saved for a planning application. This logging can be implemented for base InfoProviders
that are suitable for planning.
Planning Concepts
The BAdI is filter-dependent. Create an implementation of interface IF_RSPLS_LOGGING_ON_SAVE for every
suitable base InfoProvider that you want to log.
The BAdI is called if data is saved for an application for planning in a suitable base InfoProvider. The BAdI is not
called if the InfoProvider is described differently, for example, in loading mode using Data Warehouse
Management. This has no effect on the existing logging operations, as long as the data of the InfoProvider is
partially or completed deleted.
Using Methods
● Methods log_defined and log_structure are used to specify whether or in which format the data is
provided. In method log_structure, you can specify that context information about the name of the writing
user, the date, the time and the SAVE ID are displayed using special InfoObjects in the DDIC structure.
Using the SAVE-ID, you can identify a 'save' action in a planning application.
 Example
If a user saves data three times in a planning application and describes two base InfoProviders while
logging is active for both base InfoProviders for example, the system therefore creates the three SAVE-
IDs. These IDs can be passed to both logging calls of the two base InfoProviders, if required. You can
therefore identify in the logs of the two base InfoProviders, which data from base InfoProvider1 was
saved together with which data from base InfoProvider2.
● Method log_write calls the actual logging for every 'Save'event in the application that transfers the data in
the structure specified for log_structure. The actual logging is implemented in method log_write. In other
words, the data is written to a transparent table. Besides the data, the request ID of the suitable
InfoProvider (where the data is saved) is also passed to method log_write.
● Using method log_defined_db, you activate logging on the SAP HANA database for an InfoProvider that
you have classified for logging using method log_defined. Once you have done this, method log_write is not
called any more for the InfoProvider in question. Method log_write_db is called instead.
● Method log_write_db provides you with the name of a database table containing structure
i_structure_name and the data to be logged. Whereas method log_write is an internal table, this method is
a database table. It is not known in the DDIC and therefore has to be processed using database tools
(ADBC API or EXEC SQL, in other words Native SQL). You can persist the log information to your storage
location by transforming the content of the database table in question to a storage location of your
choosing.
 Note
The methods in this interface are described in detail in the interface documentation (see Class Builder,
transaction SE24).
 Note
The methods of interface IF_RSPLS_LOGGING_ON_SAVE are described in detail in the interface

documentation (see Class Builder, transaction SE24).
For more information, see SAP Note 1802658 .
Planning Concepts
Related Information
Checking Data Before Saving with a Planning Sequence

For more information about the relevant procedure in the BW Modeling tools, see Central Settings.
Logging Saved Values Without SAP HANA Database
You can use statistics events 50098 and 50099 to measure the processing times.
1.11 Audit
Using the data audit, you can track changes made to transaction data on input-ready query level (for example,
if data was changed in the query and who made the changes). The user can view the audit information for every
cell of the query. This information is provided as delta values of the change history in a corresponding audit
query.
Supported InfoProviders
You can use the data audit for the following InfoProviders:
● Data Mart DataStore Object: In this type of InfoProvider, the data audit is a fixed component and is always
active.
● Local provider in BW workspace (activated for planning): Audit characteristics are also added to this local
provider.
 Note
The audit characteristics should only be used for the audit function. In other words, these characteristics
should not be added to InfoProviders that do not support audits.
Using Audit Characteristics in Providers
Data Mart DataStore Object

The prerequisite for this is that the Show Audit Characteristics in Query property is set in a CompositeProvider
containing the DataStore object.
The audit infrastructure is a fixed component in the DataStore object. The audit information is updated via the
request and can be included in queries via the navigation attributes.
The following InfoObjects are used:
● Time Stamp: 0REQTSN

● User: Navigation Attribute 0REQTSN__0AUSER
Planning Concepts
● Data source: Navigation Attribute 0REQTSN__ 0ASOURCE
Local Provider in BW Workspace

If data is written to a local provider using an input-ready query or planning function, the system fills the audit
characteristics as follows:
● Data audit active:

○ 0ATIMESTAMP = time stamp of the save event
○ 0AUSER = SY-UNAME
○ 0AMODE = PLAN
○ 0ASOURCE = name of query or planning function (if unique)
● Data audit inactive:
○ 0ATIMESTAMP = fixed time stamp (time when mode switched from active to inactive)
○ 0AUSER is empty
○ 0AMODE = OFF
○ 0ASOURCE is empty
 Caution
Note that local objects, and all objects that reference a local provider, cannot be transported.
Related Information
Audit Characteristics [page 154]

Audit Query [page 155]
1.11.1 Audit Characteristics
The system uses specific characteristics to save audit information.
The audit characteristics are supplied with technical content from SAP BW∕4HANA. These characteristics are
filled by the system and cannot be modeled by users.
The following table provides an overview of the audit characteristics and their values.
Audit Characteristics
Characteristic Values and Description
0ATIMSTMP This characteristic contains the audit time stamp.
● If the database audit is active, this characteristic contains a time stamp,

which indicates when the data was saved on the database.
● If the database audit is inactive, this characteristic contains a fixed time
stamp, which indicates when the data audit was switched from active to in
active.
Planning Concepts
Characteristic Values and Description
0AMODE This characteristic contains the audit modus. The following values are permitted:
● WHM: This value is used in loading mode (in other words, when data is
added to the InfoProvider by loading requests).
● PLAN: This value is used in planning mode (in other words, when data is
taken from planning).
● OFF: This value is used if the data audit is set to inactive.
0AUSER This characteristic contain the name of the user who initiated the save event.
● If the data audit is active, this characteristic contains the content of the
ABAP system field SY-UNAME.
● If the data audit is inactive, this characteristic is empty.
0ASOURCE This characteristic contains the name of the source of the data change at the
time of saving.
● When the data audit is active and the data is taken from planning (planning
mode), this characteristic contains the name of the query or the planning
function, provided that these names are unique.
 Note
If this field contains the name of a standard query, generated by the
system, and this name begins with "!", this character is replaced by "$".
● In all other cases, this characteristic is empty.
Related Information
Audit [page 153]
1.11.2 Audit Query
The following example shows how to define an input-ready query and the corresponding audit query. You can
either execute an audit query in a way that allows to you to track the changes, or in a way that allows you to
view the delta values.
Changes in Input-Ready Query ZTSC0AC10_Q_INVFORML_01 (With and

Without Audit)
In the following example, the user has used an input-ready query to write values to a data mart DataStore
object.
Planning Concepts
The following screen shows the executed query:
Then the user made further changes in the input-ready query and then saved the changes immediately. The
following changes were made:
1. Subtotal Hardware, Personal Computer: the value of Sales Quantity was changed from 30 to 60.
2. Subtotal Hardware, Personal Computer: the value of Sales was changed from 15,000 to 20,000.
3. Subtotal Hardware, Personal Computer: the value of Sales Quantity was changed from 60 to 120 and the
value of Sales was changed from 20,000 to 30,000.
Planning Concepts
The following screen shows the executed query after the changes:
Definition of Audit Query ZTSC0H000_Q_AUDIT_00
You usually create the audit query on a CompositeProvider containing all base InfoProviders that are changed
with input-ready queries or planning functions. We recommend that you build the audit query in the same way
as the input-ready query. However, all the characteristics of the audit dimension should be available as free
characteristics.
In our example, the characteristic Request Transaction Sequence Number (0REQTSN) is drilled down in the
rows. The characteristic Product is removed from the rows, which makes it easier to track changes to the
subtotal.
Planning Concepts
The following screen shows the definition of the audit query:
Executing the Audit Query ZTSC0H000_Q_AUDIT_00
When you execute the audit query, you see the following result: Using characteristic 0REQTSN, you can track
which values have been changed by the user of the input-ready query. You need to use property Cumulate
Values for characteristic 0REQTSN in the query definition.
Planning Concepts
The following screen shows the executed query with the changes:
If the audit query is executed without the property Cumulate Values for characteristic 0REQTSN, you can track
the changes (delta values).
Planning Concepts
The following screen shows the executed query with the delta values:
1.12 Lock Concept and Lock Management
Use
If transaction data is requested in change mode, this data has to be locked exclusively for one user. The data
records that need to be locked are described in a selection table. A data record is locked by the selection table
if for each characteristic in the selection table, the characteristic value in the data record lies within the
selection. In this case it is irrelevant whether the data record exists in the database.
● All records in the selection are locked.

● If the selection table is empty, each data record is locked since no restrictions exist.
● For characteristics outside the aggregation level, selection * (all) is always locked.
Planning Concepts
 Example
The selection table is as follows:
Characteristic Characteristic value
Fiscal year 2006
Product P1 - P10
This table describes a selection. All the records in this selection are locked. This includes the following
for example:
Fiscal year Product
2006 P1 Both values are in the selection, so

the record is locked.
2006 P20 P20 is not in the selection, so the re

cord is not locked
2007 P1 2007 is not in the selection, so the

record is not locked
2008 P11 Neither component is in the selec

tion, so the record is not locked
Activities
The selection tables have to be stored and managed centrally for all users and application servers. The SAP
standard lock server cannot manage locks that are based on selection tables. You therefore have to make SAP
BW∕4HANA-specific settings to store locks that are described by selection tables.
You access the SAP BW∕4HANA lock management settings in the SAP Reference IMG (transaction SPRO) or in
lock setting maintenance for planning (transaction RSPLSE). To use Planning, the used lock table needs to be
sized. The sizing depends on the location of the lock table.
More Information
Managing Lock Settings [page 162]
Sizing Lock Tables [page 168]
Planning Concepts
1.12.1 Managing Lock Settings
Use
You need information about lock management so that you can make the right settings.
To call lock management, enter transaction RSPLSE. The Display Planning Lock Settings screen appears.
Prerequisites
Make sure that you have the required authorizations. The authorization object for displaying and changing lock
settings in planning is S_RS_PLENQ.
Features
If you are in change mode, you can make the required changes in change mode on the Lock Table and Lock
Characteristics tab pages.
Tab: Lock Table
Here you specify where the lock table is stored (see Storage of Lock Tables [page 163]).
 Caution
You can only switch from display mode to change mode if no locks are active for any basis InfoProviders in
planning. In other words, no planning application transaction data can be locked for any InfoProviders of
the data basis. This is intended to ensure that locked transaction data remains consistent.
Tab: Lock Characteristics
Here you specify which characteristics are relevant for lock checks (see Selection of Lock Characteristics [page
164]).
 Caution
You can only switch from display mode to change mode if there are no active locks for the selected
InfoProvider. In other words, no transaction data can be locked using a planning application for the
InfoProvider of the data basis.
 Note
The lock characteristics are in table RSPLS_CHAS_LOCK. These settings can be transported by entering the
table entries directly into the transport request.
You can display the relevant information on the Locks,Lock Conflict and Master Locks tab pages.
Tab: Lock
Planning Concepts
Here, you display locks for a specific InfoProvider and user (see Displaying Active Locks [page 165]).
Tab: Lock Conflict
The system displays information about the last lock conflict (see Analysis of Lock Conflicts [page 168]).
Tab: Master Locks
You can display and delete master locks here (see Displaying Master Locks [page 167]).
1.12.2 Storing the Lock Table
Use
The selection tables have to be stored and managed centrally for all users and application servers. The SAP
Standard Lock Server cannot manages locks that are based on selection tables. You therefore have to make
your own settings for storing locks that are described by selection tables.
The current locks are stored in a lock table. On the Lock Table tab page, you specify where you want to store the
lock table. There are three options for storing the lock table. You can select a suitable server depending on the
storage type.
Features
Storing the Lock Table on the SAP Standard Lock Server
The selection tables are compressed and stored on the SAP standard lock server.
The collision check for locks is not performed by the lock server, but by an ABAP program. This check requires
that the selection tables are copied to the user context. The collision check is set by default on the server you
are logged on to. If you select a different, fixed server instead, the collision check is performed there with an
RFC call.
This can be advantageous if the enqueue process is installed on a different (fast) server, and not on the central
instance in order to possibly speed up the copy process for selections from a lock table to the user context. The
server with the enqueue process is marked as such in the server selection.
 Note
In SAP lock management (transaction SM12), you use table RSPLS_S_LOCK to display the compressed
lock records. To find the actual locked selections, you need to call transaction RSPLSE (see Displaying
Active Locks [page 165]).
 Recommendation
This option requires the least administrative effort. It is suitable for small and mid-size installations. You can
set the size of the lock table using the profile parameter enque/table_size.
Storing Lock Tables in the Shared Object Memory of an Application Server (Default System Setting)
Planning Concepts
The selection tables are not compressed. They are stored in a shared object memory area. This is the default
value of the system unless you are using the SAP Standalone Engine Server, in which case the above option
(store the lock table in the SAP standard lock server) is preset.
This area is bound to an application server. In this case, the SAP standard lock server only contains a pointer to
the selection (one lock record for each selection table). You need to specify a server that contains the lock table
in Shared Object Memory. The collision check is performed on this server. (The standard setting is for the
enqueue server to be set.) It is therefore not necessary to copy the selections from the lock table to the user
context. If you select a different server instead, the collision check is performed there with an RFC call.
Here too it may be useful to install the enqueue process on a separate (faster) server rather than on the central
instance. This is because during a lock process, the selections in the shared object memory are synchronized
with the pointers on the SAP standard lock server. This synchronization is performed fastest if the server with
the enqueue process is the same as the server with the lock table. This option is therefore normally the default
setting.
 Note
In SAP lock management (transaction SM12), you find one lock record for each locked selection if using
table name RSPLS_S_LOCK_SYNC. You can find the actual locked selections in transaction RSPLSE (see
Displaying Active Locks [page 165]).
 Recommendation
This option provides better performance than storing the lock table in the standard SAP lock server. The
lock table has to guarantee the availability of the server though if you want to lock transaction data using
selections. You can set the size of the shared object memory using profile parameter abap/
shared_objects_size_MB.
1.12.3 Selecting Lock Characteristics
Use
On the Lock Characteristics tab page, you can specify which characteristics are used for the lock check.
● In the default setting, all the characteristics and the artificial characteristic 1KYFNM, for a data mart
DataStore object and for a local provider in BW Workspace, are relevant for the lock check.
● In a direct update DataStore object, all the characteristics in the default setting for the lock check are also
relevant. The artificial characteristic 1KYFNM is not available however. This means that data in direct
update DataStore objects is always locked, regardless of the key figures used in the planning function or
input-ready query.
To reduce the size of the lock table, you can exclude characteristics that do not divide lock selections from the
lock check. These include characteristics that are the same for all users or have overlapping values.
If no characteristics are selected as relevant, the whole InfoProvider is locked.
Planning Concepts
Activities
Select lock characteristics
1. To switch to change mode, choose .

2. Select an InfoProvider. In the default setting, the Lock Characteristic Selection is empty, as all the
characteristics are relevant.
3. Press Enter. Under Lock Characteristics, the system displays all lock characteristics that are currently
selected.
4. Remove any characteristics that are not relevant for the lock check from Lock Characteristics .
 Example
In cost center planning, the Fiscal Year, Version, Cost Center and Cost Element characteristics are used.
If a number of users are performing planning for the same year and the same cost elements, the Cost
Center and Version characteristics are sufficient to ensure that different users’ selections do not
overlap. Only set these characteristics as relevant for locking.
Select navigation attributes as lock characteristics
In the default settings, navigation attributes are not relevant for lock checks. This means that they are always
completely locked. In some cases, setting navigation attributes as lock characteristics can reduce the size of
the selection tables. You could use selections based on a product group for example instead of selections
based on an extensive list of products belonging to the product group.
In expert mode, you can add navigation attributes to the list of lock characteristics.
 Note
You use ok_code EXPERT to activate expert mode and NOEXPERT deactivate it.
 Caution
Make sure that no navigation attribute values are changed during planning. Otherwise, two different users
can both edit the same values of the related basic characteristic, thus writing new delta records.
User 1 plans product P1, which is in product group (navigation attribute) PG1. PG1 is selected in the
selection table, and no restriction has been set for Product. If the product group is used to set the lock, the
following situation might arise: User 2 plans product group PG2: User 1 starts planning first; the system
locks the data. During this time, the attribute of product P1 is changed from PG1 to PG2. User 2 starts
planning. Since PG2 is now technically different to PG1, there is no lock conflict. Both users can plan key
figure values for product P1.
1.12.4 Displaying Active Locks
Use
On the Lock tab page, you can see the selections that are currently locked for each InfoProvider and user. This
is similar to the Select Lock Entries function in SAP lock management (transaction SM12).
Planning Concepts
Features
Table Locks: Header Entries
The system displays the header entries for each locked selection (InfoProvider, User Name, Lock Mode, Lock
Records, Lock Handle). The user name, number of records in the locked selection, and lock mode are of
particular interest.
You can choose from the following lock modes:
● E(exclusive): Write lock that is used for all data that is edited in change mode. The data is locked and can
be edited by one user only.
● S(shared): Read lock that protects data (reference data for planning functions for example) against
changes at runtime.
 Note
For more information about the lock modes, see .
The lock handle (a 32-character GUID) represents a locked selection.
Table Lock Records
The system displays the locked selections. The display is grouped by header entry (Lock Handle),
Characteristic, type of interval (Interval) and the lower and upper interval boundaries of the selection (Internal
Characteristic Value). The selections themselves are normally displayed in the lock table: for each
characteristic, each selection is a disjunctive union of open, half open and closed intervals.
The type of interval can be:
● ( ) for an open interval

● [ ) or ( ] for a half open interval
● [ ] for a closed interval
Activities
1. Select the InfoProvider. The system finds all existing locks for the planning-relevant InfoProviders in this
InfoProvider (aggregation levels or CompositeProviders, for example).
2. Select the user. You can use wildcard searches, like ‘PRE*’or ‘*ABC*’. The active locks are listed in the
Locks: Header Entries table and the Lock Records table.
3. Notify the user and delete any locks.
 Note
If you want to delete active locks, use SAP lock management (transaction SM12). Depending on where
the lock table is stored, you might have to select a different lock structure.
○ Lock table on SAP lock server: Table name RSPLS_S_LOCK.
○ Lock table in shared objects memory: Table name RSPLS_S_LOCK_SYNC.
In SAP lock management (transaction SM12), you cannot see which data records are locked however.
To do this, use the maintenance transaction for lock settings in planning (transaction RSPLSE).
Planning Concepts
1.12.5 Displaying Master Locks
Use
You use master locks to ensure that complex planning sequences do not terminate because of lock conflicts
with other users. On the Master Locks tab, you can display and delete active master locks.
Master locks are set at runtime by planning sequences at planning-relevant InfoProvider level. These
sequences are integrated as steps into process chains. Before processing the data, the system determines all
required selections. The system first tries to set a normal lock for these selections. If this is possible, these
selections are saved as master locks and the normal locks are removed. After this, no users can change data in
this area.
The process chain itself normally runs in the background. Individual subprocesses can be authenticated as
master locks and only these are permitted to pass the master lock. When the planning sequences are run, the
data to be edited is protected as usual by normal locks. Once the process chain has processed the data, the
master locks are removed.
Integration
Master locks are only set by planning sequences in process chains.
Features
Table Master Locks: Header Entries
The master locks set by a process chain are assigned a lock handle. The system displays the header entries for
each locked selection (Lock Handle, InfoProvider, Process Chain, Process Variant).
Table Lock Records
The system displays the locked selections for the lock handle. The display is grouped by header entries (Lock
Handle), the associated selections (Number of Selection Table), the Characteristic, the interval type (Interval)
and the lower and upper interval boundaries of the selection (Internal Characteristic Value). The selections
themselves are normally displayed in the lock table: for each characteristic, each selection is a disjunctive
union of open, half open and closed intervals.
The type of interval can be:
● ( ) for an open interval

● [ ) or ( ] for a half open interval
● [ ] for a closed interval
Planning Concepts
Activities
1. Select an InfoProvider. The system detects all master locks in the planning-relevant InfoProviders or
aggregation levels and displays them in the overview.
2. To delete a master lock, delete the corresponding row in the Master Locks: Header Entries table.
 Note
Even if you delete master locks, the transaction data is protected at runtime by normal active locks.
Without the master lock, it might not be possible to execute parts of planning sequences due to lock
conflicts with other users.
1.12.6 Analyzing of Locking Conflicts
Use
On the Locking Conflict tab page, the system displays the selections for the last lock conflict. The system
displays the following information about the context of the caller:
● InfoProvider
● User who requested a lock
● User with lock (user who has already locked the selection).
● Date and time of the lock query in the system time
● Whether or not the lock conflict occurred with a master lock
Activities
To identify the cause of the lock conflict, compare the selections in tables Selection in Lock Request and Locked
Selection. The lock conflict occurs where selections overlap.
1.12.7 Sizing Lock Tables
Use
For an InfoProvider of the data basis for planning, no access is allowed to the SAP BW∕4HANA lock server
during a lock operation. Space on the lock server is restricted. When implementing planning applications in a
SAP BW∕4HANA system, it is therefore necessary to choose a design that keeps the number and size of the
selections as small as possible. The smaller the lock table, the faster the response times of the lock server.
You can reduce the size of the lock table by removing characteristics from the list of lock-relevant
characteristics in a planning-relevant InfoProvider if these characteristics do not divide the selection. These
Planning Concepts
include characteristics which are the same for all users or which have overlapping values. More information:
Selecting Lock Characteristics [page 164].
The following sections contain information about sizing the lock table for planning. These sections explain how
to calculate the required memory and set the profile parameters accordingly.
 Note
For more information about the various options for storing lock tables, see Storing Lock Tables [page 163].
For current sizing information, see SAP Note 928044 .
Integration
In profile parameter maintenance (transaction RZ11), you can display the values that are currently set.
Features
Storing lock tables on the SAP Standard lock server
You use profile parameter enque/table_size to set the size of the lock table on the SAP standard lock server.
The enque/table_size = 25.000 setting should be sufficient for most systems where planning is used.
You can get a more accurate idea of the number of lock records required as follows:
● The number of planning-relevant InfoProviders being used actively is IC.

● The average number of rows in the selection table is Rec. In lock setting maintenance for planning
(transaction RSPLSE), you can calculate this number for a given user by viewing the locked selections on
the Display of Active Locks tab page.
● The number of lock requests per user is LReq. This number depends on the design of the planning
application; number of input-ready queries, number of related planning applications and how often these
components request data in change mode.
● The number of active users is U.
● The compression factor for a selection table is Compr. This factor is between 5 and 10.
The number of NLCK lock records is:
NLCK = IC * U * LReq * Rec / Compr
In SAP lock management (transaction SM12), choose Extras Statistics to ascertain the maximum
number of lock records that can be stored in the lock table according to the current value of the enque/
table_size profile parameter. You can find the value in the Lock Entries Table, Size row.
Storing lock tables in the shared object memory of an application server (default system setting)
You use the abap/shared_objects_size_MB profile parameter to set the size of the lock table in the shared
object memory of an application server.
Planning Concepts
The abap/shared_objects_size_MB = 200 setting should be sufficient for most systems where planning is
used.
You can get a more accurate idea of the number of lock records required as follows:
● The number of planning-relevant InfoProviders being used actively is IC.

● The average number of rows in the selection table is Rec. The actual selections are in the shared object
memory twice: once optimized for search access by characteristic and once optimized for access by
locked selection (secondary index). The DDIC structure used has a width of 207 characters, or 207 bytes
(414 bytes in Unicode systems). You can expect approximately one kilobyte per row in the selection table.
● The number of lock requests per user is LReq. This number depends on the design of the planning
application; number of input-ready queries, number of related planning applications and how often these
components request data in change mode.
● The number of active users is U.
The number of NLCK lock records is:
NLCK = IC * U * LReq * Rec
The required memory space in KB is calculated by multiplying NLCK by 2. This is because, when a lock is
requested, the system makes a copy of the locked selection and retains this for the duration of the collision
check.
For information about the memory currently required for the SAP BW∕4HANA lock server, see area
maintenance for the shared object (transaction SHMA). Call this transaction on the server with the SAP
BW∕4HANA lock table; use CL_RSPLS_ENQ_AREA as the area.
Planning Concepts
2 Creating Planning-Relevant Objects
To model planning-specific metadata objects and reusable metadata objects that are also relevant for planning
(filters and variables), you use the BW Modeling Tools.
Features
The BW Modeling Tools provide you with the following functions for editing planning-specific metadata objects:
● Aggregation levels
● Data slices
● Characteristic relationships
● Planning functions
● Planning Sequences
For manual entry of planning data, define an input-ready query.
To display planning-specific metadata objects for a particular object opened in the editor in the BW Modeling
tools, use the planning view.
Related Information

Creating a Data Slice [page 174]
Creating Planning Functions [page 179]
Creating a Planning Sequence [page 181]
Planning Concepts
Creating Planning-Relevant Objects PUBLIC 171
2.1 Creating Aggregation Levels
To plan data manually or to change it using planning functions, you need a planning-specific InfoProvider
known as the aggregation level. You use the aggregation level to set the granularity of planning by only adding
characteristics and key figures of the underlying InfoProvider for planning.
Prerequisites
You are using an SAP HANA database. You have installed and configured the BW Modeling tools.
You have selected an InfoProvider that is suitable for planning as the basis of the aggregation level (see Data
Basis InfoProvider [page 7]).
Context
You can create more than one aggregation level for an InfoProvider, thereby modeling various levels of planning
and hierarchical structures for example. Note that aggregation levels cannot be nested.
Procedure
1. Create the aggregation level. In the Project Explorer view, you can create an aggregation level either for a
BW project or for an InfoArea. You can also create an aggregation level as a copy of an existing aggregation
level.
a. To do this, open the context menu for a BW project or an InfoArea and choose New Aggregation
Level , or open the context menu for the aggregation level you want to use as a template and choose
Copy . The New Aggregation Level dialog box appears. Depending on your point of entry, the
system will have already preselected certain objects.
b. The system preselects the current BW project at the very least. By choosing Browse, you have the
option of selecting a different BW project.
c. If you have created an aggregation level for a BW project, you also have to select the required InfoArea.
Enter its technical name or a corresponding search term. The system helps you when searching for the
technical name, and returns a list of results under Matching items.
d. If you have created an aggregation level for an InfoArea, the system preselects this InfoArea. By
choosing Browse, you have the option of selecting a different InfoArea.
e. To add your aggregation level to your local favourites, choose Add to Favorites.
f. Enter a unique technical name and a description for the aggregation level.
g. Specify the required InfoProvider, which is suitable for planning. By choosing Browse, you can select
from the list of suitable InfoProviders.
Planning Concepts
172 PUBLIC Creating Planning-Relevant Objects
h. If you have created an aggregation level as a copy of an existing aggregation level, the system
preselects this aggregation level together with the underlying InfoProvider. By choosing Browse, you
have the option of selecting a different aggregation level as the template.
i. Choose Finish.
The system opens the new aggregation level in the Eclipse Editor. The General tab opens, together with all
aggregation level settings that you have made so far.
2. Go to the Output tab. The system displays the definition of the aggregation level.
If you are creating a new aggregation level, Provider Fields is empty.
If you have created an aggregation level as a copy of an existing aggregation level, the selected fields of the
underlying aggregation level are displayed under Provider Fields.
3. Define which characteristics and key figures you want to be available in the aggregation level.
a. Switch from the Project Explorer view to the InfoProvider View. The system displays the InfoProvider
underlying the aggregation level.
b. From the InfoProvider view, choose the required characteristics and key figures, and drag these to the
definition of the aggregation level.
If you click on the provider field, the sysem displays the properties of the object on the right side of the
screen.
If you click on the associated object, the system opens the object display in a new window.
 Note
The key figures contained in the aggregation level are aggregated using the characteristics not
contained in the aggregation level.
c. If you want to remove an InfoObject, open the context menu and choose Remove...
4. Save the the definition of the aggregation level.
○ If you choose Save, the system saves the current definition of the aggregation level as an M version.
○ If you choose Activate, the system checks the current definition of the aggregation level and, if
possible, saves it as an A version. The check result appears in the Problems View.
Once it has been activated, the aggregation level is ready for use.
Related Information

Simple Aggregation Level [page 25]
Complex Aggregation Level [page 26]
The following links take you to the documentation for the aggregation level concept.
Planning Concepts
2.2 Creating a Data Slice
You can use data slices to protect the main data in a basic InfoProvider against changes.
Prerequisites
You have selected the required basic InfoProvider, a DataStore object that is, with the Planning Mode flag set.
Note that this has an active Object Status and Version State.
If you want to work with an exit class, you need an ABAP in Eclipse project.
Context
If you use a data slice to protect the data in a basic InfoProvider centrally against changes, this affects all
planning InfoProviders that use this InfoProvider. It also affects all input-ready queries and planning functions
that use this InfoProvider.
Procedure
1. To create a data slice, choose the corresponding link next to the Planning Mode field under Modeling
Properties on the General tab.
If a data slice already exists for the InfoProvider in question, you can choose Open Data Slices from the
InfoProvider’s context menu.
2. When you create a new data slice, you first have to assign the relevant transport request.
○ If the transport system is active in your system, a dialog appears where you can select the transport
request. Select the relevant transport request.
○ If the transport system is not active in your system, the system saves automatically to $TMP in the
background.
3. The system displays the Data Slices tab. Under Data Slices, you see any existing data slices. To make
changes to a given data slice, select it.
4. If you want to create a new data slice based on a selection, choose Add Selection. The Edit Selection dialog
appears.
1. Select the characteristic to be restricted and add it to the Selection Details column by double-clicking it
or dragging and dropping it.
2. Open the context menu for the characteristic and choose Restrict. The Edit Filter dialog appears.
Restrict the characteristic to:
○ a single characteristic value
○ a variable characteristic value interval
○ variable characteristic values
Planning Concepts
○ a specific hierarchy node
○ a variable hierarchy node
3. Choose OK.
4. Under General, enter a description for the data slice.
5. If you want to create a new data slice based on an exit class, choose Add User Exit. The Edit Selection dialog
appears.
1. Select the characteristic to be restricted and add it to the Selection Details column by double-clicking it
or dragging and dropping it.
 Note
You will only see the current values in the exit for these characteristics. If you are also interested in
the initial values in the exit, select the flag in the # is Used column under Selection.
2. Choose the required exit class. Input help is provided.
 Note
The exit class must implement interface 'IF_RSPLS_DS_EXIT'. Only these types of classes are
offered for editing in maintenance. We recommend that the customer class inherits from template
class 'CL_RSPLS_DS_EXIT_BASE'. The template class itself can be run directly, but does not
execute an action. Re-implement method ‘IS_PROTECTED’. Note the example source code given in
the template class too: An infrastructure for buffering can be provided here.
3. Choose OK.
4. Under General, enter a description for the data slice.
5. Under Selection, select the flag in the # is Used column for all characteristics whose initial value you
want to be taken into account in the exit.
 Note
If this flag is not set for a characteristic, the exit is not called for aggregation levels that do not
contain this characteristic, since the characteristic value in question would be initial in this case.
6. Order the steps according to your preference by moving them up or down in the list.
7. Set the active flag for all steps that you want to be taken into account.
8. Remove any steps that are not required by choosing Remove.
2.3 Creating Characteristic Relationships
Characteristic relationships are used to define a relationship between characteristics with matching contents.
Context
You have selected the required basic InfoProvider, a DataStore object that is, with the Planning Mode flag set.
Note that this has an active Object Status and Version State.
Planning Concepts
Procedure
1. To create a characteristic relationship, in the General tab under Modeling Properties choose the link next to
the field Planning Mode.
If there is already a characteristic relationship with the InfoProvider, from the context menu for the
InfoProvider you can choose Open Characteristic Relation.
2. If you create a new characteristic relationship, you must first assign the relevant transport request.
○ If the transport system is active in your system, a dialog appears where you can select the transport
request. Select the relevant transport request.
○ If the transport system is nicht active in your system, the sytem saved it automatically to $TMP in the
background.
3. The characteristic relationship’s General Settings tab opens. In this tab, you can configure the central
settings for the selected InfoProvider. These settings apply to the entire planning model, provided that the
model is based on the InfoProvider.
4. Go to the Characteristic Relations tab. Under Relations, you can use the corresponding pushbuttons to add,
move or remove characteristic relationships of type DSO, Exit Class, Attribute or Hierarchy.
5. Select the type of the characteristic relationship.
6. Select the basis of the characteristic relationship.
This is different for each type of relationship:

○ Type Attribute: A characteristic with master data
○ Type Hierarchy: The hierarchy basic characteristic
○ Type DataStore: A DataStore object
○ Type Exit: An exit class
7. Under General, you specify whether the system should derive the time characteristic from the basic
characteristic. You can also stipulate that this derivation should also be performed for the combination
check and be based on the combination proposals.
8. Define the further settings based on the selected relationship type.
9. Remember to save the characteristic relationship you have defined before leaving the tab page. The
system automatically saves the characteristic relationship actively.
Related Information

Tab Page: Characteristic Relationships [page 177]
These links take you to the documentation for tasks.
This link takes to you to the documentation for concepts.
Planning Concepts
2.3.1 Tab Page: General Settings
In this tab, you can configure the central settings for the selected InfoProvider. These settings apply to the
entire planning model, provided that the model is based on the InfoProvider.
The display mode provides you with an overview of settings available in the system.
In change mode, you can make changes to the settings:
1. Under Key Date, you can set a fixed date or variable as the key date, thus deviating from the default value.
This key date is used in all time-dependent objects used for planning, such as in characteristic
relationships, data slices and in the planning buffer (values of time-dependent navigation attributes).
2. In the Maximum Number of Created Combinations field, you can set the maximum number of
combinations to be created by the system for the selected InfoProvider.
3. Under Save Plan Data, you can define whether the system checks the validity of the data of the selected
InfoProvider with a planning sequence prior to saving, and what basis the changed data should be read on.
○ In the Planning Sequence When Saving field, you can specify the planning sequence that checks the
data to be saved in this InfoProvider. By pressing Browse, you can call input help for this setting.
If the planning sequence reports an error, the data is not saved.
○ You can specify which data the planning function processes. This data is described by the filters
defined in the planning sequence. With the Only Read Changed Data setting, these filters are adjusted
when the sequence runs. This adjustment ensures that a smallest possible maximum set of data is
described, which was changed during the user session and not yet stored on the database. This setting
can affect performance, since it normally results in less data records being processed.
Only Read Changed Data affects performance.
○ In the Aggregation Level For Reading Changed Data Only field, you can specify which aggregation level
is used to read the changed data. By pressing Browse, you can call input help for this setting.
2.3.2 Tab Page: Characteristic Relationships
On this tab page, you can make various settings depending on the type of the characteristic relationship.
Depending on your selection in the Derivation field, you can either select check characteristics in the Used
Characteristics table or source and target characteristics in the Source and Target tables:
● If you have not selected a derivation, you can select check characteristics.
● If you have selected with derivation, you can select source and target characteristics, and move these
between the tables either by pressing Add and Remove or by drag & drop.
Type: Attribute
The attributes of the basic characteristic can be selected as the time characteristic. The existing combinations
of characteristics and attribute values are always interpreted as valid combinations.
 Example
Characteristic Currency characteristic is an atttribute of characteristic Controlling Area.
Planning Concepts
If you want to use a different basic characteristic, delete the current characteristic relationship and create a
new one with the required basic characteristic.
Type: Hierarchy
All characteristics that you set flagged as External Characteristics in Hierarchy are available as source or target
characteristics in the InfoObject maintenance screen. In addition to the hierarchy basic characteristic, the
hierarchy must include at least one other characteristic.
Only one characteristic is permitted as a source and/or target characteristic (higher-level characteristics are
not counted in compound characteristics).
The permitted combinations are taken from the hierarchy structure. The same hierarchy can be used in
multiple relations. In the first step, you derive a characteristic on the next level up from the hierarchy basic
characteristic; in the second step, you take the derived characteristic and derive the characteristic on the next
level.
If the hierarchy is version and/or time-dependent, you can also make settings from the basic characteristics
deviating from the version and/or key date. The hierarchies used for this can also be defined with the matching
variables.
In an existing characteristic relationship, you cannot change the basic characteristic, but you can select a
different hierarchy. All hierarchies for the basic characteristic can be selected. If you want to use a different
basic characteristic, delete the current characteristic relationship and create a new one with the required basic
characteristic.
DataStore Object Type
The data records contained in the DataStore object define the valid characteristic combinations and are used
for characteristic derivation.
Only combination check: You can select all InfoObjects from the DataStore object (except for key figures). If
you set the With Subsets flag, the relation is also applied if there is a non-empty subset of characteristics of the
relation in the aggregation level. In this case, the relation defines precisely the combination of the DataStore
object as valid that arises from projection of the records of the DataStore object to the subset. We recommend
either including all characteristics in the key of the DataStore object or setting these with a single value as a
restriction in the relation.
With Derivation: You can select the keys of the DataStore object as source characteristics. Target
characteristics can be InfoObjects from the data part of the DataStore object (except for key figures). Every
characteristic selected can only be in one of the two tables.
A restriction can be defined for the keys of the DataStore object. If you define restrictions in the Restriction
table, the system applies the part defined by this restriction in the combination check or derivation. You can
also define variables for the restrictions. These variables then have to be replacable without a dialog however.
 Note
If you restrict a compounded characteristic, not that the compound parent does not have to be added to
the Restriction table.
Planning Concepts
Type: Exit
The valid characteristic combinations and derivable characteristic values are defined by the customer-specific
implementation of the specified exit class. The Exit Class link takes you to the dialog for selecting an ABAP in
Eclipse project, where you can display and change the exit class.
The exit class must implement interface IF_RSPLS_CR_EXIT. Only these types of classes can be edited in
maintenance. We recommend deriving your class from the example class CL_RSPLS_CR_EXIT_BASE. You then
only have to implement methods CHECK, DERIVE, and CREATE. Class CL_RSPLS_CR_EXIT_BASE itself can be
run directly, but does not execute an action.
 Remember
For more information, see the documentation about the attributes and values of the class in transaction
SE24. If you want to buffer access to data methods that have already been read in methodd CHECK,
DERIVE, CREATE, you can pass this task onto the system and do not have to implement it in this exit. To do
this, you go to CONSTRUCTOR in the exit class and set attribute N_USE_EXTERNAL_BUFFER in interface
IF_RSPLS_CHAR_RELATION. Note that you should always implement method CREATE, as the system
always calls this method if combinations should be created on the basis of the characteristic relationships.
This is the case for example in input-ready queries (Access Type for Result Values, input help in dynamic
filters or in new rows) and in certain planning function types.
You can also change the exit class for your characteristic relationship subsequently, as the list of
characteristics from the underlying InfoProvider is independent of this. You can add all characteristics and
compounded characteristics.
 Note
If two compounded characteristics have the same compound parent, and one of these characteristics is
added to the Source table while the other is added to the Target table, the compound parent is added to the
Source table.
Related Information

2.4 Creating Planning Functions
Planning functions allow planning of system-based processing or generation of data. To be able to use a
planning function, define the type of planning function and the aggregation level on which you want the
Planning Concepts
planning function to work. You can also set the characteristic usage, the conditions and the associated
parameter sets.
Prerequisites
You have created the following objects:
● The aggregation level on which the planning function is created.

● Filters that are specifed when the planning function is executed. The planning function locks the data
defined in the filter in the basis InfoProviders belonging to the aggregation level. The filter has to be defined
on the same aggregation level as the planning function.
Context
You can create, copy, delete, change, check, and save planning functions.
Procedure
1. You are in the Project Explorer. In the context menu for an InfoArea of your project, choose New
Planning Function . The dialog for creating a planning sequence appears.
2. Enter a name and a description.
3. Select the aggregation level that you want the planning function to work on. Input help is provided.
4. Select the default planning function type that you want the planning function to have. Input help is
provided.
5. By choosing Copy from, you can use a planning function as a template. Input help is provided.
6. Choose Finish. The system takes you to the planning function maintenance screen on the General tab.
Under General, you can see the technical name, the description, the name of the underlying aggregation
level, the selected planning function type and a help text. These show you what the function does, and how
you can work with it.
7. Under Characteristic Usage , you can see all available characteristics. Select the characteristics that you
want to be changed and the characteristics that you want to be added to the condition.
8. Switch to the Parameters tab page.
This tab page is always displayed, even if the planning function type does not have any parameters.
9. Under Conditions, you can add, edit, duplicate and remove conditions. You can also change the sequence
of the conditions.
10. Under Parameters, you can define parameters specifically for the planning function type in question.
11. Check the planning function.
During the check, you have to specify values for existing mandatory entry variables if values have not been
selected for these variables in the current session. If this is the case, an entry screen appears.
Planning Concepts
12. Save the planning function.
Planning functions can be saved even if they are not consistent.

13. Execute the planning function.
To execute a planning function, you first have to include it in a planning sequence. Before the planning
function is executed, the system always checks whether it is consistent.
Related Information

Standard Planning Function Types [page 40]
2.5 Creating a Planning Sequence
With a planning sequence, you can group planning functions together, save them in a sorted sequence, and
sort the entire group. You can even insert steps for manually entering data in a planning sequence.
Prerequisites
You have created the required planning functions.
Context
You can create, change and execute a planning sequence, and copy with all subelements.
Procedure
1. You are in the Project Explorer. In the context menu for your project, or an InfoArea of your project, choose
New Planning Sequence... . The dialog for creating a planning sequence appears.
2. If you are creating the planning sequence for a project, you now have to select the required InfoArea. Input
help is provided.
3. Enter a name and a description.
4. By choosing Copy from, you can use a planning sequence as a template. Input help is provided.
5. Choose Finish. The system takes you to the maintenance screen on the Steps tab.
Planning Concepts
6. If you want to add a step, choose Add. The Add Planning Sequence Step dialog appears.
7. Select the step type: Planning Function or Manual Input.
8. Select the underlying aggregation level.
 Caution
If you have defined a step on an aggregation level, we do not recommend changing the aggregation
level. If this is necessary however, first remove the step and then create a new one based on the
required aggregation level.
9. To add the step to your planning sequence, press OK. You are returned to the Steps tab.
10. Under General, select the required filter and - if applicable - the planning function. You can select from
objects that are available for the chosen aggregation levels. In this case, these are the (reusable) filters.
If you are creating a step of type Manual Input, you also have to define a filter. Otherwise an error message
is displayed.
If you want to make changes to a planning function, click on the Planning Function link under General. The
SAP GUI for editing planning functions appears.
Under General, there are two further settings that apply globally for the entire planning sequence.
○ Reprocess Variables: If you select this option, the variables are processed again before execution.
○ No Data Slice Check: If you choose this option, the planning sequence ignores data slices during
execution. This can be of interest for special cases. Note however that the data slices remain valid for
other users and in other sessions.
11. Design your planning sequence:
○ By choosing Duplicate, you can copy a step (and then change it if required).
○ By choosing Up, you can move a step upwards. It is then executed earlier.
○ By choosing Down, you can move a step downwards. It is then executed at a later point in time.
○ By choosing Remove, you can remove a step.
12. If you have defined the planning sequence, you can execute it. To do this, choose Execute Planning
Sequence from the toolbar. This takes you to the SAP GUI in display mode. Here you can execute the
planning sequence either step by step or in its entirety.
 Note
Note that steps of type Manual Input are ignored during execution.
13. To copy the planning sequence together with all of its subelements (filters and planning functions), choose
Deep Copy of Planning Sequence from the toolbar. This takes you to the SAP GUI in display mode. Here you
can select the subelements to be copied. In the default setting, the technical names of all copied elements
are given the prefix . CP_ and the description Copy of .
 Note
Note that the aggregation level is not copied.
Planning Concepts
Important Disclaimers and Legal Information
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your
agreements with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such
links, you agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this
information.
Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by
SAP at any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use
the experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your
feedback (e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax
and phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of
example code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.
Videos Hosted on External Platforms

Some videos may point to third-party video hosting platforms. SAP cannot guarantee the future availability of videos stored on these platforms. Furthermore, any
advertisements or other content hosted on these platforms (for example, suggested videos or by navigating to other videos hosted on the same site), are not within
the control or responsibility of SAP.
Planning Concepts
Important Disclaimers and Legal Information PUBLIC 183
www.sap.com/contactsap
© 2019 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.
Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.
Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.
THE BEST RUN

Planning Concept in BW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Planning Concept in BW

Uploaded by

Copyright:

Available Formats

© 2019 SAP SE or an SAP affiliate company. All rights reserved.

THE BEST RUN

2 Creating Planning-Relevant Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

The planning model is comprised of the following elements:

● Data (stored in InfoProviders intended for planning)

1. Creating Data Basis and Managing Locks

Suitable InfoProviders are used to store data for planning.

More information about transporting planning model objects: .

3. Defining Input-Ready Queries

Data Basis InfoProvider [page 7]

Data Slices [page 15]

Basis InfoProviders that are suitable for planning

Characteristic Relationships and Data Slices

Default Key Date for Planning

1.2.1 Characteristic Relationships

Definition of a Characteristic Relationship

Behavior of combination checks with and without derivation

● Combination check without derivation:

Data Basis InfoProvider [page 7]

1.2.2 Characteristic Relationships for Time Characteristics

Source characteristics Target characteristics Comment

0CALDAY, 0FISCVARNT 0FISCPER Fiscal year variant required due to com­

0CALDAY, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com­

0CALDAY, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com­

0FISCPER, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com­

0FISCPER, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com­

0CALWEEK, 0WEEKDAY1 0CALDAY

0CALYEAR, 0CALQUART1 0CALQUARTER

0CALYEAR, 0CALMONTH2 0CALMONTH

0FISCVARNT, 0FISCYEAR, 0FISCPER3 Fiscal year variant required due to com­

Characteristic Relationships [page 9]

1.2.3 Data Slices

There are two types of data slice:

The following basic rules apply for data slices:

Creating a Data Slice [page 174]

Mapping Table Z_MAP_PRODUCT

R_01 RP_123 UP_123

R_02 RP_123 UP_321

Implementation on the SAP HANA database

● IF_RSPLS_CR_EXIT_HDB : SQLScript implementation of the characteristic relationships

The SAP HANA-specific interfaces have the following tasks:

1.2.4.1 SAP HANA HANA-Specific Interfaces for

Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_CR_EXIT_HDB

E_DB_SCHEMA_NAME Name of a database schema that contains the SQLScript

If the parameter of the method is not set, the DB schema of

E_PROCEDURE_NAME_CHECK Name of the SQLScript procedure that contains the imple­

E_PROCEDURE_NAME_DERIVE Name of the SQLScript procedure that contains the imple­

E_PROCEDURE_NAME_CREATE Name of the SQLScript procedure that contains the imple­

E_PARAMETER_NAME Name of a DDIC structure that describes additional parame­

If the parameter of the method is not set, no additional infor­

Method GET_SQLSCRIPT_INFO of interface IF_RSPLS_DS_EXIT_HDB has the following export parameters:

Export Parameters of Method GET_SQLSCRIPT_INFO of IF_RSPLS_DS_EXIT_HDB

E_DB_SCHEMA_NAME Name of a database schema that contains the SQLScript

If the parameter of the method is not set, the DB schema of

E_PROCEDURE_NAME_PROTECTED Name of the SQLScript procedure that contains the imple­

E_PARAMETER_NAME Name of a DDIC structure that describes additional parame­

If the parameter of the method is not set, no additional infor­

Export Parameter of Method GET_SQLSCRIPT_PARAMETERS

E_S_PARAMETER Structure used to pass on additional parameters to the

At runtime, this parameter has the type of the DDIC struc­

1.2.4.2 Parameters for the SQLScript Procedures

Methods for characteristic relationships

Methods for data slices

0CALDAY, 0FISCVARNT 0FISCPER Fiscal year variant required due to com

0CALDAY, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com

0CALDAY, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com

0FISCPER, 0FISCVARNT 0FISCYEAR Fiscal year variant required due to com

0FISCPER, 0FISCVARNT 0FISCPER3 Fiscal year variant required due to com

0FISCVARNT, 0FISCYEAR, 0FISCPER3 Fiscal year variant required due to com

E_PROCEDURE_NAME_CHECK Name of the SQLScript procedure that contains the imple

E_PROCEDURE_NAME_DERIVE Name of the SQLScript procedure that contains the imple

E_PROCEDURE_NAME_CREATE Name of the SQLScript procedure that contains the imple

E_PARAMETER_NAME Name of a DDIC structure that describes additional parame

If the parameter of the method is not set, no additional infor

E_PROCEDURE_NAME_PROTECTED Name of the SQLScript procedure that contains the imple

E_PARAMETER_NAME Name of a DDIC structure that describes additional parame

If the parameter of the method is not set, no additional infor

At runtime, this parameter has the type of the DDIC struc