12/3/2020

Model Con guration Guide

Generated on: 2020-12-03 10:11:55 GMT+0000

SAP Integrated Business Planning for Supply Chain | 2011

PUBLIC

Original content: [Link]

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation. The information included in
custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be missing important aspects and/or correlations to other
topics. For this reason, it is not for productive use.

For more information, please visit the [Link]

Planning Models in SAP Integrated Business Planning

A planning model describes the structure of your plan in terms of data and calculations. It de nes how data is stored, calculated, and aggregated in the system.
From a technical perspective, a planning model is a collection of master data and time series data that is organized in dimensions and enhanced with speci c
calculations. All models are based on the following entities:

Attributes

Master data types

Time pro les

Planning areas

[Link] 1/128
12/3/2020
Planning levels

Key gures (including snapshots)

Versions

Calculations

Miscellaneous additional entities such as global con guration parameters, planning operators, and reason codes.

The gure below illustrates the relationship between the main con guration entities.

 Note
Hover over the elements for more information.

This image is interactive. Hover over each area for a description. Click highlighted areas for more information.

Planning operators are functions that are associated with a planning area. An important example of a planning operator is the COPY operator, which you can use to
copy values of source key gures to target key gures in the same version (base or other) of a planning area.

SAP Integrated Business Planning allows you to con gure and customize your own planning models to address your unique business requirements. The following
apps, which you can access from the launchpad, include all features that enable you to con gure a model from scratch, and activate it:

Attributes

Master Data Types

Time Pro les

Reason Codes

Time Pro les

Sample Model Entities

Planning Areas

Planning Operators

Snapshots

Many model entities (planning areas, master data types, and time pro les) can also be copied and modi ed. (You cannot, however, copy attributes or planning
operators.)

Sample Planning Areas

The SAP Integrated Business Planning web client provides display access to sample SAP planning areas, which are shipped with SAP Integrated Business Planning.
You can use sample planning areas as a basis for creating your own planning areas. You can copy one of the planning areas and extend it as necessary to meet your

[Link] 2/128
12/3/2020
particular business needs. You can add your own master data types, key gures, calculations, and attributes. The following table lists the planning areas that are
available:

Sample Planning Area Applications Represented

SAP3 Inventory

SAP4 Supply (time-series-based supply planning algorithms)

SAP4C Business network collaboration

SAP4S Time-series-based shelf life planning heuristic only

SAP5 SAP Supply Chain Control Tower

SAP6 Demand

SAP7 Order-based planning

 Note
To use the SAP7 sample planning area, you need to make assignments in the Settings for Order-Based
Planning app. In this app, you map attributes and select key gures, for example. For more information,
see Settings for Order-Based Planning and Setting Up Order-Based Planning.

 Note
If you need a planning area for order-based planning and time-series-based supply planning, we
recommend that you use a combination of the SAP7 and SAP4 sample planning areas, or SAPIBP1 as
described in SAP Best Practices for SAP Integrated Business Planning. For more information, see
[Link] .

SAP8 Demand-driven replenishment

SAPIBP1 The uni ed planning area is a comprehensive sample planning area that supports an integrated planning
process covering all of the following:

Demand planning

Demand sensing

Inventory optimization

Supply planning (time-series-based supply planning algorithms)

Sales and operations planning

SAP Supply Chain Control Tower

You can use the uni ed planning area SAPIBP1 to jump-start the implementation in case your business
process requires integration across different IBP applications. Just like any other sample planning area,
this planning area delivers a pre-built integration scenario which you can customize to t your unique
requirements. You can also use the uni ed planning area for the separate IBP applications by copying only
the part of the planning area that you need for that speci c application. To copy parts of the uni ed
planning area, use the partial copy option. For more information about partial copy see the Create New
with Dependencies and the Replace Existing Including Dependencies sections.

 Note
For more information about an integrated planning process using the uni ed planning area, see
Example: Integrated Planning Process with Uni ed Planning Area.

For the integrated planning process based on the uni ed planning area, the SAP Best Practices for SAP
Integrated Business Planning provides sample data, planning view templates, prede ned dashboards,
con guration guides, test scripts and more. Customer test tenants and IBP Starter Edition instances
include an activated copy of the uni ed planning area with the sample content.

You can also download the content at [Link] .

The following table shows the scope of the sample planning areas:

Model SAP3 SAP4 SAP4C SAP4S SAP5 SAP6 SAP7 SAP8 SAPIBP1
contents

Complete No No No No No Yes No No Yes

demand model
example

Statistical No No No No No Yes No No Yes

forecasting

[Link] 3/128
12/3/2020

Model SAP3 SAP4 SAP4C SAP4S SAP5 SAP6 SAP7 SAP8 SAPIBP1
contents

Supply No Yes Yes No No No No No Yes

planning
optimization
(time-series-
based supply
planning
optimizer)

Multi-level Yes Yes No No Yes No No No Yes

supply
planning (time-
series-based
supply
planning
heuristic and
time-series-
based supply
propagation
heuristic)

Multi-level No No No Yes No No No No No
supply
planning (time-
series-based
shelf life
planning
heuristic)

Financial and No No (only No (only No No No No No Limited

sales planning optimizer optimizer
costs) costs)

Inventory Yes (only No No No No No No Yes (Buffer Yes

planning and optimize levels)
optimization inventory
targets)

Order-Based No No No No No No Yes No No
Planning

SAP Supply No No No No Yes No No No Yes

Chain Control
Tower

Business No No Yes No No No No No Yes

network
collaboration

To access these planning areas, launch the Sample Model Entities app.

As well as these planning areas, small sample planning areas with examples of advanced con guration to meet different business requirements are provided in SAP
Notes, together with information on how to request L-code if con guration can't meet your requirements. The SAP Notes are listed in the following table:

SAP Note Title

2347105 Master Note for the Con guration of Sample Models

2240170 Rolling Sum of the Last Three Periods

2240173 Calculation of Average and Weighted Value of Price Key Figures (Including Unit of Measure and Currency
Conversion)

2240178 View Monthly Key Figures at Weekly Level Based on Number of Weeks in the Month

2286684 Last Period Aggregation for Key Figures

2288329 Time as a Dimension (Year-To-Date and Quarter-To-Date Aggregations)

2289248 Time-Independent Unit of Measure Conversion

2289617 Aggregation of Last n Periods in Current and Future Periods

2289651 Last Period Aggregation with Unit of Measure Conversion

2298382 Requesting L-Code from SAP

[Link] 4/128
12/3/2020

SAP Note Title

2319165 Triggering an Alert on First Occurrence

2586250 Bill of Material for Demand Planning

SAP provides multilanguage support for the sample planning areas. Translations in all languages supported by SAP IBP are available for following sample content:

Key gure names and descriptions

Attribute names and descriptions

Planning area attribute descriptions

If you enable multilanguage support in the Multilanguage Support app, you can handle these properties in the logon language of your application. For more
information, see Setting Up Multilanguage Support for Modeling Objects.

Con guring a Planning Area

A planning area describes the structure of a plan in terms of data and calculations. It de nes how data is stored, calculated, and aggregated in the system.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
Before con guring your planning area, SAP recommends that you create a blueprint based on the customer requirements to map the business processes to a
planning area. This blueprint describes the business processes as they are and also as they are to be. A blueprint outlines the key business functions and the
required scope and identi es the master data types, attributes, data integration, key gures, and calculations that need to be modeled in the system.

Procedure
1. Select a sample planning area based on your business requirements and create a copy of it using the Create New with Dependencies option.

Use the Sample Model Entities app to view the available sample content.

If you want to use SAP Integrated Business Planning for demand sensing, for example, copy the SAP6 planning area. If you want to use more than one
process, for example, demand and inventory, you could create a partial copy of the SAPIBP1 planning area.

2. Adjust your planning area as needed.

 Caution
To run the inventory operators and time-series-based supply planning algorithms, you have to use speci c technical IDs de ned by SAP for the relevant
master data types, attributes, and key gures. For demand sensing, the same applies to key gures for which a business meaning has not been speci ed
and certain master data attributes. For more information, see the documentation of the relevant planning operator in this guide and the respective
chapter of the application help.

 Recommendation
SAP recommends that you try out any changes to your planning area in a test environment (including activating the planning area and testing the results)
before you transport or export and import changes to the production system.

a. Create new attributes or change the existing ones.

b. Create new master data types or change the existing ones.

c. Adjust the time pro le.

 Caution
If you replace the time pro le in a planning area, you need to adjust the planning area con guration extensively to ensure its consistency.

d. Adjust the planning area settings as required.

e. Create new planning levels or change the existing ones.

f. Create new key gures or change the existing ones.

g. Add planning operators, if needed.

h. Create snapshots and versions, if needed.

3. Activate the planning area.

[Link] 5/128
12/3/2020
Check the integrity of the planning area and activate it. This generates the underlying database artifacts. You can activate the planning area with its
dependent time pro le and master data types, or you can activate the time pro le and the master data types rst and then activate the planning area.

 Recommendation

 Note
If you want to change your planning area later, SAP recommends that you create a new entity (for example, an attribute or a time pro le), and use it in
your planning area, instead of changing the existing entity that has already been in use in an active planning area.

4. Load data into the planning area.

Use the Data Integration app to import time pro le data, master data, and key gure data into the planning area.

Related Information
Copying an SAP Sample Planning Area with Create New with Dependencies
Creating Attributes
Creating Simple Master Data Types
Creating Compound Master Data Types
Creating External Master Data Types
Creating Reference Master Data Types
Creating Virtual Master Data Types
Replacing the Time Pro le in a Planning Area
Creating Planning Areas
Creating Planning Levels
Creating Key Figures
Creating a Version
Con guring Original Snapshots
Activating Planning Models
Data Integration Scenarios
Uploading Time Periods
Uploading Master Data
Uploading Key Figure Values

Master Data Types

Master data types represent categories of information, for example, customer, location, product, or resource. You use master data types to segment planning data.
A typical example of their use would be a consumer goods company that wants to understand sales data based on the product, customer, and location master data
types.

Every master data type has one or more attributes, for example, the S2CUSTOMER master data type has S2CUSTID as an attribute.

In the Types of Master Data Types table you can nd a description of the types of master data types available in the system.

 Note
You cannot change the type of an active master data type.

Types of Master Data Types

Type of Master Data Type Description

Simple master data type For example, product, customer or location.

Compound master data type Combines two or more master data types to represent a valid combination of the
component master data types.

For example, you use the product and the customer master data types. As not all
products are sold to all customers, to represent the valid combinations of products
and customers, you create the customer product compound master data type. When
a key gure data containing the keys product ID and customer ID is loaded, the system
checks against the compound master data type for valid combinations, and stores
data only for those.

[Link] 6/128
12/3/2020

Type of Master Data Type Description

Reference master data type References another master data type so that you do not have to upload the same data
more than once. For example, you can create the currency master data type as a
reference master data type that uses the currency to master data type.

 Note
You cannot load data into a reference master data type.

External master data type Makes it possible for SAP Integrated Business Planning to handle and integrate
master data when the content comes from an external database. Before you can use
the external master data types, the database tables they retrieve their content from
have to be integrated from SAP ERP to SAP HANA database tables inside SAP
Integrated Business Planning. When you set up your planning model, you de ne an
external master data type referring to a table that contains the prede ned content.
The integration runs in batch mode, so the external master data entries are updated
on a regular basis from SAP ERP according to your set preferences. There is no need
for manual data upload.

 Note
You cannot load data into an external master data type.

Virtual master data type Enables you to create joins between two or more master data types that otherwise
have no connection to each other. The join conditions you de ne between these
referenced master data types determine the set of data the virtual master data type
uses. By combining master data types this way, you can avoid the duplication of data
in your database.

 Note
You cannot load data into a virtual master data type. Make sure you load data into
the referenced master data types that the virtual master data type is based on.

Related Information
Creating Simple Master Data Types
Creating Compound Master Data Types
Creating External Master Data Types
Creating Reference Master Data Types
Creating Virtual Master Data Types

Description Attributes

When you de ne a master data type, you can link a description attribute to its corresponding ID attribute. This can be bene cial for the performance of the IBP
Excel add-in. When you link the description and ID attributes, during logon, the IBP Excel add-in downloads the master data of one attribute for both the ID and the
description, instead of two separate attributes. This reduces the data volume in the IBP Excel add-in. After you have linked them in con guration, both the
description and ID attributes are displayed in the IBP Excel add-in, but not in all other apps in SAP Integrated Business Planning.

 Caution
If you have linked the description and ID attributes in con guration, you will not be able to use the dynamic selection logic for master data attribute values in the
IBP Excel add-in. For more information about the dynamic selection of master data attribute values, see Dynamic Selection of Values of Master Data Attributes
in the application help.

Copy Options for Master Data Types

Copy options enable you to create an exact copy of a master data type, combine two master data types, or overwrite a master data type with a different one.

You can copy sample master data types and non-sample master data types with the copy options available in the system. When you copy the sample master data
types, their attributes are automatically copied if they haven't been copied yet. If the attributes already exist, you can update them using the Update Attributes
option. When the system updates the attributes in the target master data type based on the attributes in the source master data type, the rules for changing an
attribute are applied. For more information about changing attributes, see Editing Attributes.

The system does not copy the attributes assigned to the master data type when you copy non-sample master data types.

The following three options are available to copy master data types:

Create New

[Link] 7/128
12/3/2020
You can create a master data type that contains exactly the same con guration as the source with a new ID.

Merge with Existing

You can create a combination of the con guration available in two master data types, that is, keep all the con guration in the target master data type and
add everything new from the source master data type. The resulting master data type has the ID of the target master data type and the name and
description of the source master data type. The source and the target master data types must be of the same type and the target master data type must be
active.

Replace Existing

You can create an exact copy of the source master data type in an existing target master data type, that is, delete con guration in the target master data
type that is not included in the source master data type, add new con guration from the source master data type, and update existing con guration in the
target master data type based on the source master data type. The resulting master data type has the ID of the target master data type and the name and
description of the source master data type. The source and the target master data types must be of the same type and the target master data type must be
active.

When you copy a sample or a non-sample master data type, checks are run on the target master data type. These checks are the same as the ones that you can run
on any master data type using the Check button in the Master Data Types app. If all checks are successful or end with warning messages, the target master data
type is created. You are noti ed if the checks fail, but you can still continue and copy the master data type. The enhanced log tells you what went wrong during the
checks.

Creating Simple Master Data Types

Use the Master Data Types app to create simple master data types.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Procedure
1. In the Master Data Types app, choose New and then Simple.

2. On the New Simple Master Data Type screen, provide the details for the simple master data type.

 Recommendation
SAP recommends that you de ne a two-letter or three-letter pre x for the IDs of the master data types; for example, ABC or XYZ (as in ABCPRODUCT or
XYZPRODUCT). One suggestion could be to use your company's ticker symbol as a pre x. The sample planning areas delivered with SAP Integrated
Business Planning use the IBP pre x in the master data type IDs.

To create the product master data type, you could enter the following:

ID: S2PRODUCT

Name: Product

Description: Product

3. In the Assigned Attributes screen area, add at least one attribute to your master data type.

 Note
If you haven't already created the attributes, you can do so here by clicking New.

You could add attributes like product ID (S2PRDID) and product description (S2PRDDESC).

 Caution
To run the inventory operators and time-series-based supply planning algorithms, you have to use speci c technical IDs de ned by SAP for the relevant
master data types and also for attributes and key gures. For demand sensing, the same applies to certain master data attributes and key gures for
which a business meaning has not been speci ed. For more information, see the documentation of the relevant planning operator in this guide and the
respective chapter of the application help.

4. Specify at least one key attribute for the master data type.

Select the Key checkbox for S2PRDID.

5. Optional: Specify attributes as personal data by selecting the corresponding Personal Data checkbox.

 Caution
Do not use this feature to track general changes to master data because this may lead to performance problems.

[Link] 8/128
12/3/2020
6. Optional: Link the description attribute to the corresponding ID attribute using the Description Attribute eld.

Select S2PRDDESC as description attribute for S2PRDID.

7. Optional: De ne an attribute check for the master data type.

8. Save your entries.

Next Steps
Activate your master data type.

Related Information
Creating Attributes
Master Data Type Con gurations
Creating Attribute Checks
Master Data Types
Description Attributes
Tracking Changes to Personal Master Data

Creating Attribute Checks

Use the Master Data Types app to create attribute checks.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

To use the example described in this section, make sure you have created the S2PRODUCT and S2PRODUCTFAMILY master data types in your system. You can
also work with your own master data types.

Context
You want to make sure that the master data that you upload to your system belongs to a speci c set.

Procedure
1. Open the Master Data Types app.

2. Find the master data type that you want to de ne the attribute check for and open it for editing.

Open the S2PRODUCT master data type.

3. Go to the Attribute Checks screen area and turn on attribute checks.

4. De ne a new attribute check.

De ne the attribute check as follows:

Check Master Data Type: S2PRODUCTFAMILY

Check Attribute: S2PRDFAMILY

Assigned Attribute: S2PRDFAMILY

You can de ne one or more attribute checks for a particular master data type using several attributes from the same check master data type or attributes
from different check master data types.

5. Save the attribute check.

6. Save the master data type.

Results
Now you have an attribute check that checks whether the values of the S2PRDFAMILY attribute in the S2PRODUCT master data type match the values of the
S2PRDFAMILY attribute in the S2PRODUCTFAMILY master data type. When you upload data for the S2PRODUCT master data type, the system will reject any
data records that do not meet this requirement.

Next Steps
Activate the master data type and upload data for it.

[Link] 9/128
12/3/2020
Related Information
Creating Simple Master Data Types
Master Data Type Con gurations
Attribute Checks

Creating Compound Master Data Types

Use the Master Data Types app to create compound master data types.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure you have created the master data types you want to add as components.

Procedure
1. In the Master Data Types app, choose New and then Compound.

2. On the New Compound Master Data Type screen, enter the details for the compound master data type.

To create the customer product master data type, you could enter the following:

ID: S2CUSTOMERPRODUCT

Name: Customer Product

Description: Customer Product

3. Add at least two master data types as components.

You can specify simple, compound, reference, and external master data types as component master data types. Also, make sure that the status of the
master data type you select is active or inactive.

For the S2CUSTOMERPRODUCT compound master data type, add S2CUSTOMER and S2PRODUCT.

The key attributes of the component master data types you selected are automatically added as key attributes under Assigned Attributes.

 Note
A decimal attribute cannot be a key attribute in a compound master data type. If a decimal attribute is added, the Key checkbox will be automatically
deselected and inactive.

4. Optional: Assign more attributes to the compound master data type.

Add S2CUSTDESC and S2PRODDESC.

5. Optional: Specify attributes as personal data by selecting the corresponding Personal Data checkbox.

 Caution
Do not use this feature to track general changes to master data because this may lead to performance problems.

6. Optional: Link the description attribute to the corresponding ID attribute using the Description Attribute eld.

Select S2PRDDESC as description attribute for S2PRDID.

7. Optional: De ne an attribute check for the master data type.

8. Save your entries.

Next Steps
Activate your master data type.

Related Information
Creating Attributes
Creating Simple Master Data Types
Creating Attribute Checks
Description Attributes
Master Data Types
Tracking Changes to Personal Master Data

[Link] 10/128
12/3/2020

Creating External Master Data Types

Use the Master Data Types app to create external master data types.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure your SAP Integrated Business Planning system has been integrated with the system you would like to provide master data for your external master data
types, for example, SAP ERP.

Procedure
1. In the Master Data Types app, choose New and then External.

2. On the New External Master Data Type screen, provide the details for the external master data type.

To create the location external master data type, you could enter the following:

ID: S2LOCATIONEXT

Name: Location External

Description: Location External

3. Specify an external data source.

Select SMD_LOC from the External Data Sources list.

4. Specify an integration pro le for the master data type.

Use the default integration pro le that SAP delivers.

5. Add at least one attribute to your master data type.

Add the following attributes:

Location ID (S2LOCID)

Location Description (S2LOCDESC)

Location Type (S2LOCTYPE)

6. Assign the attributes to the corresponding data source columns using the Referenced Column.

Make sure to use all key columns of the external data source as referenced column. The data type of the assigned attribute and the column of the external
data source you specify as referenced column for this assigned attribute must be compatible with each other.

Specify LOCATION_NUMBER as referenced column for the S2LOCID assigned attribute. For S2LOCTYPE specify LOCATION_TYPE_CODE as referenced
column. For S2LOCDESC add LOCATION_DESCRIPTION.

The Key checkbox is automatically selected for S2LOCID and S2LOCTYPE.

7. Optional: Link the description attribute to the corresponding ID attribute using the Description Attribute eld.

Select S2LOCDESC as a description attribute for S2LOCID.

8. Save your entries.

Related Information
Creating Attributes
Master Data Types
Description Attributes
Separation of Data with Integration Pro les

Creating Reference Master Data Types

Use the Master Data Types app to create reference master data types.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure you have created the master data type you want to use in your reference master data type.

[Link] 11/128
12/3/2020
Procedure
1. In the Master Data Types app, choose New and then Reference.

2. On the New Reference Master Data Type screen, provide the details for the reference master data type.

To create the currency to master data type, you could enter the following:

ID: S2CURRENCYTO

Name: Currency To

Description: Currency To

3. Specify a referenced master data type.

You can specify a simple, a compound or an external master data type as a referenced master data type. Also, make sure that the status of the master data
type you select is active or inactive.

You could create and select the S2CURRENCY master data type here.

The attributes of the selected referenced master data type are automatically listed in the Referenced Attributes section.

4. Select the attributes you want to assign to the master data type.

Add the Currency To ID (S2CURRTOID) and Currency To Description (S2CURRTODESC) attributes.

5. Specify a referenced attribute for each assigned attribute.

Make sure that the assigned attribute and the referenced attribute have the same data type, and that the length of the assigned attribute is greater than or
equal to the length of the referenced attribute.

Specify S2CURRID as a referenced attribute of S2CURRTOID and S2CURRDESC as a referenced attribute of S2CURRTODESC.

6. Optional: Link the description attribute to the corresponding ID attribute using the Description Attribute eld.

Select S2CURRTODESC as a description attribute for S2CURRTOID.

7. Save your entries.

Related Information
Creating Attributes
Creating Simple Master Data Types
Master Data Types
Description Attributes

Creating Virtual Master Data Types

Use the Master Data Types app to create virtual master data types.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure you have created the master data types you want to use in your virtual master data type.

Context
Virtual master data types set up references to data in other master data types by creating join conditions. They enable you to use data available in the referenced
master data types so you can avoid loading the same set of data into your database multiple times.

Procedure
1. In the Master Data Types app, choose New and then Virtual.

2. On the New Virtual Master Data Type screen, provide the details for the virtual master data type.

To create the S2SALESHDRITEMPRODLOC master data type, you could enter the following:

ID: S2SALESHDRITEMPRODLOC

Name: Virtual Sales Order Item

Description: Virtual Sales Order Item

3. Add at least two referenced master data types.

[Link] 12/128
12/3/2020
You can specify simple, compound, reference, and external master data types as referenced master data types. Also make sure that the status of the master
data type you select is active or inactive.

The system automatically adds the key attributes of the master data types you added as referenced master data types in the Assigned Attributes section.

4. In the Add Join Condition dialog, de ne at least one join condition as shown in the example below.

Master Data Types Attributes Master Data Types Attributes

S2SALESORDERITEM S2SALESDOC Equals S2SALESORDERHDR S2SALESDOC

Make sure to use every referenced master data type in a join condition and make sure that the join conditions form a chain. You need at least two referenced
master data types and one join condition.

5. Optional: Under Assigned Attributes, you may change the values of the Referenced Attribute and Referenced Master Data Type elds or assign more
attributes and de ne the referenced attribute and referenced master data type for the attributes you added.

6. Save your entries.

Example
The following example, based on sample master data types, illustrates the use of virtual master data types.

SAP delivers sample master data types including the following:

IBPSCHEDULELINES (Schedule Line)

IBPSALESORDER (Sales Order)

IBPSALESORDERITEM (Sales Order Item)

IBPSALESORDERHEADER (Sales Order Header)

IBPPRODUCT (Product)

IBPLOCATION (Location)

Without using a virtual master data type, a key gure calculation at schedule line level would require that you upload data for each of the following attributes one by
one:

SCHLINE (Schedule Line Number)

SALESITEM (Sales Order Item)

SALESDOC (Sales Order)

PRODID (Product ID)

LOCID (Location ID)

However, the set of data required is in fact available through upload for other master data types, without the need to upload it again for SCHEDULELINES. The data
is in fact de ned by the key attributes of the SCHEDULELINES master data type along with the other master data types listed above, as follows:

SALESDOC and SALESITEM within the SCHEDULELINES master data type are also key attributes of the IBPSALESORDERITEM master data type (while
SALESDOC is also a key attribute of IBPSALESORDERHEADER).

The IBPSALESORDERITEM master data type in turn contains the LOCID and PRODID attributes as non-key attributes, which are available in the IBPLOCATION
and the IBPPRODUCT master data types as key attributes.

The virtual master data types IBPVSALESHDRITEMSCHLPRODLOC (Virtual Schedule Lines) and IBPVSALESHDRITEMPRODLOC (Virtual Sales Order Item) set
up the very references described above in the form of join conditions as shown in the tables below:

IBPVSALESHDRITEMSCHLPRODLOC (Virtual Schedule Lines)

Master Data Types Attributes Master Data Types Attributes

IBPSALESORDERITEM LOCID Equals IBPLOCATION LOCID

IBPSALESORDERITEM PRODID Equals IBPPRODUCT PRODID

IBPSALESORDERITEM SALESDOC Equals IBPSALESORDERHDR SALESDOC

IBPSCHEDULELINES SALESDOC Equals IBPSALESORDERITEM SALESDOC

IBPSCHEDULELINES SALESITEM Equals IBPSALESORDERITEM SALESITEM

IBPVSALESHDRITEMPRODLOC (Virtual Sales Order Item)

[Link] 13/128
12/3/2020

Master Data Types Attributes Master Data Types Attributes

IBPSALESORDERITEM LOCID Equals IBPLOCATION LOCID

IBPSALESORDERITEM PRODID Equals IBPPRODUCT PRODID

IBPSALESORDERITEM SALESDOC Equals IBPSALESORDERHDR SALESDOC

Related Information
Creating Attributes
Creating Simple Master Data Types
Master Data Types

Master Data Type Con gurations

Speci c settings for creating simple master data types.

Simple Master Data Type Configurations

ID Name Assigned Attributes Key

S2CURRENCY Currency S2CURRID S2CURRID

S2CURRDESC

S2CUSTOMER Customer S2CUSTID S2CUSTID

S2CUSTDESC

S2LOCATION Location S2LOCID S2LOCID

S2LOCDESC

S2PRODUCT Product S2PRDID S2PRDID

S2PRDDESC

S2PRDFAMILY

S2PRODUCTFAMILY Product Family S2PRDFAMILY S2PRDFAMILY

S2PRDFAMILYDESCR

S2SALESORDERITEM Sales Order Item S2SALESDOC S2SALESDOC

S2SALESITEM S2SALESITEM

S2LOCID

S2PRDID

S2ORDERQTY

S2SALESORDERHDR Sales Order Header S2SALESDOC S2SALESDOC

S2DISCTCHANNEL

Related Information
Creating Simple Master Data Types
Master Data Types

Change of a Master Data Type

You may want to change a master data type. However, you'll nd that not all elds of a master data type are available for editing. The changes you can do depend on
the following factors:

If the status of the master data type is active or inactive

If the master data type is assigned to planning areas, or used in other master data types, or not

If data has already been uploaded for the master data type

 Note
You can change any parameter (except for its ID) of a master data type that you have never activated (that is, only an inactive instance of the master data type
exists). You can also delete the master data type.

[Link] 14/128
12/3/2020
If a master data type has already been activated (even if it currently has an inactive instance), certain rules apply for what changes you can make.

General Data
You can change the name and the description of a master data type any time.

Once you activated a reference master data type, you can’t change the master data type your reference master data type is built on.

Once you activated an external master data type, or used it in a planning area, you can’t change its external data source.

Type
You can change the type of an inactive master data type as follows:

Change the type of a simple or compound master data type to external

Change the type of an external master data type to simple or compound

Once you have activated the master data type, you can no longer change its type.

Component and Referenced Master Data Types

A compound master data type must have at least two components. A virtual master data type must have at least two referenced master data types.

If you add or remove components, you must re ect the changes in the set of the key attributes of the compound master data type as well.

In case master data records exists for a compound master data type, you can’t add or remove components. You can add referenced master data types to or remove
them from a virtual master data type even if data exists for the components.

Assignment of Attributes to Master Data Types

Adding Additional Attributes to a Master Data Type

You can add additional attributes to a master data type. If you want to use the newly added attribute in a planning area or in a master data type built on the master
data type you changed, you must select it explicitly for the planning area, or for the master data type. Given they were already active, you must activate the master
data type and all other entities that use the changed master data type (planning areas, other master data types) for the changes to take effect.

If master data records already existed for the master data type you added an attribute to, the already existing records of the changed master data type will have an
empty value for the new attribute. You can decide to upload the master data, enriched with the new attribute, again.

Removing Attributes from a Master Data Type

You can’t remove all attributes from a master data type. A master data type must have at least one attribute assigned.

You can’t remove an attribute from a master data type if the attribute is used in a planning area, or in a master data type that is built on the master data type you
want to change.

 Caution
If you remove an attribute from a master data type, the already existing data for this attribute is deleted from the master data records.

Other master data types that use the same attribute are not affected.

Key Attributes

In case of a simple master data type, you can specify additional attributes as key attributes. However, if master data records already existed for the master data
type before you set an additional attribute to key, the attribute cannot be empty in any of the master data records.

The master data type must have at least one key attribute. You can change a key attribute to a non-key attribute if the remaining key combination still has only
unique values for all existing master data records.

Compound master data types contain all key attributes of the component master data types, and cannot have any other key attributes. The component master
data types cannot have the same key attributes. If you change the key attributes in a component of a compound master data type, you must update the keys of the
compound master data type as well.

A virtual master data type doesn’t have key attributes.

[Link] 15/128
12/3/2020
Reference master data types must use all key attributes of the referenced master data type as key. Each key attribute of the referenced master data type must be
used as a referenced attribute in the reference master data type that is built on it.

If you change the key attribute of the master data type the reference master data type is built on, you must update the key of the reference master data type as well.

An external master data type must contain all the keys of the external data source.

You must activate the master data type and all other entities that use the master data type (planning areas, other master data types) for the changes to take effect.

Required Attributes

Each key attribute of a master data type is a required attribute. You can specify additional attributes as required, or you can change a non-key required attribute to
not required at any time. However, if master data records already existed for the master data type when you set an additional attribute to required, make sure that
the master data records for this attribute do not contain empty or null values.

When creating master data, you need to provide values for the required attributes, but you don’t need to provide them when you update or delete master data.

You must activate the master data type for the changes to take effect.

Personal Data

You can de ne attributes of simple and compound master data types as personal data. To do this, you need to select the Personal Data checkbox for the
corresponding attribute. After that, you must activate the master data type so that the changes take effect.

 Caution
Do not use this feature to track general changes to a master data type because this may lead to performance problems.

Related Information
Tracking Changes to Personal Master Data

Deleting a Master Data Type

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
If a master data type is not assigned to any other model entity, and has never been activated, you can delete it.

You must work top down to remove the master data type you want to delete from each model entity that uses it if any of the following applies:

The master data type is assigned to a planning area.

The master data type is used as a component in a compound master data type, or in a virtual master data type.

The master data type is used as a reference in a reference master data type.

Procedure
1. If a master data type to be deleted is used in a planning area, delete the master data type from the planning area by marking it for deletion, then activate the
planning area.

Repeat this for all planning areas where the master data type is used.

2. If a master data type to be deleted is used in a compound master data type, delete it from the compound master data type. Activate the compound master
data type.

 Note
You can delete a component from a compound master data type only if no data exists for the compound master data type.

Repeat this for all compound master data types where the master data type to be deleted is used.

3. If a master data type to be deleted is used in a virtual master data type, delete it from the virtual master data type. Activate the virtual master data type.

Repeat this for all virtual master data types where the master data type to be deleted is used.

4. If a master data type to be deleted is used in a reference master data type, delete the reference master data type by using active deletion.

[Link] 16/128
12/3/2020

 Note
You can delete a reference master data type only if it is not used in any higher-level entities, such as a planning area, or other master data types. Before
deletion, you must delete it from all planning areas and master data types.

5. Now use active deletion to delete the master data type you originally wanted to delete.

Tracking Changes to Personal Master Data

If your company stores master data records that contain personal data, changes to this data can be tracked, viewed, and downloaded if required.

To use this feature, you rst need to de ne the corresponding attributes as personal data in the Master Data Types app. You can de ne this setting for both simple
and compound master data types. To do this, you need to select the Personal Data checkbox and activate the master data type. You can change this setting at any
time.

The changes will be stored in the system for 90 days. You can change this retention time using the PERSONAL_DATA_CHANGE_LOG_AGE global con guration
parameter.

 Caution
Do not use this feature to track general changes to master data because this may lead to performance problems.

You can view and download changes to personal data in the View Personal Master Data Changes app.

Related Information
View Personal Master Data Changes
Creating Simple Master Data Types
Creating Compound Master Data Types
Change of a Master Data Type

Time Pro les and Time Periods

Time Pro les de ne a time interval used for managing planning data.

A time pro le is made up of time pro le levels (for example, months, quarters, or years). Each level is made up of periods, which are identi ed by a number, and
describe the start and end time of the time period in question.

If you want to perform aggregation or disaggregation along time, then the periods on different levels need to form a hierarchy. In this hierarchy, time pro le levels
can have multiple parents, and there can be time pro le levels without a parent level. For more information about setting up your planning model for aggregating
and disaggregating data across different time levels, see Con guring Aggregation and Disaggregation of Data Across Different Time Pro le Levels.

 Example

[Link] 17/128
12/3/2020

Time Periods for a Time Profile with 6 Time Levels

The sample models delivered with IBP also provide time pro le de nitions. Launch the Sample Model Entities app to see the time pro les delivered with SAP
Integrated Business Planning. You can either copy one of these time pro les or create one from scratch in the Time Pro les app.

After creating and activating a time pro le, you must load a time pro le data le, or schedule an application job to create the time periods.

PERIODID and PERIODID(n) Attributes in Time Pro le Levels

The PERIODID and PERIODID(n) attributes are technical attributes. The PERIODID(n) attribute is the hierarchy level ID for the time period. The PERIODID
attribute identi es a speci c time period, and not a time pro le level. For example, 25503 is the PERIODID for May 2016 as a time period, and 25504 for June
2016. You won't nd these attributes in the Time Pro les app, but you may need them when de ning calculations for key gures or attribute transformations.

The assignment of PERIODID(n) attributes varies according to the time pro le ID and levels that have been de ned. PERIODID0 represents the lowest time
pro le level. If the time pro le has multiple time pro le levels, then PERIODID1 represents the highest level. The next PERIODID(n) value represents the next
highest time pro le level.

For example, if a time pro le is de ned with the levels "Day", "Technical Week", "Week", "Month", and "Year", the assignment is as follows:

PERIODID0: Daily periods

PERIODID1: Yearly periods

PERIODID2: Monthly periods

PERIODID3: Weekly periods

PERIODID4: Technical weekly periods

Creating Time Pro les

Use the Time Pro les app to create time pro les.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Procedure
[Link] 18/128
12/3/2020
1. In the Time Pro les app, choose New.

2. In the Select Time Pro le Levels dialog, choose the time pro le levels for your time pro le. For example, select all the available levels and choose OK.

The time pro le levels that you selected are created and pre lled. If you don't want the system to automatically create time pro le levels for your time
pro le, choose OK without selecting any levels.

 Note
If you select the time pro le levels, that is, they are created automatically from a template, you can't change the base level of any time pro le level, you
can only extend the time pro le with a less granular time pro le level. If you want to use a custom structure for the time pro le, create one from scratch.

3. On the New Time Pro le screen, provide the details for the time pro le.

Enter a positive integer as ID.

Make sure that the time pro le levels form a sequence based on the period type. For example, a time pro le level that has the period type “day” must come
before the one that has “month”, and “month” must come before “quarter”.

 Note
Day and calendar week refer to the Gregorian calendar.

The default display horizon that you set for a time pro le level determines the default time period that is preselected for the relevant time pro le level under
Time Settings when you create a new planning view or edit an existing planning view in the SAP Integrated Business Planning, add-in for Microsoft Excel
(SAP IBP, add-in for Microsoft Excel). The values in the default display horizon elds are relative to the current period. For example, if the current period is
May 2020, and you set 0 for Default Display Horizon in the Past, and 6 for Default Display Horizon in the Future, then on the Time Settings tab of the
Create New Planning View screen of the Excel add-in, the preselected values for monthly periods are May 2020 in the From eld and November 2020 in the
To eld.

4. Optional: Assign attributes to the time pro le levels.

 Note
You can assign any attribute to a time pro le level, except for attributes with decimal data type.

If the External Time Series checkbox is selected for your planning area, do not assign an attribute that has DATE as an ID to a time pro le level because
it will not be propagated to the calculation scenarios.

5. Save your entries.

Options for Creating Time Periods

A time period is a speci c instance of a time pro le level, which is identi ed by a number and has a start date and an end date.

Time periods are generated for days, (technical) weeks, months, quarters, and years. The start and end dates for the time periods are taken from the selected time
pro le. The following gure illustrates how technical weeks work:

Grouping of Days into Technical Weeks

You have three options to create time periods once you have an active time pro le:

You can generate time periods using an application job in the Application Jobs app.

You can download a template with time periods in the Data Integration Jobs app and then upload them from the comma-separated values (CSV) le.

You can upload time periods from SAP Cloud Platform Integration for data services.

 Recommendation

[Link] 19/128
12/3/2020
Use the data integration jobs and SAP Cloud Platform Integration for data services options if you are working with complex time pro les, that is, time pro les
that contain time pro le levels of the custom period type, or if you have assigned attributes to time pro le levels.

Related Information
Creating Time Periods with an Application Job
Creating Time Periods from a Template

Creating Time Periods from a Template

You can create time periods from templates in the Data Integration Jobs app.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
We recommend that you use this option because in the comma-separated values (CSV) le, you can modify the period description if needed, and if you use time
pro le attributes, you can ll the attributes with data before loading the time periods for the time pro le into the system.

Procedure
1. In the Data Integration Jobs app, click Download Template.

2. Select Time Periods as the data type.

3. Select the time pro le from the dropdown list and specify whether you want to pre ll the template with new or existing time periods.

If you leave the Pre ll Template dropdown blank, the template doesn’t contain any time pro les.

If you select With New Time Periods, the template contains the time periods in accordance with the value in the Time Pro le eld. Note that if
periods already exist, this option is grayed out.

If you select With Existing Time Periods, the template contains time periods that already exist in the system for the time pro le, for example,
because they have been uploaded at a previous point in time.

4. Click Download.

Results
A le is generated for you to use as a template with the correct, comma separated headers for your data type. You can now ll out the template with the correct
values, save it, and use it to upload data to the system.

 Note
Before uploading time periods using a template that is pre lled with existing time periods, make sure that the numbering in time period descriptions of weeks
and technical weeks are correct. For more information, see Uploading Time Periods.

Next Steps
Upload the time periods.

Related Information
Uploading Time Periods

Creating Time Periods with an Application Job

Use the Application Jobs app to generate time periods for the selected time pro le.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

You have activated the time pro le for which you want to create time periods.

[Link] 20/128
12/3/2020

 Tip
Application jobs create generated descriptions for time periods. You can modify time period descriptions using the Data Integration Jobs app by downloading
the template for time pro les pre lled with existing time periods, editing the descriptions, and uploading the data. For more information, see Uploading Time
Periods.

Procedure
1. Open the Application Jobs app.

2. Create a new application job.

3. Select the Create Time Periods for Time Pro le template.

4. Optional: Set the scheduling options for your job.

5. Provide the Time Pro le ID for which you want to create the time periods.

6. Choose Schedule.

Next Steps
Find your job in the list of application jobs to check the status of your job. When your job has nished, you can also see the related log messages.

Change and Deletion of Time Pro les

You may want to change a time pro le. However, you’ll nd that not all elds on the time pro le screen are available for editing. The changes you can do depend on
the following factors:

If the status of the time pro le is active or inactive

If the time pro le is assigned to planning areas or not

If time periods have already been created for the time pro le

 Note
If you have created and saved a time pro le, but have not activated it yet (that is, only an inactive instance of the time pro le exists), you can change any
parameters of the time pro le. You can also delete the time pro le.

If a time pro le has already been activated (even if it currently has an inactive instance), certain rules apply regarding the elds or parameters that you can change
or delete.

Changing a Time Pro le

Description

You can change the description of a time pro le at any time.

Start Date and End Date

If the time pro le is not used in any planning area, you can change its start date and end date at any time.

You have to activate the time pro le for the changes to take effect.

 Note
If changing the start and end date of the time pro le extends its entire validity period, in other words, if the new start date is earlier than the old start date or the
new end date is later than the old end date, no time periods will exist for these parts of the time pro le. In this case, create the missing time periods by uploading
them or by using the application job for creating time periods.

 Caution
If the time pro le is already used in a planning area and transactional data exists, changing the time pro le dates is not recommended as it may cause issues.

 Recommendation
We recommend that you de ne the start and end date of the time pro le in such a way that no changes to the dates are needed. For example, de ne the end
date many years in the future.

Time Pro le Levels

[Link] 21/128
12/3/2020
You can’t delete time pro le levels.

You can change the base level, the period type, and the default display horizon of time pro le levels.

If time periods already exist for the time pro le, even if the time pro le isn’t assigned to any planning areas, and you add a new time pro le level, you’ll have to
upload the time periods again.

If the time pro le is already assigned to a planning area, you can’t add new time pro le levels.

You have to activate the time pro le for the changes to take effect.

Attributes Assigned to Time Pro le Levels

You can assign additional attributes to a time pro le level at any time. You can assign an attribute to one time pro le level only. If you have assigned an attribute to a
planning area, you can't assign the same attribute to a time pro le level.

To set an attribute to required, you must have data uploaded for the attribute for each time period. You can activate the time pro le only if all time periods are
uploaded with a value for this attribute (empty values are not allowed).

If time periods already exist for a time pro le, you can add a new required attribute in two steps. First, assign the attribute to the time pro le level without setting it
to required. Activate the time pro le, then upload the time periods with this attribute lled out. Make sure that you don’t change any other data for the already
existing time periods. As the last step, in the time pro le de nition, mark the attribute as required.

You can remove an assigned attribute from a time pro le level only if the given attribute is not used in any planning levels.

You have to activate the time pro le for the changes to take effect.

Deleting a Time Pro le

You can delete a time pro le only if it is not assigned to any planning areas. You delete an active time pro le in two steps. First, when you delete the active time
pro le, the system creates a new instance of the time pro le, which has the pending deletion status. When you activate the time pro le, the system carries out the
deletion: both instances (active and pending deletion) are deleted.

If you delete a time pro le, the time periods that belong to the given time pro le are deleted as well.

Con guring Aggregation and Disaggregation of Data Across Different Time Pro le Levels
Several applications of SAP Integrated Business Planning, which work with different time pro le levels and time horizons, may use the same planning area.
Therefore, the values of the common key gures must be aggregated and disaggregated across different time levels.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Your time pro le includes a time pro le level with technical week period type. This time pro le level is the base level of the time pro le levels with week and month
period type.

Context
The aggregation and disaggregation of data across different time levels can be realized by a speci c modeling concept, which is built on the modeling of time pro le
levels with multiple parents and that of intermediate levels without parents. If you apply this “week-to-months split” modeling concept after weeks and months
have been aggregated, you can aggregate and disaggregate key gure values across different time levels.

 Note
You can also apply this modeling concept for aggregation and disaggregation between custom overlapping periods. Use the custom (empty value) period type to
de ne such a time pro le. Make sure to model the relationships between the time pro le levels using the Base Level eld.

Procedure
1. De ne the period weight factor attribute.

In the Attributes app, de ne one or more attributes that represent the period weight factor. Typically, the number of workdays or calendar days is used as
the period weight.

Specify INTEGER as the data type of the attribute.

2. Assign the period weight factor attribute you created to the technical week level of the selected time pro le.

[Link] 22/128
12/3/2020
You can assign an attribute to the time pro le level of the selected time pro le in the Time Pro les app.

3. Activate your time pro le.

You can activate your time pro le in the Time Pro les app.

4. Upload time periods with period weight factors into the time pro le.

Use the Data Integration app to get a CSV le template for the time pro le. Fill out the template with the data of the time periods, including the period
weight factors, then upload the le to create the time periods.

 Note
If you apply the week-to-months split modeling concept, you have to use either the Data Integration app or the SAP Cloud Platform Integration for data
services to create the time periods. If you create the time periods by scheduling an application job, they will lack the period weight factors. This can result
in inaccurate aggregation and disaggregation between different time pro le levels.

5. Assign the period weight factor attribute to the relevant planning levels.

If you want to read and write key gure values in both (calendar) weeks and months, select the technical week time pro le level as the root in the base
planning levels used in the given key gures. Also assign the period weight factor to the base planning level of the key gure. You do this on the Planning
Levels tab in the Planning Areas app.

6. Assign the period weight factor attribute to the relevant key gures.

You must specify the period weight factor for each key gure whose values you would like to access in both weeks and months. To do this, go to the Key
Figures tab in the Planning Areas app, and select the attribute you created for the period weight factor.

 Note
You can assign a period weight factor to a key gure only if the disaggregation mode of the key gure is Equal with or without proportional disaggregation
de ned.

If you store key gures at technical week level, but you want to run forecast at calendar week level, then you must have at least one stored key gure at
calendar week level.

7. Activate the planning area for your changes to take effect.

Planning Areas

A planning area is a model entity that de nes the structure and forms the backbone of the planning process. A planning area consists of its assigned time pro le,
attributes of master data types, planning levels, key gures, and versions. You could compare this to SAP APO or SAP ERP, where tables, table values, and
con guration are de ned to support the planning process.

Planning areas can contain multiple planning data sets, that is, a base version data set and additional version data sets. The versions are for alternative plans for all
or part of what is in the base version and need to be con gured and activated. Versions can share master data with the base version or can be based on
independent sets of version-speci c master data. Scenarios de ned by users also exist, which lie on top of the versions (including the base version).

A company can have multiple planning areas to enable the processes of SAP Integrated Business Planning in different business units.

 Note
As you can use the SAP Integrated Business Planning, add-in for Microsoft Excel for only one planning area at a time, there are limitations to this use case.

Separate planning areas are also used for con guration work to separate on-going con guration activities from end-user testing, for example, or to separate the
work from different project phases. See Best Practices for Transporting Planning Models.

A planning area consists of the following settings and model entities:

Name, for example, ABC

Description, for example,: ABC’s planning area

Time Pro le: time pro le ID (160)

Storage Time Pro le Level (for example, weekly or monthly)

Planning horizon

List of selected attributes, and the master data types they originate from, for example:

Attribute Master Data Type

CUSTTYPE CUSTOMER

LOCTYPE LOCATION

[Link] 23/128
12/3/2020

Attribute Master Data Type

PRDID PRODUCT

PRDDESC PRODUCT

MKTSGMNT CUSTOMERPRODUCT

CMPNTID COMPONENT

Planning levels

Key gures

Versions (optional)

Assigned planning operators (optional)

Additional parameters, such as the enablement of the planning area for supply planning or for change history

Using Multiple Planning Areas

Planning areas are used to model the complete planning process in a company. Considering the different business scenarios and processes, a company might
decide to have several planning areas to care for the various needs and requirements they have. Multiple planning areas can be used for the different business
processes, with the possibility of copying data among them to ensure consistent planning throughout the whole company.

Let's see a couple of uses cases where the usage of multiple planning areas might prove to be bene cial.

Regional Demand Planning Processes

In case you have different regional requirements that would be difficult to model and maintain in a single planning area, you can model the regional demand
planning processes in different planning areas. In addition to that, create a global planning area with demand copied from all regional planning areas. This way, you
can use the global planning area to carry out consensus and supply planning for the entire company.

You might want to create different planning areas for the different regional demand planning process in the following cases:

Different regions have different planning requirements, planning levels, and calculations.

Some regions require a large number of key gures, and have several hundreds of users; while other regions have a small number of key gures, low data
volume, and very few users.

Piloting a New Business Process

In this case, you have an existing productive planning area. However, you would like to extend your business processes to a new area, for example, demand sensing,
without disrupting your productive processes. To do so, you create a separate planning area for your demand sensing processes, and copy the planning data back to
the original planning area regularly. The volume of data required for short term planning in demand sensing is very large. By managing demand sensing processes
in a separate planning area, the performance of the already existing productive planning area will not be affected.

Strategic Long- and Mid-Term Planning

Strategic long-term planning is usually carried out at quarterly or yearly at aggregated levels of the planning hierarchy. The consumers of these plans and planning
areas are typically senior management teams who are responsible for long-term strategic goals. These strategic long-term plans are then broken down to tactical
mid-term plans.

These planning processes and plans can be very different in terms of complexity, user management, consumers and legal requirements. These differences can be
easily handled by using separate planning areas for the different planning processes.

If you want to create management reports and what-if analyses, you can merge the most critical key gures from the different planning areas into a consolidated,
global planning area and run the required reports.

Complexity and Performance

To manage the growing complexity of a uni ed planning area that has several hundreds of key gures and deals with large volumes of data, you might want to split
planning processes into separate planning areas. Also, your planning processes might be very different; some of them might require only a small set of data and key
gures, whereas, others might deal with large volumes of data.

To manage complexity and improve performance, you can split such a complex planning area into separate planning areas.

Also, you can evaluate new features in a separate planning area without disrupting the planning areas that are used in a productive environment.

[Link] 24/128
12/3/2020
Order-Based Planning
You might want to use one planning area for order-based planning processes, and another one for long- and mid-term time-series-based planning processes.

 Note
Multiple planning areas can share the same master data types; however, it might increase integration time as data is uploaded to several planning areas.

To copy data between planning areas, use the advanced copy operator. For more information, see Copy Operator (Advanced).

Creating Planning Areas

Use the Planning Areas app to create planning areas.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure you have already carried out the following tasks:

You have created a time pro le.

You have created attributes and assigned them to master data types.

Context
You create a planning area to group and structure your model entities, and to con gure which processes of SAP Integrated Business Planning are enabled.

Procedure
1. In the Planning Areas app, choose New.

2. On the Planning Area screen, under General, enter an ID and a description for the planning area.

The planning area ID can:

be up to 10 characters long

contain numbers and letters

only start with a letter

3. Under Planning Area Settings, specify settings for the planning area.

The following settings are available for the planning area:

Planning Area Setting Description

Enable Supply Planning Enables the use of advanced supply planning functions, such as heuristics and
optimizers.

Enable External Time Series Enables the con guration for the usage of external key gures.

Integration Pro le This option is available for planning areas that are enabled for external time series.
Enables you to select an integration pro le.

Enable Change History Enables change history for the planning area.

 Caution
If you select the Enable Change History checkbox, and later decide to deselect
it, the previously recorded change history of the planning area will be deleted
upon the next activation of the planning area.

Enable Change-History-Based Key Figure Calculations Enables operations on historical key gure values that were captured using the
change history, or the shared data tracking feature in business network
collaboration.

4. Under Time Settings, select a time pro le for the planning area.

The settings for Planning Horizons de ne the possible period ranges that you can use for your planning view in the SAP Integrated Business Planning, add-
in for Microsoft Excel (SAP IBP, add-in for Microsoft Excel). The values for the Periods in the Past and the Periods in the Future elds determine the range of
values that you can select for the From and To elds on the Time Settings tab of the Create New Planning View screen.

[Link] 25/128
12/3/2020
The values for the Periods in the Past and Periods in the Future elds are lled automatically based on the selected time pro le. You can change the values,
but you should always make sure that the values do no exceed the start and end dates of the time pro le and that you de ne a broader horizon than the
default display horizon for the time pro le level. The values in the Periods in the Past and Periods in the Future elds are relative to the current period. For
example, if the current period is May 2020, and you set 12 periods in the past and 6 periods in the future, the user can choose to view data from the periods
between May 2019 and November 2020 in the Excel add-in. The user will not be able to view data from periods before or after this horizon, even though this
data might exist in the system.

5. Under Time Settings, change the value of the Current Period Offset.

The current period offset allows you to shift your planning period. For example, -1 means the current period starts from the previous period of the lowest
time pro le level. This means, if, for example, the lowest time pro le is month, the planning period starts from the previous month.

6. Save the planning area.

Next Steps
Assign attributes to the planning area.

Assign planning operators to the planning area.

Related Information
Creating Attributes
Assigning Attributes to a Planning Area
Setting up Change-History-Based Calculations
Creating Planning Levels
Creating Key Figures
Creating a Version
Creating a Planning Operator
Con guring Original Snapshots
Separation of Data with Integration Pro les

Assigning Attributes to a Planning Area

Use the Planning Areas app to assign attributes to a planning area.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

You have created a planning area and attributes.

Procedure
1. In the Planning Areas app, nd the planning area you want to assign attributes to and open it.

2. On the Attributes tab, choose Add.

3. Find the attributes you want to add to the planning area.

The attributes you select here for the planning area will be available for creating planning levels. In SAP Integrated Business Planning, add-in for Microsoft
Excel, you can use the attributes you assigned to a planning area when you create a planning view.

Keep in mind the following:

If you select an attribute in a master data type, you also select and assign the master data type to the planning area. If you select a master data type,
the system automatically selects all attributes that are assigned to that master data type.

If an attribute is assigned to multiple master data types, you can assign the attribute to the planning area only once from one of the master data
types.

If an attribute is assigned to a time pro le level of a time pro le that is assigned to the planning area, the attribute cannot be assigned to the planning
area.

If you assign a compound master data type to a planning area, make sure you also assign its component master data types. Similarly, if you assign a
reference master data type or a virtual master data type to a planning area, assign their referenced master data types as well.

Make sure you do not select the key attributes of a compound master data type. Select the key attributes from its component master data types
instead.

If the ID attribute of a master data type is linked to its description attribute, you only need to include the ID in the planning area. The description is
then included through the link. For more information about linking ID and description attributes, see Description Attributes.

[Link] 26/128
12/3/2020
You cannot assign a decimal attribute to a planning area but you can create an attribute as key gure based on the attribute, which you can assign to
the planning area.

 Remember
Make sure you only add attributes to the planning area that you want to use in planning levels.

4. Make settings for the attributes you added to the planning area.

The following settings are available:

Settings for Planning Area Attributes Description

Planning Area Attribute Description The system lls this eld automatically with the description of the attribute. The
user can change the description in the planning area. The new value is only
available for the attribute in the planning area in which it was changed. This
description is visible in the IBP Excel add-in.

Business Meaning Provides a semantic connection between the attribute ID that you specify and the
code, letting the system know for what purpose you want to use a certain
attribute.

Attribute Category See Validate Master Data for New Planning Objects.

Related Information
Creating Attributes
Creating Planning Areas
Validate Master Data for New Planning Objects
Creating Planning Levels
Creating Key Figures
Creating a Version
Creating a Planning Operator
Con guring Original Snapshots

Planning Area Download

You can download the details of a planning area into comma-separated values (CSV) les.

To download the content of a planning area and its entities, go to the Planning Areas app, select the planning area and choose Download. The content of the
planning area and its entities is downloaded into 10 comma-separated values (CSV) les.

 Note
Make sure you check your browser settings, especially those related to le download and enable the download of multiple les.

A separate le is downloaded with the details of each of the following entities and settings of the planning area:

Key gures

Master data types

Versions

Planning operators

Planning horizons

Attributes

General info

Attributes as key gures

Planning levels

Time pro le

Validate Master Data for New Planning Objects

In the Planning Areas app, on the Attributes tab of the planning area, you can assign an attribute category to a planning area attribute.

[Link] 27/128
12/3/2020
The attribute category speci es whether master data has to exist for the attribute when new planning objects are added in the IBP Excel add-in or during data
integration. By default, all attributes have the category NULL (optional).

Attribute Category Explanation Relevant for Data Integration Relevant for New Planning Objects

Mandatory The attribute value must be found, Yes Yes

although the value itself might be NULL.
Key gure records for which no attribute If no attribute value is found (that is, the
That is, master data records must exist.
value is found (that is, where the master master data records are missing), the
data records are missing) are rejected. planning object is omitted from the new
set of planning objects.

Optional (default value) An attribute value does not have to be Yes Yes
found. That is, master data records don't
No attribute value is found (master data Irrespective of whether an attribute value
necessarily have to exist.
records are missing). The planning level is found (master data records are missing
attribute value is set to NULL, and the key or available), that planning object stays in
gure record(s) are processed for that the set of new planning objects, and
planning object. attribute value is set to found value or
NULL respectively.
Attribute value is found (master data
records are available) The planning level
attribute value is set to fetched value,
and the key gure record(s) are
processed for that planning object.

Calculated The attribute value must be found, No No

although the value itself might be NULL.
That is, master data records must exist.

As this indicator is not relevant for either

data integration or for new planning
objects, select value NULL in both cases.
Values for such attributes will be
calculated using an operator of some
description and must not be overwritten
by data integration.

 Example
The key gures KF1 and KF2 are stored at the MTHLOCPRD (Month-Location-Product) planning level. Month, PRDID, and LOCID are root attributes of the
MTHLOCPRD (Month-Location-Product) planning level. ATTR1 is a non-root attribute of the MTHLOCPRD (Month-Location-Product) planning level. The planning
area contains data for the key gures KF1 and KF2.

The LOCATIONPRODUCT (Location Product) master data type contains the following data:

LOCID PRDID ATTR1

L1 P1

L2 P2

The planning area contains the following attributes:

Attribute Attribute Category Source Master Data Type

PRDID Optional LOCATIONPRODUCT

LOCID Optional LOCATIONPRODUCT

ATTR1 Optional LOCATIONPRODUCT

The MTHPRDLOC (Month-Product-Location) planning level is de ned as follows:

Attribute Root Source Master Data Type

Month Yes -

PRDID Yes LOCATIONPRODUCT

LOCID Yes LOCATIONPRODUCT

ATTR1 No LOCATIONPRODUCT

The planning area contains data for key gures KF1 and KF2 for location-product combinations ( L1- P1), ( L2- P1), and ( L2- P2):

[Link] 28/128
12/3/2020

LOCID PRDID Month KF1 KF2

L1 P1 2017 AUG 100 200

L1 P1 2017 SEP 110 210

L2 P1 2017 AUG 300 400

L2 P1 2017 SEP 310 410

L2 P2 2017 AUG 500 600

L2 P2 2017 SEP 510 610

As long as locations L1 and L2 and products P1 and P2 exist individually in the LOCATIONPRODUCT (Location Product) source master data type, any
combination of them is valid for the MTHLOCPRD (Month-Location-Product) planning level and allowed to exist in the planning area.

Then, the planning area con guration is changed such that ATTR1 is set as a mandatory attribute in the planning area. Now only those location-product
combinations are allowed to exist for the MTHLOCPRD (Month-Location-Product) planning level that are also present as location-product combinations in the
LOCATIONPRODUCT (Location Product) master data type. As a result of this change, location-product combination ( L2- P1), and the associated key gure
data are no longer valid in the planning area:

Any attempt to load key gure data for location-product combinations of the MTHLOCPRD (Month-Location-Product) planning level that are not present
as location-product combinations in the LOCATIONPRODUCT (Location Product) master data type results in the rejection of such key gure data
records.

Deleting any location-product combinations from the LOCATIONPRODUCT (Location Product) master data type also deletes the corresponding
location-product combinations from the MTHLOCPRD (Month-Location-Product) planning level, and the associated key gure data from the planning
area.

To delete the location-product combinations that are not present as location-product combinations in the LOCATIONPRODUCT (Location Product)
master data type from the MTHLOCPRD (Month-Location-Product) planning level, and the associated key gure data from the planning area, run the
Purge Non-Conforming Planning Area Data application job.

Replacing the Time Pro le in a Planning Area

Choose a different time pro le for a planning area, and perform additional required con guration steps and data integration tasks.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
To adhere to business requirements, you want to change the time granularity at which planning data is stored and aggregated in your planning model, so you assign
a different time pro le to the planning area.

You have to perform additional con guration steps and data integration tasks - including the deletion and reupload of key gure values if key gure values already
exist in the planning area - to keep the planning model consistent and be able to activate the planning area after you have replaced the time pro le.

 Caution
Replacing the time pro le in a planning area that has already been activated is a critical con guration task that cannot be standardized, and may result in invalid
planning data.

SAP recommends that you do a thorough test – including all the additional con guration and data integration tasks described below – in a test environment
before you make this change in the productive environment.

SAP recommends that you consider creating a new planning area instead of replacing the time pro le in a planning area that is already in use, and contains key
gure values.

 Note
You don’t need to replace the time pro le if the only change you want to make is assigning an attribute to one of its levels. You can assign an attribute to a level of
an active time pro le that is used in a planning area in the Time Pro les app.

Procedure

[Link] 29/128
12/3/2020
1. Replace the time pro le in the planning area.

You can do this in the Planning Areas app.

2. Specify the planning horizons for each time pro le level.

If the Planning Horizons table is lled out, overwrite the values in the From and To columns.

3. Check, and if needed, update the planning levels.

A planning level is a combination of attributes. As for time, the system uses the PERIODIDn attribute, but displays the name of the time pro le level that
belongs to a speci c PERIODIDn attribute. For more information, see PERIODID and PERIODID(n) Attributes in Time Pro le Levels.

The assigned PERIODIDn attribute to a time pro le level may be different for each time pro le.

For example, both the old and new time pro les have month as a time pro le level, but in the old time pro le, month was assigned PERIODID2, and in the
new time pro le, PERIODID1. When using the old time pro le, PERIODID2 corresponded to month, but in the new time pro le, it represents the technical
week.

Check each planning level if they have to be updated because a time pro le level is not available in the new time pro le, or because the assignment of the
PERIODIDn attribute is different.

4. If an attribute is assigned to one or more time pro le levels of the old time pro le, make sure that you carry over the attribute if it’s used in the new pro le as
well, or remove its usage, if it’s not needed anymore before you activate the planning area.

 Caution
Replacing the time pro le in an active planning area marks the assignment of an attribute to a time pro le level for deletion.

If the same attribute is assigned to a time pro le level in the new time pro le, revoke the pending deletion of the assignment of the attribute for each
planning level that uses the attribute.

If the attribute is not assigned to any time pro le levels of the new time pro le, make sure that the attribute is not used anywhere in the planning area. With
the next activation of the planning area, the attribute is removed from the affected planning levels. If necessary, on the Key Figures screen, update the
de nitions of key gures that use the attribute from old time pro le as the period weight factor, or in the disaggregation expression so that this attribute
isn't referenced anymore.

5. For key gures using planning levels that have been changed: Update the base planning level and the affected calculations to re ect these changes.

6. Update attribute transformations, if any is used in the planning area, so that the time offset remains correct, and no attributes are used that were assigned
to a time pro le level in the old time pro le only.

7. If you use L-code in key gure calculations, create a customer incident to request the update of the L script.

8. Create periods for the new time pro le, if they don't exist yet.

9. If key gure values already exist in the planning area, delete them.

Key gure values are stored per time period (per the ID of a unique time period, such as April 2018). In a different time pro le, the same period ID may point
to a different period, which would make the data inconsistent.

10. Activate the planning area.

11. Upload the key gure values.

12. If the planning area includes an attribute as a key gure, upload the master data records for the master data type that contains the attribute used as key
gure.

Related Information
Creating Planning Areas
Change and Deletion of Planning Levels
Attribute Transformations
PERIODID and PERIODID(n) Attributes in Time Pro le Levels
Options for Creating Time Periods
Activating Planning Areas in the Planning Areas App
Data Lifecycle Management
Data Integration Jobs
SAP Note 2298382

Planning Levels
A planning level is a set of attributes that identify and label key gure values, and forms part of the de nition of a planning area. The attributes you have assigned to
the planning area are available to form planning levels, as well as the time pro le levels, and the attributes assigned to the time pro le levels.

A planning level enables you to analyze and plan at a speci c aggregation level, for example, at the planning level period-product-customer.

Key gures in SAP Integrated Business Planning are calculated or stored at speci c planning levels, and their values can be queried at these planning levels.
Depending on the planning level – that is, the speci c set of attributes that is used in a key gure query – different calculation and/or aggregation steps are

[Link] 30/128
12/3/2020
performed to compute the key gure numbers at that level. These calculation/aggregation steps are speci ed in the calculation de nitions of the key gure.

A planning level can be used as the base planning level of a key gure. The base planning level speci es the most granular level at which the value of the key gure is
de ned. If a planning level is used as a base planning level of a key gure, speci c rules regarding the attributes used in the base planning levels and regarding the
assignment of these planning levels to key gures must be ful lled. For more information, see Planning Areas.

We differentiate between “root attributes” and “non-root attributes” of a planning level:

Root attributes are necessary as keys to identify ( nd) individual key gure values. They de ne the independent dimensions in which the key gure values
exist. The root attributes are often also the keys of master data types but this is not a necessary condition.

Non-root attributes are also associated with the key gure values but don’t on their own uniquely identify what the key gure value is for. They can be
thought of as labels (sometimes hierarchies) to aggregate key gure values.

Planning levels are used in the calculation de nitions of key gures. The system has a special, built-in planning level, the REQUEST level, which represents the
planning level at which the user queries the key gure data. A key gure can be queried at any combination of attributes that are available in the REQUEST-level
calculation, and come from the planning levels of the input key gures.

In addition, there are also planning levels used for aggregation, for example to support demand fair share, to which no key gures are assigned.

 Example
A key gure SALESFORECAST might depend on the following attributes:

Attribute Description Root Attribute (X)

PRDID Product ID X

CUSTID Customer ID X

REGION Sales Region

PRDGRP Product Group

PRDFAM Product Family

MARKET Market Segment

PERIODID0 Month X

Let’s assume that the attributes PRDID, CUSTID, and PERIODID0 are the root attributes. Let’s call this set of attributes the planning level PRDCUST. (You
could choose any name for the planning level.)

The implication is that every stored key gure value for SALESFORECAST depends on a value for PRDID, CUSTID, and PERIOIDID, that is, on a value for a
Product ID, a Customer ID and a Month. For example, the forecast for sales (SALESFORECAST) of product P1 to customer C1 in 2018/12 might be
“100”.

The key gure value also depends on the other attributes. For example, you could ask about the SALESFORECAST for the market segment “M1”. MARKET
might, for example, be an attribute of customer or customer product: You specify the origin of the attributes in the planning area.

When key gure data is loaded, the system determines all attribute values based on the given root attributes of the planning level. If these values cannot be
uniquely determined, the data set contains an error.

Related Information
Creating Planning Areas
Creating Key Figures
Key Figure Calculations

Creating Planning Levels

Use the Planning Areas app to create planning levels.

Prerequisites
Make sure you have created a planning area and assigned a time pro le and attributes to it.

Context
A planning level is a set of attributes that enables you to store and analyze planning data at a speci c granularity. You use the planning level you create here for
de ning key gures and their calculations, and for querying key gure values.

[Link] 31/128
12/3/2020
Procedure
1. In the Planning Areas app, nd the planning area you want to create planning levels for and open its details.

2. Choose New on the Planning Levels tab of the Planning Area (details) screen or on the Planning Levels tab of Focus Mode.

The Select Time Pro le Level dialog appears.

3. On the Select Time Pro le Level dialog, select the lowest time pro le level for the planning level and click OK.

You can select one of the time pro le levels or none. If you select one of the time pro le levels, the system automatically lls the Time Attributes table.

The New Planning Level screen is displayed.

4. On the New Planning Level screen, enter an ID and description for the planning level.

The planning level ID can:

be up to 32 characters long

contain numbers and letters

only start with a letter

ID: PERPRODCUST

Description: Period/Product/Customer

 Note
You can use special characters in the description of the planning level. These special characters might not be shown in, for example, the names of
worksheets in the IBP Excel add-in due to restrictions on special characters in Microsoft Excel.

5. Select time attributes or change the automatically provided assignments.

6. Optional: Select the lowest time pro le level as root for the planning level.

You can only set one time pro le level as a root attribute of a planning level.

7. Add attributes and master data types to the planning level.

You can select the attributes and master data types that you have previously assigned to the planning area on the Attributes tab. Make sure that you use all
attributes you assigned to the planning area in one or more planning levels.

 Note
If the ID attribute of a master data type is linked to the description attribute, you only need to include the ID in the planning level. The description is then
included via the link.

Add all attributes of the S2PRODUCT and S2CUSTOMER master data types.

8. Select the root attributes, as in the table below.

A planning level can include root attributes that are not keys of a master data type, but you always have to make sure that the key attribute of the same
master data type is not assigned to the planning level in such a case.

If you want to use multiple planning levels as base planning levels of stored key gures, and these planning levels have identical root attributes (not taking
the time attribute into consideration), ensure to set identical non-root attributes as well.

Planning Level Description Master Data Root Attribute

PERPRODCUST Period/Product/Customer S2PRODUCT PRDID

S2CUSTOMER CUSTID

9. Optional: Select the Conversion Source or Conversion Target checkbox for the attribute.

Property Description

Conversion Source Indicates that an attribute is used as a source unit for conversion purposes.

Conversion Target Indicates that an attribute is used as a target unit for conversion purposes.

10. Optional: Add history attributes and data sharing attributes to the planning level.

De ne such attributes to use change-history-based calculations.

 Note
You can only add history and data sharing attributes to the planning level if you have enabled the planning area for change-history-based key gure
calculations.

[Link] 32/128
12/3/2020

11. Save your entries.

Results
An inactive planning level is created.

Next Steps
You can use the planning level as a base planning level of a key gure, or in calculation de nitions of a key gure.

Activate the planning area to activate the planning level you created. You cannot activate a planning level directly.

Related Information
Creating Key Figures
Planning Areas
Creating Attributes
Description Attributes

Assigning Attributes to Planning Levels

Use the Planning Areas app to assign the attributes in your planning area to planning levels.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
Each attribute in your planning area needs to be assigned to one or more planning levels except for those that are marked as planning area independent.

Steps
1. Open your planning area.

2. On the Attributes tab of the Planning Area (details) screen, select the attribute that you want to assign to planning levels and choose Assign to Planning
Levels.

3. On the Assign Attribute to Planning Levels screen, select all the planning levels that you want to assign your attribute to and choose Assign.

Ful lling Attribute Sourcing Requirements

When assigning your attribute to planning levels, you need to ensure that sourcing requirements are ful lled for the attribute. On the Assign Attribute to Planning
Levels screen, the following information is available to help you nd the relevant planning levels:

If you select a planning level in the list, values for the Input PLs and Output PLs columns are displayed. The values are clickable and of the format X/Y, where
X and Y have the following meanings:

Y in the Input PLs column shows the total number of input planning levels in key gure calculations where the planning level selected is in the output
(that is, all the planning levels that the planning level selected depends on).

Y in the Output PLs column shows the total number of planning levels that depend on the selected planning level in a similar way.

The X values show the number of input/output planning levels where the attribute being added to the planning level selected is already added.

If you click on the values or the row containing them, a list of all input and output planning levels (for the relevant planning level) will be displayed in a new
dialog. In the dialogue, the planning levels currently selected (or already assigned to the attribute) are marked in the checkboxes next to the items. You can
deselect any of the planning levels marked but you can also select any further ones to ensure that attribute sourcing requirements are ful lled. When you go
back to the previous dialog, the list will be updated accordingly.

Whether the input planning levels ful l the sourcing requirements for the attribute is shown in the Fully Sourced column next to the Input PLs column ("yes"
or empty).

Change and Deletion of Planning Levels

The changes you can make to a planning level depends on if the planning level is used in key gures, and if values exist for those key gures. For certain changes,
and for the deletion of a planning level, you must perform several con guration steps in a given order.

[Link] 33/128
12/3/2020
You create the planning levels to use them in key gure de nitions (as the base planning level of a key gure) and in key gure calculations.

Whether you can change a planning level or not depends on if the planning level is used in key gures, and if data (key gure values) already exists for the key
gures that use the given planning level. The Used in Key Figures eld shows you if the selected planning level is already used in key gure de nitions or
calculations.

Description
You can change the description of a planning level any time.

 Note
You cannot change the ID of a planning level.

Attributes
You can add an additional non-root attribute to a planning level.

You can remove a non-root attribute from a planning level only if the attribute is not used in any key gure calculations.

To remove a non-root attribute that is used in key gure calculations, rst edit the key gure calculations so that none of them includes the attribute. Only then can
you remove the attribute from the planning level.

 Note
A planning level must have at least one attribute.

Root Attributes

 Caution
Changing the root attribute of a planning model may result in inconsistency between the planning model and the already existing data.

SAP Integrated Business Planning is designed to preserve the consistency of the planning model and the planning data. If such a change is made that would
break the consistency, IBP keeps the planning data intact, and rejects the change of the model by making the next activation of the planning model fail.

You can set an additional attribute to root if the planning level is not used in any key gures, or if the key gures that use the given planning level as their base
planning level do not have key gure values.

If the planning level is not used, or if the key gures that use a given planning level as their base planning level do not have key gure values, you can set a root
attribute to non-root.

If key gure values exist (by upload or by manual edit of data in the planning view), you must follow this procedure if you want to set a root attribute to non-root:

1. Delete the values of the stored key gures that use the planning level.

To do this, in the IBP Excel add-in, delete all values of all stored key gures that use the planning level. The cells of key gure values must be empty. Then
delete the planning objects by choosing Delete Planning Objects.

2. In the Planning Areas app, set the root attribute to non-root.

 Note
A planning level must have at least one root attribute.

Deletion of a Planning Level

You can delete a planning level if it is not used in any key gures.

To delete a planning level that is in use, to keep your data consistent, you must follow this procedure:

1. Delete the values of the stored key gures that use the planning level.

To do this, in the IBP Excel add-in, delete all values of all stored key gures that use the planning level. The cells of key gure values must be empty. Then
delete the planning objects by choosing Delete Planning Objects.

2. In the Planning Areas app, delete all key gures (de nitions) that use the planning level to be deleted.

3. In the Planning Areas app, delete the planning level.

[Link] 34/128
12/3/2020

 Caution
If you delete all stored key gure de nitions that use a given base planning level, you must delete their key gure values rst to keep your data consistent.

Key Figures
Key gures are series of numbers over time, where each number corresponds to a particular time period value.

Key gures have a business context: In SAP Integrated Business Planning, end users view and use key gures in the planning views or in Analytics. Every key gure
has a base planning level.

Key gures are associated with a key, which is a combination of attributes from one or more master data objects.

Key gures represent variables that are associated with attributes (master data types), and can be imported into the SAP Integrated Business Planning system,
calculated, and/or manually edited.

 Example
Examples of key gures are Sales Forecast, Marketing Forecast, Consensus Demand Plan, Projected Inventory, Capacity Plans or actual data such as Sales
Orders and Shipment History.

Once you have created your attributes, master data types, time pro les, and planning areas and levels, you de ne the key gures you want to include in your
planning model.

For more information, see Creating Key Figures.

 Caution
To run the inventory operators and time-series-based supply planning algorithms, you have to use speci c technical IDs de ned by SAP for the relevant key
gures and also for master data types and attributes. For demand sensing, the same applies to key gures for which a business meaning has not been speci ed
and certain master data attributes. For more information, see the documentation of the relevant planning operator in this guide and the respective chapter of
the application help.

Types of Key Figures

You can create the following types of key gures:

Type Explanation

Key gure The key gures that end users view in the planning views or in Analytics.

Helper key gure Helper key gures are typically used for intermediate calculation results in a regular
key gure or in another helper key gure. For example, they can be used to break down
a large calculation into manageable subcalculations.

Helper key gures are not visible to the end user and do not have a base planning level.
They can be used at request level or at any other planning level. They are used in
calculations that have more than 3 inputs at different planning levels.

Helper key gures are primarily used in ratio calculations, last period aggregation, and
in cost calculations. You can also use them in cases where the same key gure would
otherwise occur twice in a single calculation. (You can't use the same key gure name
twice in one calculation.)

As they are used only in calculations, helper key gures do not have key gure
properties such as “stored”, “editable”, “aggregation”, and “disaggregation”.

For ease of identi cation, helper key gures are usually pre xed “H”.

Attribute Transformations Attributes that are assigned to a planning level can be transformed to a different value
based on certain conditions. For example, Period ID can be transformed to calculate
lead time offset.

For more information, see Example: Attribute Transformations.

Attributes as key gures You can de ne attributes of master data types as key gures in the planning area.

For more information about attributes as key gures see Attributes as Key Figures.

For more information on how to con gure an attribute as a key gure, see De ning an
Attribute as a Key Figure.

[Link] 35/128
12/3/2020

Type Explanation

Alert key gure Key gures that monitor and manage the execution of business plans based on user-
de ned criteria. Alert key gures are always calculated. They can't be stored or edited.

Alert key gures can only have the values" 0" or "1", meaning that the alert itself is
either ON or OFF. Alerts typically check conditions on other key gures, such as
TargetRev vs. ConsensusRev > 10%.

Snapshot key gure To check how key gure values have evolved over time, you can set up an application
job to take snapshots of the selected key gure at regular intervals. The values
captured in this way are stored in a snapshot key gure. You can display the values of
the snapshot key gure in your planning view, which allows you to create a time-lapse
view of your data.

Depending on your use case, you can either use original snapshots or lag-based
snapshots. For more information, see Snapshots.

Snapshot key gures are system generated and always stored.

 Note
Note the following guidelines with respect to key gures:

Key Figures Affected Guideline

Supply Planning input and output key gures Must be stored key gures.

Input key gures added via data integration Mark as Stored. If you need to edit such a key gure, mark it as Editable.

Quantity and value key gures Typically set to aggregation mode SUM, MIN, or MAX. If such key gures are de ned
as Editable, Disaggregation Mode is set to Equal.

Ratio, price, cost, and percentage key gures Typically set to aggregation mode Custom, Min, Max, or Avg. If Editable, typically set
to Copy.

Such key gures generally have request level calculations.

Related Information
Creating Key Figures
Attributes as Key Figures
De ning an Attribute as a Key Figure

Creating Key Figures

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
Once you have created your attributes, master data types, time pro les, and planning areas and levels, you de ne the key gures you want to include in your
planning model.

Steps
1. Go to the Key Figures tab of the planning area in the Planning Areas app.

Alternatively, enter focus mode using the Focus Mode button available from any tab of the Planning Area (details) screen.

2. Choose New, and select the type of key gure you want to create from the dropdown list.

3. Enter an ID for the key gure, for example, SALESFORECASTQTY.

4. Select the desired base planning level from the drop-drown menu (for example, PERPRODCUST).

The base planning level speci es the most granular level at which the value of the key gure is de ned.

 Note
Different key gures may have different base planning levels. However, if multiple planning levels that are used as the base planning level of stored key
gures have identical root attributes (not taking the time attribute into consideration), ensure to set identical non-root attributes as well.

[Link] 36/128
12/3/2020
A calculation can be speci ed for a key gure at a planning level other than its base planning level. Key gure values are calculated or stored at the base
planning level and at each planning level for which a calculation is speci ed.

As a result, the system creates a REQUEST level calculation by default. Later on, if you modify the planning level or the aggregation mode, the REQUEST
level calculation is updated automatically up until you edit the calculation manually.

5. Fill out the characteristics as required:

Field Label Explanation

Display Settings Determines how the key gure is displayed in analytics and how decimals are displayed in the Web-
Based Planning app, the Driver-Based Planning app, and the Copy Operator (Advanced) app.

Decimals: Specify the number of decimal places required. The default setting is 6 decimal places.
This setting also controls rounding in disaggregation for those key gures that have SUM or AVG
aggregation mode.

Display as Percentage: Select to display the key gure as a percentage. Note that key gures can only
be displayed as a percentage in analytics.

 Note
In the SAP Integrated Business Planning, add-in for Microsoft Excel, the EPM formatting sheet
controls how numbers are displayed.

Base Planning Level Shows the planning level you selected earlier.

Aggregation Mode SUM (default value), MIN, MAX, AVG, CUSTOM

You use aggregation mode CUSTOM in the following cases (only relevant for stored key gures):

When a key gure has a complex calculation at request level, for example, Unit Price, which
has inputs at request level.

When the planning level used in the request level calculation is different from both the base
planning level of the key gure and from the planning level that is used in unit of measure or
currency conversions.

The aggregation mode is relevant for stored key gures only. Together with the disaggregation mode
and optionally the proportionality it determines how values for stored key gures are disaggregated.

 Example
A value of 100 for Q1 of 2020 is to be disaggregated to the three monthly planning combinations
JAN 2020, FEB 2020, and MAR 2020. The values should have a proportionality of 2:3:5.

Depending on the selected aggregation mode, the distribution of the values to the individual
buckets leads to the following result:

Exam ple: Results of Aggregation

JAN 2020 FEB 2020 MAR 2020 Values for Q1

Proportionality 2 3 5
Factor

Result with 20 30 50 20+30+50=100

Aggregation
Mode SUM

Result with 60 90 150 (60+90+150)/3=100

Aggregation
Mode AVG

Disaggregation Mode Disaggregation mode is available only for key gures for which Edit Allowed is selected. There are two
options:

Copy Value

Equal Distribution

Proportionality After specifying the disaggregation mode, you can de ne the proportionality for disaggregation. For
more information see Con guration of Proportional Disaggregation.

[Link] 37/128
12/3/2020

Field Label Explanation

Period Weight Factor Used to enable a proportional distribution according to the period weight factor. This option can only
be used for the Equal Distribution disaggregation mode and if the time pro le contains the relevant
attribute of the data type INTEGER.

For more information on the period weight factor, see Con guring Aggregation and Disaggregation of
Data Across Different Time Pro le Levels.

Disaggregation Expression Used to enter a disaggregation expression, that is, a mathematical expression that disaggregates the
values entered for the key gure that is de ned using other attributes and key gures. The following
conditions apply to disaggregation expressions:

All the key gures in the expression must be stored and must have the same base planning
level as the key gure for which the expression is de ned. To disaggregate key gure values
proportional to a calculated key gure, use the Advance Simulation operator or copy the
calculated values to a stored key gure that can be used in the disaggregation expression.

If the reference key gure is calculated and stored, the stored value will be used in the
disaggregation expression.

All the attributes must be from the base planning level of the key gure for which the
expression is de ned

You can enter a disaggregation expression only when Edit Allowed has been selected.

You can call input help for the Disaggegation Expression eld by entering a double quotation mark.

Examples of values in Disaggregation Expression:

"KEYFIGURE1"

"KEYFIGURE1" + "KEYFIGURE2"

"KEYFIGURE1" + "ATTRIBUTE"

(IF(ISNULL("ADJUSTEDACTUALSQTY"),"ACTUALSQTY","ADJUSTEDACTUALSQTY"))

Consideration of the disaggregation expression during disaggregation:

The disaggregation expression is only evaluated if proportionality is de ned.

If the disaggregation expression has a value <> 0 on aggregated level, it is calculated for all
child nodes and used as the proportional factor by disaggregation.

If the disaggregation expression has a value of 0 on aggregated level, the period weight factor
is used as proportional factor (if de ned).

If neither the disaggregation expression nor the period weight factor can be used as
proportional factor, the disaggregation is done equally/ by copy as de ned in the
disaggregation mode.

 Note
You must enter key gure IDs and attribute IDs in uppercase, and place them in double quotation
marks.

 Example
A demand planner has a product family PF1 with only two products, P1 and P2. These products
have the following values at the base planning level:

Product Customer Month Marketing Actuals Qty 12

Forecast Qty Months Offset

P1 C1 Jan 100

P2 C1 Jan 200

At the aggregated level, the values for the product family are as follows:

Product Family Customer Month Marketing Actuals Qty 12

Forecast Qty Months Offset

PF1 C1 Jan 300

The demand planner would now like to disaggregate the marketing forecast quantity to individual
products in the product family proportionally based on the key gure Actuals Qty 12 Months
Offset.

If, at the aggregated level, the demand planner enters 330 for Marketing Forecast Qty without the
expression in the Disaggregate Expression box, the quantity would be distributed equally between

[Link] 38/128
12/3/2020

Field Label Explanation

the two lower levels as 165 and 165. Now, with the disaggregation expression, the values are
disaggregated based on values in reference key gure Actuals Qty 12 Months Offset as follows:

Product Customer Month Marketing Actuals Qty 12

Forecast Qty Months Offset

P1 C1 Jan 110 100

P2 C1 Jan 220 200

Stored Indicates a key gure in which data is stored at a de ned base planning level.

Note that all edited key gures are designated as Stored. However, an imported key gure can be
designated Not editable. (For example, Actuals Qty must not be changed.)

 Note
Select both Stored and Calculated only for key gures that are con gured to default to another
key gure. See Defaulting to Another Key Figure.

Edit Allowed If a key gure is only calculated, its values can’t be edited. The values of stored key gures and key
gures that are both stored and calculated can be changed.

The value of a key gure can change in the following ways:

in the SAP IBP, add-in for Microsoft Excel, the Web-Based Planning app, or the Driver-Based
Planning app by the user

during data integration

through planning algorithms and planning operators by the system

The Edit Allowed eld controls by which of the above means a key gure value can be changed in the
system. The following options are available:

Not Editable: you can't edit the key gure in the SAP IBP, add-in for Microsoft Excel

System Editable: any kind of planning algorithm, for example, the forecasting algorithm, can
change the key gure for the complete time horizon

Editable in the Current or Future Period: system users and planning algorithms can both
change the key gure, but only in the current period or for future periods

Editable in the Past: system users and planning algorithms can both change the key gure,
but only in the past periods

All Editable: any of the above changes are possible

Calculated Key gures in which values are always calculated based on user-de ned formulae (for example,
Revenue = Qty * Price).

This type of key gure is usually not editable. However, to support use cases such as defaulting, a key
gure can be both editable and stored. For more information about defaulting, see Defaulting to
Another Key Figure.

Key gure calculations (calculated key gures) are made at a de ned planning level, which can be
different from the level on which a user requests to view the key gure. An IBP planning area typically
includes key gures from multiple planning levels, which can be linked with calculations that often
result in key gures at additional planning levels.

Enable Fixing Select this checkbox if you want to use the xing of key gure values for a speci c key gure. For more
information about the con guration of key gure xing, see Con guration of Key Figure Fixing.

Enable Planning Notes Select this checkbox if you want to use planning notes for a speci c key gure.

For more information about planning notes and how to set them up see Planning Notes and Setting
Up and Managing Planning Notes.

Planning Level for Planning Notes By default, planning notes can be created or displayed on any planning level that the key gure allows,
down to the base planning level of the key gure. You can restrict this by de ning the lowest level to
which planning notes can be created and displayed in this eld. The planning level you choose here
must be a subset of the attributes of the key gure’s base planning level.

For more information about planning notes and how to set them up see Planning Notes and Setting
Up and Managing Planning Notes.

[Link] 39/128
12/3/2020

Field Label Explanation

Input/Output for Supply Planning Indicates an input and/or output key gure for supply planning. If the planning area is enabled for
supply planning, this eld determines whether the key gure is used as an I/O for supply planning.

 Note
To enable a planning area for supply planning, go to the General tab of the planning area in the
Planning Areas app and select Enable Supply Planning .

Input/Output for TS Forecast Consumption Indicates if the stored key gure is an input or output for time-series-based forecast consumption.

For more information about time-series-based forecast consumption. see Time-Series-Based

Forecast Consumption.

Convert Using Used for disaggregation of conversion key gures. Required only for key gures that are editable.
Select the key gure that you want to use to convert the current key gure.

 Note
This key gure must be a stored key gure and not a calculated one, as calculation rules are not
executed.

Enable Change History Indicates that changes to the key gure will be tracked. For more information, see Change History for
Key Figures and How to Enable Change History?.

Hashtags You can de ne your personal ltering criteria in the form of hashtags. You can assign hashtags to any
key gures for which characteristics are available.

You can introduce a new hashtag or reuse existing ones and you can assign several hashtags to the
same key gure.

Hashtags are not case-sensitive, always start with the hashtag symbol (#) and can only contain
alphanumeric characters and underscores. You can type your hashtag with the hashtag symbol at the
beginning or without it, in which case the system will add it to your string.

 Note
The #IBP* and #SAP* namespaces are reserved by SAP, so you cannot create any hashtags
beginning with these strings.

6. Save your key gure. If you choose Save and New, you can immediately proceed to create the next key gure of the same type.

Related Information
Decimal Places in Key Figure Values

Con guration of Key Figure Fixing

Before business users can x and un x key gure values, you must rst enable xing of key gures in the con guration.

Key Figure Requirements

As well as the requirements described under Fixing of Key Figure Values, please consider the following:

The Edit Allowed eld of a key gure must be set to All Editable, Editable in the Current or Future, or Editable in the Past.

The key gure must have a speci c combination of aggregation and disaggregation modes. It either needs to have aggregation mode Sum and
disaggregation mode Equal distribution, or it needs to have aggregation mode Avg and disaggregation mode Copy value. Note that the proportionality No
Proportional Disaggregation is not supported.

The key gure must not be time-independent. (A key gure is time independent if its base planning level contains no time attributes as root attribute or if it
has PERIODID as the only root time attribute.)

The key gure must not use L script in its calculation de nition.

The key gure must not be marked as Output for Supply Planning or Input and Output for Supply Planning.

The key gure must not be marked as Output for TS Forecast Consumption.

The key gure must not have the business meaning Promotion Final, Promotion Total (Source), or Promotion Uplift (Source) assigned to it.

How to Enable Fixing of Key Figures

[Link] 40/128
12/3/2020
You need to enable xing of key gure values for each key gure that you want your business users to be able to x and un x. To do this, you need to select the
Enable Fixing checkbox in the Characteristics section when you create or edit a key gure in the Planning Areas app.

Technical Key Figures for Fixing

After you have enabled xing for a key gure, two technical key gures are generated. These technical key gures are merely used for storing technical information
about the key gure for which you have enabled xing and are therefore not visible in any planning app. For information purposes, they are displayed in read-only
mode in the Planning Areas app.

The technical key gures use the following pre xes:

Pre x Purpose of Technical Key Figure

DIS_FIXIND_<key gure name> Holds the information that the key gure is xed

DIS_FIXQTY_<key gure name> Holds the xed quantity

 Note
If necessary, the system may slightly adjust the name of the technical key gures to ensure that they are unique.

Enabling Fixing Information to Be Displayed Correctly in the SAP Integrated Business Planning, add-in for
Microsoft Excel
If the planning view in the SAP IBP, add-in for Microsoft Excel contains xable key gures but no EPM formatting sheet, xing formatting will always stay in the cells
where it is added. Over time, xed cells get multiple xing icons.

To make sure that xing information is displayed correctly in the IBP Excel add-in, you need to include an EPM formatting sheet in the planning view by choosing
Edit View View Formats on the IBP tab. In the EPM Formatting Sheet dialog, you can de ne speci c formatting rules for xable key gures.

Related Information
Fixing of Key Figure Values

Enabling Planning Notes for a Key Figure

You can enable planning notes for up to 20 stored key gures in a planning area.

Context
To allow business users to add planning notes to the values of a key gure in the planning view, you must enable planning notes in the key gure con guration.

 Note
You can’t enable planning notes for helper, snapshot, technical, external, or alert key gures.

Procedure
1. In the Planning Areas app, select the planning area that contains the key gure for which you want to enable planning notes.

2. Select this key gure in the Key Figures tab.

3. Choose Edit.

4. In the Characteristics section, choose the Enable Planning Notes checkbox.

This means that planning notes can be created and displayed on any aggregation level of the key gure down to its base planning level.

5. Optional: If you want to restrict creation and display of planning notes to higher aggregation levels, you can select a different planning level in the Planning
Level for Planning Notes eld.

 Caution
The planning level you choose here must be a subset of the attributes from the key gure’s base planning level. If you select a planning level that does not
ful ll this requirement, you won’t be able to (re-)activate your planning area.

For more information about the various uses for planning notes, see Planning Notes and Setting Up and Managing Planning Notes.

6. Reactivate your planning area.

Related Information
[Link] 41/128
12/3/2020
Planning Notes
Setting Up and Managing Planning Notes

Con guration of Proportional Disaggregation

In the Planning Areas app, the con guration of proportional disaggregation depends on the combination of values for several elds.

The Disaggregation Mode eld controls the base disaggregation mode, which is either Equal Distribution or Copy Value.

The value speci ed in the Proportionality eld describes the data source of the proportional factors that are used as weighting factors during proportional
disaggregation.

Proportional disaggregation is available for both the Equal Distribution and Copy Value disaggregation modes. The Proportionality eld can take the values
described in the table below.

Values of Proportionality Field

Value Description

No Proportional Disaggregation Values are disaggregated according to the disaggregation mode.

Same Key Figure – Stored Values If the stored values of the same key gure are not 0, the aggregated values are
disaggregated proportional to them, otherwise according to the disaggregation mode.

Same Key Figure – Calculated Values If the calculated values of the same key gure are not 0, the aggregated values are
disaggregated proportional to them, otherwise according to the disaggregation mode.
In this case, a disaggregation expression is generated based on the calculation rules
during activation.

Other Key Figure – Stored Values If the stored values of the other key gure are not 0, the aggregated values are
disaggregated proportional to them, otherwise according to the disaggregation mode.

Disaggregation Expression If the resulting values of the disaggregation expression are not 0, the aggregated
values are disaggregated proportional to them, otherwise, according to the
disaggregation mode.

If Other Key Figure – Stored Values is selected in the Proportionality eld, the key gure against which the disaggregation is to be done is available in the Key
Figure for Proportionality eld.

Each combination of the above settings in the Planning Areas app corresponds to a combination of settings in the Con guration app. The tables below show how
the different con gurations are represented in the Planning Areas app and the Con guration app respectively.

Configuration of Proportional Disaggregation in the Planning Areas app

Variant Disaggregation Mode Proportionality Disaggregation Expression Key Figure for Proportionality

1 Equal Distribution No Proportional Disaggregation Empty Empty

2 Equal Distribution Same Key Figure – Stored Values Empty Empty

3 Equal Distribution Same Key Figure – Calculated Empty Empty

Values

4 Equal Distribution Other Key Figure – Stored Values Empty <Other Key Figure ID>

5 Equal Distribution Disaggregation Expression <Expression> Empty

6 Copy Value No Proportional Disaggregation Empty Empty

7 Copy Value Same Key Figure – Stored Values Empty Empty

8 Copy Value Same Key Figure – Calculated Empty Empty

Values

9 Copy Value Other Key Figure – Stored Values Empty <Other Key Figure ID>

10 Copy Value Disaggregation Expression <Expression> Empty

Configuration of Proportional Disaggregation in the Configuration app

Variant Disaggregation Mode Disaggregation Expression

1 Equal Distribution Empty

2 Proportional if aggregated value is not zero; otherwise, equal distribution Empty

3 Proportional if aggregated value is not zero; otherwise, equal distribution Empty

4 Proportional if aggregated value is not zero; otherwise, equal distribution <Other Key Figure ID>

[Link] 42/128
12/3/2020

Variant Disaggregation Mode Disaggregation Expression

5 Proportional if aggregated value is not zero; otherwise, equal distribution <Expression>

6 Proportional if aggregated value is not zero; otherwise, copy value to Empty

7 Proportional if aggregated value is not zero; otherwise, copy value to Empty

8 Proportional if aggregated value is not zero; otherwise, copy value to Empty

9 Proportional if aggregated value is not zero; otherwise, copy value to <Other Key Figure ID>

10 Proportional if aggregated value is not zero; otherwise, copy value to <Expression>

Conversion Con guration

You can specify a conversion key gure in the Convert Using eld.

You can specify a key gure in the Convert Using eld of key gures that are editable. The key gure you specify can be stored or calculated.

The calculated key gure that you specify in the Convert Using eld can't contain any aggregation in its calculations and must meet either of the following
requirements:

It is de ned on the same time pro le level as the key gure. This means that their base planning levels have the same time pro le level as root time attribute.

 Example
In the SAP6 sample planning area the Statistical Forecast Price (STATISTICALFCSTPRICE) key gure is converted using the
EXCHANGERATE_UOMCONVERSION (EXCHANGERATEUOMCONVERSION) key gure. Both key gures are de ned on technical week level.

It is de ned on a less granular time pro le level as the key gure, that is, its base planning level has a time pro le level as root time attribute that is less
granular as the one speci ed as root time attribute in the base planning level of the key gure. The data on the less granular time pro le level must be
readable on the other time pro le level, so, for example, if the key gure is de ned on technical week level, it can be converted using a key gure de ned on
months, quarters and years. If the key gure is de ned on calendar week level, it can't be converted using a key gure de ned on monthly level, as a calendar
week can fall into two months.

 Example
In the SAPIBP1 sample planning area, the Unit Cost (COSTPERUNIT) key gure is de ned on technical week level and converted using the
Exchange Rate by UOM (EXCHANGERATEUOMCONVERSION) key gure which is de ned on monthly level.

Related Information
Con guring Currency Conversion
Con guring Unit of Measure Conversion

Copying Key Figures

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
Note the following with respect to copying key gures:

The associated planning area must have the status Active or Inactive.

You can copy key gures only within the same planning area.

The planning area must be within the customer space.

When you copy a key gure, the new key gure has the same type (for example, when you copy a helper key gure, the new key gure is also a helper key
gure).

Steps

1. In the Planning Areas app, go to the Key Figures tab of the planning area or enter focus mode.

2. Select the key gure that you want to copy.

[Link] 43/128
12/3/2020
3. Choose Copy.

4. Enter the ID for the new key gure.

5. Choose Copy.

The source key gure is copied to the new key gure.

6. Review the new key gure and adjust the properties as required, adapt calculations, and remove any calculations that you do not need.

Editing Key Figures

Context
You can change all properties of a key gure except the key gure ID.

You can change the name, description, display settings, and hashtag assignments of an active key gure. For all other changes, the key gure must be inactive.

Editing a Key Figure on the Key Figures Tab

You can make changes to individual key gures in the Planning Areas app as follows:

1. Go to the Key Figures tab of your planning area.

2. Select the key gure that you want to change from the key gure worklist. The details of the key gures will be displayed in full-screen display mode.

3. Choose Edit and make your changes.

4. Save your changes.

If you want to edit further key gures, navigate back to the key gure worklist to select the next item.

Editing Key Figures in Focus Mode

To edit several key gures in quick succession you can use the focus mode available in the Planning Areas app as follows:

1. Enter focus mode by choosing the Focus Mode button on the Planning Area (details) screen. If needed, switch to the Key Figures tab of Focus Mode (if you
have navigated from the Planning Levels tab of the Planning Area details screen).

2. Select the key gure that you want to edit from the key gure worklist on the left. The details of the key gure will immediately appear in edit mode on the
right-hand side with the worklist still displayed on the left.

3. Make your changes.

4. Save your changes and proceed by selecting the next key gure that you want to edit from the worklist on the left.

Creating External Key Figures

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
External key gures enable SAP Integrated Business Planning to work with special stored key gures where the actual time series content comes from an external
database. To use external key gures, the application-relevant orders, for example, sales orders or purchase orders, have to be aggregated and integrated from ERP
to an SAP HANA database table inside the Integrated Business Planning system using a near real-time integration mechanism. When you set up your planning
model, you have to de ne an external key gure or key gures referring to this table. Since the integration is continuous, the reference key gure data always
contains the latest aggregated entries from SAP ERP. Therefore, there is no need for manual update.

Steps
To create external key gures you have to do the following:

1. Go to the Planning Areas app.

2. Select the planning area and open it.

3. Enable the planning area for external time series and select an integration pro le for your planning area.

[Link] 44/128
12/3/2020

 Note
An integration pro le for a planning area and a pro le for all master data types in this planning area must be the same.

4. Save your changes.

5. Go to the Planning Levels tab, nd the planning level you want to use and select an entry from Data Source for External Key Figure De nition.

 Note
Make sure that a value has been selected for Data Source for External Key Figure De nition. Otherwise, the planning level does not support external key
gures on this base level.

6. Assign a reference column to each root attribute of the planning level using the Reference Column.

7. Click Save.

8. Go to the Key Figures tab and nd the key gure you want to de ne as external.

9. Select the Stored checkbox.

10. Choose a reference column in the External Key Figure Quantity drop down which contains the time series data for this key gure.

11. Click Save.

Decimal Places in Key Figure Values

In the Planning Areas app, you can de ne the number of decimal places you want to be displayed in analytics, the Web-Based Planning app, and the Driver-Based
Planning app for each key gure. If the number of decimal places is not speci ed, the maximum possible value is used, which is 6 decimal places.

 Note
In the IBP Excel add-in, the EPM formatting sheet controls the display of numbers. The number of decimal places speci ed in the display settings on the Key
Figure tab of the planning area doesn't have any effect on how the IBP Excel add-in displays the numbers.

The setting for decimal numbers also affects disaggregation for key gures that have aggregation mode SUM or AVG. The information provided here refers only to
such key gures.

When a user enters a key gure value in a planning view, or executes a batch process that involves disaggregation, the system manages the values as follows:

The disaggregated key gure values at the base planning level are always rounded to the con gured number of decimal places.

Rounding is done in the planning unit of measure. If the planning unit of measure is different from the base unit of measure, and a conversion to the base unit
of measure is needed, the rounded key gure value may have a different number of decimal places than the con gured number.

The aggregation of the base planning level values is a key gure value that is also always rounded to the con gured number of decimals (when not taking
conversion into account).

The aggregation of the base planning level values is the same as the number entered by the user (provided the number entered does not exceed the number
con gured).

 Example
You entered 2 decimal places for a key gure Demand.

Product group PG has 3 products: A, B, and C.

You enter a value of 10 for Demand at the aggregated planning level PG.

Result: After disaggregation, the key gure values at the base planning level are 3.33, 3.33, and 3.34 for the 3 products A, B, and C. The system arbitrarily
decides which product gets 3.34.

You enter 12.456 for Demand at the aggregated planning level PG.

Result: After disaggregation, the key gure values at the base planning level are 4.15, 4.15, and 4.16 for the 3 products A, B, and C. This aggregates to 12.46
according to the con guration setting of 2 decimal places for the key gure.

 Example
You entered 4 decimal places for a key gure Supply.

Product group PG has 3 products: A, B, and C.

[Link] 45/128
12/3/2020
You enter a value of 12.456 for Supply at the aggregated planning level PG.

Result: After disaggregation, the key gure values at the base planning level are 4.152, 4.152, and 4.152 for the 3 products A, B, and C.

 Note
In some circumstances, taking the number of decimal places into account during disaggregation can affect performance. So if you do not need this feature for a
particular key gure, you can deactivate it by setting the number of decimal places for the key gure to null in the Planning Areas app.

Key Figure Calculations

Context
Once you have created a key gure, you can add calculations to it. Note the following:

All key gures that an end user is able to query from the user interface must have a calculation at REQUEST level, because the system determines how to
calculate the key gure starting from this calculation

You can additionally de ne calculations that aggregate the key gure data from a lower base planning level using an operator such as SUM, MIN, or MAX.

You can also de ne calculations across key gures, for example, KF1 plus KF2.

All key gure calculations have calculation inputs, which can be marked as stored or non-stored. The calculation chain (from REQUEST level to the bottom)
for every key gure must end in a stored key gure.

The calculation shouldn’t involve a division by zero for any actual key gure value. Division by zero causes a numeric over ow condition in the system and
therefore needs to be avoided. For example, the calculation KF1@PL1 = KF2@PL1 / KF3@PL1 involves a division by zero if KF3@PL1 takes the value 0. You
can avoid that by including an if condition in your calculation as follows: KF1@PL1 = IF(KF3@PL1=0, 0, KF2@PL1 / KF3@PL1).

 Example
KF1@PL1 = KF2@PL1 plus KF3@PL1 , Key figure 2 (KF2) is a stored input key gure and key figure 3 (KF3) is a calculated input key gure.
The calculated chain for key figure 3 (KF3) must nish with a stored key gure (such as KF3@PL1 = SUM(KF4@PL2), where KF4@PL2 is a stored key
gure).

Adding Calculations to Key Figures

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

 Note
You can copy or delete key gures with L script, but for modi cation, please contact SAP. For more information, see 2298382 .

1. Go to the Key Figures tab in the Planning Areas app.

2. Select the key gure to which you want to add a calculation and open it for editing.

3. Choose the Add Calculation De nition button.

4. Select the planning level for the left side of the calculation. This can be a planning level that does not have a calculation yet.

5. Place the cursor on the expression editor and type your calculation expression. When you enter the " character (double quotes), a dropdown menu appears,
from which you can select the desired key gure. For example, enter the following: SUM("SALESFORECASTQTY@PERPRODCUS")).

To add a simpli ed key gure calculation, start typing IBP and choose the function you want to use from the dropdown. Then, enter the parameters
according to your modeling requirements.

 Note
Each time you activate a planning area, the system generates a combined graph of all calculations of the planning area. For this graph to be valid, and the
activation be successful, certain requirements apply for the calculations:

A calculation that has 1 or 2 input key gures is valid.

A calculation that has input key gures from 1 or 2 planning levels can be valid, depending on the structure of the graph that is generated during
activation.

If a calculation turns out to be an invalid calculation, activation will fail. Rework the calculation, and activate the planning area again.

A calculation that includes 3 or more planning levels is invalid.

[Link] 46/128
12/3/2020
If one key gure is a stored input, and the other is a calculated input from the same planning level, the system considers it two different planning
levels.

If a calculation is invalid, break it down into calculations that have one or two input key gures only. You can consider introducing helper key gures.

Each change you make in a calculation results in the graph being completely re-generated with the next activation of the planning area. It may happen
that a change in a calculation makes a calculation of a different key gure invalid. Study the activation log of the planning area to nd out if you should
change a calculation.

6. Once you have entered the expression, choose Validate, and verify that the correct inputs have been selected by the system.

The system automatically marks the key gures @ planning level that are used in the expression as inputs in the Input Key Figures dialog.

7. Click OK.

If your expression is correct, it will change color from black to green (planning level) and blue (key gure). This indicates that it is validated. Otherwise, you
receive a warning message.

8. Once your expressions are correct, save your changes.

 Example
This example illustrates how to create a calculation for SALESFORECASTQTY. At request level, the calculation expression aggregates (SUMS) the stored
SALESFORECASTQTY.

The system creates a request level calculation when a key gure is created. The following procedure shows how to add the above calculation for
SALESFORECASTQTY:

a. Click the Add Calculation De nition button.

b. Select the planning level for the left side of the calculation.

c. Place the cursor on the expression editor and type your calculation expression. When you enter the " character (double quotes), a dropdown
menu appears, from which you can select the desired key gure. For example, enter the following:
SUM("SALESFORECASTQTY@PERPRODCUST").

d. Once you have entered the expression, choose Validate and verify that the correct inputs have been selected by the system.

The system automatically marks the key gures @ planning level that are used in the expression as inputs in the Input Key Figures dialog.

e. De ne the Input key gures as shown in the table below.

Input Key Figure Stored

SALESFORECASTQTY@PERPRODCUST X

f. Click OK.

If your expression is correct, it will change color from black to green (planning level) and blue (key gure). This indicates that it is validated.
Otherwise, you receive an error message.

g. Once your expressions are correct, save your changes.

Related Information
SAP Note 2298382

Calculation Graphs

A calculation graph represents a key gure's calculation de nitions at different planning levels, and their input-output relationships.

A key gure can have calculations at many planning levels. Calculations are the nodes of the graph, and their input-output connections are the arcs. Visualizing a
complex calculation graph helps when checking or changing the calculations: their de nitions, planning levels, or inputs.

Use the Key Figure Calculations app to display the complete calculation graph of one or more key gures in a planning area. You can display either the inactive or
the active instance of the calculation graph. The active instance is a complete and consistent calculation graph, otherwise it couldn't have been activated. The
inactive instance includes the changes since the last activation (if there has been an activation), and may not be complete and consistent.

After you have selected the planning area and the key gure, you can display the calculation graph, the where-used graph or lter blocks within a calculation graph:

Choose Calculation Graph Calculations to see the calculation de nitions and how they are built on each other.

Choose Calculation Graph Root Attributes to see the input-output relationships, such as which root attributes from the input planning levels are needed in
the output planning level, which ones are the basis for aggregation, or which attributes form the base of a join.

[Link] 47/128
12/3/2020
Choose Where-Used Graph to display all the calculations that use the selected calculation as a direct or indirect input. You can switch between displaying
calculation de nitions or root and join attributes here as well.

For more information, see Where-Used Graphs.

Choose Filter Blocks to see which attributes you can use for effective ltering and where lter blocks are raised.

For more information, see Filter Blocks.

 Note
If you want to view the calculation graph of a speci c key gure that you have selected in the Planning Areas app, you can navigate directly to the Key Figure
Calculations app using the Show Graph button available in the Planning Areas app.

The Key Figure Calculations app also provides information about the type of the node. Depending on the type of the node, the incoming arc arrow has a speci c
color:

Light Blue: Aggregation

In this relationship between the input and output nodes, there is one input planning level.

The output data set is a subset of the input data set. It contains all records from the input data set that are unique for a combination of values of the root
attributes of the output. It also contains aggregated records for those input records that are not unique: one record for each combination. The records are
aggregated using the function in the calculation de nition (SUM, AVG, MIN, MAX) resulting in one record in the output data set.

Medium Blue: Simpli ed Key Figure Calculations

In this relationship, there is a simpli ed key gure calculation between the input and output nodes. The following simpli ed calculations are available:

Cumulative aggregation (IBP_CAGGR)

Rolling aggregation (IBP_RAGGR)

Last period aggregation (IBP_LPA)

Period shift (IBP_PERIODSHIFT)

Weighted average (IBP_WEIGHTEDAVG)

Coverage (IBP_COVERAGE)

Calendar (IBP_CALENDAR)

Generate missing time periods (IBP_GENERATE_MISSING_TP)

For more information, see Simpli ed Key Figure Calculations.

Orange: Inner join

In this relationship between the input and output nodes, there are two input planning levels.

The output of the inner join is a set of records that combines records from the two input data sets. The output records are the ones have the same
combination of values for the join attributes in both data sets.

For more information about inner join, see Calculations Across Different Planning Levels.

Teal: Projection

In this relationship between the input and output nodes, there can be two input planning levels involved, provided they share the same set of root attributes.

The output of the projection is made by executing an operation on the input (KF2 = KF1 * 2), or with all inputs (KF3 = KF1 - KF2) for each
combination of values of the root attributes.

Purple: Union

In this relationship between the input and output nodes, there is one input planning level.

The output data set contains all records from the input data sets. If there is no value for one of the input key gures in the input data set for a given
combination of values of the root attributes, NULL is stored in the output data set for the given key gure.

Pink: L Script

In this relationship between the input and output nodes, there is one input planning level.

The calculation of the output node is not a calculation expression, but an L script.

To display detailed information for a node (about the calculation de nitions, planning levels, and key gures), call up the Node Info.

To display and change the planing level of the calculation, the key gure, or the base planning level of the key gure, you can navigate from this app directly to the
corresponding model entity in the Planning Areas app.

[Link] 48/128
12/3/2020

Commonly Used Functions and Expressions

Operators
The following operators are available:

+, -, *, /, >, <, =, >=, <=, !=, **, %, AND, OR, NOT

Operator Details Example

% Modulus operator. Returns the remainder, for example, KF1@PERPRODLOC % KF2@PERPRODLOC

17%5 = 2.

** Power operator KF@PERPRODLOC = KF1@PERPRODLOC *

((1/KF2@PERPRODLOC)**0.5 )

AND Boolean operator that returns a value of TRUE if both its KF1@PERPRODLOC = 0 AND KF2@PERPRODLOC = 0
operands are true, and FALSE otherwise.

OR Boolean operator that returns a value of TRUE if any of KF1@PERPRODLOC = 0 OR KF2@PERPRODLOC = 0

its operands are TRUE, and FALSE otherwise.

Functions for Aggregation

The following aggregation methods are available:

SUM

AVG

MIN

MAX

 Note
The same key gure must be the input key gure and the output key gure of the SUM and AVG aggregations.

The MIN and MAX functions can have several input key gures.

Standard Functions

Syntax Details Example

IF(intarg , arg2, arg3) Return arg2 if intarg is considered true CAPACITYOVERLOADS@PERLOCRES =

(not equal to zero), else return arg3. IF(“CAPADEMANDUTILPCT@PERLOCRES”> 1,1,0)

ISNULL(arg1) Return 1 (= true), if arg1 is set to null. MARKETINGFORECASTQTY@PERPRODCUST =

IF(ISNULL(MARKETINGFORECASTQTY@PERPRODCUST),
SALESFORECASTQTY@PERPRODCUST,
MARKETINGFORECASTQTY@PERPRODCUST)

CASE(arg1, default) Return value1 if arg1 == cmp1, CASE(SELECTEDOPTION@PERPROD, 1, KF1@PERPROD, 2,

value2 if arg1 == cmp2, and so on, KF2@PERRPROD,KF@PERPROD)
CASE(arg1, cmp1, value1, cmp2,
default if there is no match.
value2, ..., default)

ABS(arg) Returns arg, if arg is positive or zero, else IF(ABS(SUPPLYREV@PERPRODFML -

–arg. CONSENSUSDEMANDREV@PERPRODFML)/CONSENSUSDEMANDREV@PERPRODFML
> 0.2,1,0)

ROUND(double, int) ROUND(123.456, 0) = 123 KF1@PERPRODLOCSRC = ROUND(KF@ PERPRODLOCSRC, 0)

ROUND(123.456, 1) = 123.5

ROUND(-123.456, 1) = -123.5

ROUND(123.456, -1) = 120

ROUNDDOWN(double, int) ROUNDDOWN(123.456, -1) = 120 KF1@PERPRODLOCSRC = ROUNDDOWN(KF@ PERPRODLOCSRC, 0)

ROUNDDOWN(-123.456, -1) = -130

FLOOR(double) FLOOR(35.1) = 35 KF1@PERPRODLOC = FLOOR(KF@ PERPRODLOC)

CEIL(double) CEIL(35.1) = 36 KF1@PERPRODLOC = CEIL(KF@ PERPRODLOC)

[Link] 49/128
12/3/2020

Syntax Details Example

LTRIM(string) Remove a whitespace pre x from a string.

The whitespace characters may be
LTRIM(string,string)
speci ed in an optional argument.

RTIM(string) Remove trailing whitespace from a string.

The whitespace characters may be
RTIM(string,string)
speci ed in an optional argument.

TRIM(string) Remove whitespace from the beginning

and end of a string.
TRIM(string,string)

UPPER(arg1) Returns arg1 in upper case KF1@PERPRODCUST = IF(UPPER(''ATTR1'') = ''APPROVED'',

"KF2@PERPRODCUST", NULL)

 Example
Sample con guration for aggregation of standard deviation

Take the sum of the squares; then calculate the square root of the total:

1. Calculate the squares:

a. Square the values:

HKF1@PL = PROPAGATEDDEMANDSTDEV@PL ** 2

b. Sum the squares:

HKF1@REQUEST = SUM(HKF1@PL)

2. Calculate the square root of the total:

PROPAGATEDDEMANDSTDEV@REQUEST= HKF1@REQUEST ** 0.5

 Example
ISNULL

The ISNULL condition works only when an underlying time series record exists for the planning object.

Imagine that Sales Forecast Quantity and Marketing Forecast Quantity are the stored key gures for planning level PERPROD.

Planning Object Period Key Figure: Sales Forecast Qty Key Figure: Marketing Forecast Qty

P1 Jan 2018 100

P1 Mar 2018 100

With the above data, IF(ISNULL(SALESFCSTQTY),1,0) exhibits the following behavior:

Period ISNULL Value Notes

Jan 2018 0 January 2018 has the value “100”.

Feb 2018 Not evaluated The planning object for the time period February 2018
does not exist.

Mar 2018 1 Though there is no value for Sales Forecast Quantity,

the Marketing Forecast Quantity key gure (for the
same planning level) has a valid value. Therefore, a
record exists in the time series for this planning object.

Sample Expressions

Key Figure Calculation Expression

Actuals Price ACTUALSPRICE@REQUEST = IF(“ACTUALSQTY@REQUEST”=0,0, “ACTUALSREV@REQUEST”/“ACTUALSQTY@REQUEST”)

Capacity Overloads CAPACITYOVERLOADS@PERLOCRES = IF(“CAPADEMANDUTILPCT@PERLOCRES”> 1,1,0)

[Link] 50/128
12/3/2020

Key Figure Calculation Expression

Capacity Usage CAPAUSAGE@PERPRODLOCRES = “CAPADEMAND@PERPRODLOCRES”*“(IF(CAPASUPPLYPERDEMAND@PERLOCRES”>1,1,

“CAPASUPPLYPERDEMAND@PERLOCRES”))

Marketing Forecast Pro t MARKETINGFORECASTPROFIT@PERPRODCUST = “MARKETINGFORECASTREV@PERPRODCUST”-

“HMARKETINGFORECASTCOST@PERPRODCUST”

Marketing Forecast MARKETINGFORECASTQTY@PERPRODCUST = IF(ISNULL("MARKETINGFORECASTQTY@PERPRODCUST"),

Quantity "SALESFORECASTQTY@PERPRODCUST", "MARKETINGFORECASTQTY@PERPRODCUST")

Constrained Versus CONSTRAINEDVSCONSENSUSREV@PERPRODFML = IF(ISNULL("CONSENSUSDEMANDREV@PERPRODFML")OR

Consensus Demand "CONSENSUSDEMANDREV@PERPRODFML"=0,0, IF(ABS("SUPPLYREV@PERPRODFML" -
Revenue "CONSENSUSDEMANDREV@PERPRODFML")/"CONSENSUSDEMANDREV@PERPRODFML" > 0,2,1,0))

Supply Quantity SUPPLYQTY@PERPRODLOC = IF("HPROJECTEDINVENTORYQTY@PERPRODLOC">=0, "DEPENDENTDEMANDQTY@PERPRODLOC",

"DEPENDENTDEMANDQTY@PERPRODLOC"+ "HPROJECTEDINVENTORYQTY@PERPRODLOC")

Bill Cost per Area BILL_COST_PER_AREA@BSCIRTRSCFRCTOUFRUTO2L3AVG_A = IF(isnull("ASSETAREA5@BSCIRTRSCFRCTOUFRUTO2L3AVG_A") or

Demand Revenue "ASSETAREA5@BSCIRTRSCFRCTOUFRUTO2L3AVG_A"=0,0,"BILL_COST5@BSCIRTRSCFRCTOUFRUTO2L3AVG_A"/"ASSETAREA5@BSCIRT

 Note
In key gure calculations, column engine expressions are used. For differences between the column engine and the SQL engine, see 2780505 .

For more information about column engines, see Using Column Engine Functions in the SAP HANA Modeling Guide.

Related Information
Simpli ed Key Figure Calculations

MIN and MAX with Multiple Inputs

The MIN and MAX functions can have several input key gures.

In the case of several input key gures, there is no aggregation in the MIN and MAX functions; the output is simply the lowest or highest value of the input key
gures. If any of the key gure values is NULL, both the minimum and maximum will be NULL as well.

The attributes of the output planning level must be the union of the attributes of the input planning levels.

Example
In this example, the MIN and MAX functions have three input key gures: CAPACITYMORNING, CAPACITYAFTERNOON, and CAPACITYNIGHT. First, we calculate
the minimum and maximum values on machine/production line level. At this step, there is no aggregation; it is a function with multiple inputs. The output is simply
the lowest and highest value of the input key gures.

MINCAPACITY@REQUEST = MIN("MINCAPACITY@MTHPRODLOC")

MINCAPACITY@MTHPRODLOC = MIN("CAPACITYMORNING@MTHPRODLOC", "CAPACITYAFTERNOON@MTHPRODLOC",

"CAPACITYNIGHT@MTHPRODLOC")

MAXCAPACITY@REQUEST = MAX("MAXCAPACITY@MTHPRODLOC")

MAXCAPACITY@MTHPRODLOC = MAX("CAPACITYMORNING@MTHPRODLOC", "CAPACITYAFTERNOON@MTHPRODLOC",

"CAPACITYNIGHT@MTHPRODLOC")

[Link] 51/128
12/3/2020

Then we aggregate to machine level. The output of the MIN and MAX functions will be the aggregation of the minimum and maximum values calculated before.

Stored Key Figure Calculation

Context
Stored key gures refer to key gures that are stored in the underlying database tables and that are either imported from a source system or else are entered
manually in a planning view in the IBP Excel add-in.

Examples include SALESFORECASTQTY and ACTUALSQTY.

The following apply to stored key gure calculations:

The associated key gure is marked as Stored (and can also be set to Editable)

The key gure has only one request level calculation, but can also have some other calculations.

The input key gure for the calculation is the same key gure at base planning level.

Example: Calculation De nition for Actuals Qty from SAPIBP1 Sample Model
ACTUALSQTY@REQUEST = SUM( "ACTUALSQTY@WKPRODLOCCUSTUOMTO" )

Note that the inputs for this calculation have ACTUALSQTY as a stored value:

Key Figure Select as Input Stored Value

ACTUALSQTY@PERPRODCUST X X

Calculations at Request Level

Context
In request level calculations, the inputs for the calculation are also at request level. (“Request level”) is a built-in planning level that represents the level at which a
user looks at the data [in the Microsoft Excel client or in Analytics].) When a key gure of this type is called at request level, the key gures in the calculation are rst
calculated at request level. The results are then returned to the key gure calculation. Request level calculations are typically used for calculation of ratios, prices,
and cost. The following example shows the calculation of sales forecast price, which is a weighted average calculation:

 Example
Request Level Calculation: Sales Forecast Price: SALESFORECASTPRICE@REQUEST =
IF(“SALESFORECASTQTY@REQUEST”=0,0,“SALESFORECASTREV@REQUEST”/“SALESFORECASTQTY@REQUEST”)

[Link] 52/128
12/3/2020
Note the following:

Request level calculations must have aggregation mode Custom.

Aggregation methods such as SUM and MIN are not allowed for request level calculations. Only request level inputs are allowed.

The inputs for request level calculations are not stored.

Input Key Figures: Request Level Calculation Sales Forecast Price

Key Figure Select as Input Stored Value

SALESFORECASTREV@REQUEST √

SALESFORECASTQTY@REQEST √

Calculations Across Different Planning Levels

In SAP Integrated Business Planning, you can easily perform calculations across different planning levels. Calculations are done in real time. For example, based on
changes to the sales forecast or to consensus demand, calculations are done for the complete supply side and for nance.

 Note
When a key gure contains calculations at different planning levels, the attributes of the output planning level must match the union of all the attributes of the
input planning levels. The calculation is going to be an inner join, that is, the output records will be the ones that have the same combination of values for the join
attributes in both input planning levels. Join attributes are attributes that both input planning levels contain, and they are root in at least one of them. All the
other common attributes are de ned by the join attributes. This means that if you want to get a result for all possible attribute value combinations, you need to
ensure that both input key gures contain the same value combinations for the join attributes.

If two input planning levels do not have common attributes, the output records will be the cross join of the two input data sets. We do not recommend this
calculation type, as it might increase the data volume signi cantly.

The following gure shows an example for the Total Demand Value key gure from the SAPIBP1 sample planning area:

Calculation Graph of Total Demand Value

TOTALDEMANDVAL@WKPRODLOCCURR is calculated from DEPENDENTDEMAND@WKPRODLOC and COSTPERUNIT@WKPRODLOCCURR.

For the calculation shown below, the same attributes must be de ned for the planning level WKPRODLOCCURR (root attributes: PERIODID5, PRDID, LOCID, and
CURRID plus non-root attributes) as for the planning levels WKPRODLOC (root attributes: PERIODID5, PRDID, and LOCID plus non-root attributes) and
WKPRODLOCCURR (root attributes: PERIODID5, PRDID, LOCID, and CURRID plus non-root attributes) combined.

Similarly, the WKPRODLOCCURRCURRTO output planning level must contain all the attributes (root attributes: PERIODID5, PRDID, LOCID, CURRID, and
CURRTOID, non-root attributes: PERIODID3 and others) from the MTHCURRCURRTO (PERIODID3, CURRID, and CURRTOID plus non-root attributes) and the

[Link] 53/128
12/3/2020
WKPRODLOCCURR (PERIODID5, PRDID, LOCID, and CURRID plus non-root attributes) input planning levels.

Calculation of Total Demand Value

TOTALDEMANDVAL@REQUEST = SUM("TOTALDEMANDVAL@WKPRODLOCCURRCURRTO")

TOTALDEMANDVAL@WKPRODLOCCURR = "DEPENDENTDEMAND@WKPRODLOC" * "COSTPERUNIT@WKPRODLOCCURR"

TOTALDEMANDVAL@WKPRODLOCCURRCURRTO = "EXCHANGERATE@MTHCURRCURRTO" * "TOTALDEMANDVAL@WKPRODLOCCURR"

Input Key Figures for the Calculation of Total Demand Value

Calculation to sum up the total demand value at request level:

TOTALDEMANDVAL@REQUEST = SUM("TOTALDEMANDVAL@WKPRODLOCCURRCURRTO")

Input Key Figures Use Stored Value

TOTALDEMANDVAL@WKPRODLOCCURRCURRTO

Calculation of the total demand value in a currency other than the base currency:

TOTALDEMANDVAL@WKPRODLOCCURRCURRTO = "EXCHANGERATE@MTHCURRCURRTO" * "TOTALDEMANDVAL@WKPRODLOCCURR"

Input Key Figures Use Stored Value

EXCHANGERATE@MTHCURRCURRTO Yes

TOTALDEMANDVAL@WKPRODLOCCURR

Calculation of the total demand value from the dependent demand quantity and the unit cost in base currency:

TOTALDEMANDVAL@WKPRODLOCCURR = "DEPENDENTDEMAND@WKPRODLOC" * "COSTPERUNIT@WKPRODLOCCURR"

Input Key Figures Use Stored Value

DEPENDENTDEMAND@WKPRODLOC Yes

COSTPERUNIT@WKPRODLOCCURR Yes

Defaulting to Another Key Figure

Context
You can con gure key gures in such a way that a key gure calculation defaults to another key gure value based on a condition. You can also de ne a chain of key
gures, where a key gure defaults to another defaulting key gure.

 Note
Chaining is not restricted to defaulting. As all de nitions of key gure are iterative, you can de ne a chain for any calculations.

 Example
In this example, the key gure Sales Forecast Qty is de ned as defaulting key gure for the key gure Consensus Demand Qty. If the data value for
Consensus Demand Qty is null or empty, the system defaults to Sales Forecast Qty.

As there is no stored value for Consensus Demand Qty, the value defaults to the value for Sales Forecast Qty: 2000.

[Link] 54/128
12/3/2020

Example

Note the following:

If there is no stored data value for Consensus Demand Qty, then the value “2000” from Sales Forecast Qty is used.

If you enter a value, such as “1000” for Consensus Demand Qty or save a value from planning views, this new value will override the default value.

To revert to a calculated value, simply set the value to null (empty) in the planning view and save your entries.

Steps
1. Create a key gure, for example, CONSENSUSDEMANDQTY at base planning level PERPRODCUST

2. Mark the key gure as Stored, Editable, and Calculated.

3. De ne a request level calculation and a calculation for the base planning level:

Request level calculation:

CONSENSUSDEMANDQTY@REQUEST = SUM(“CONSENSUSDEMANDQTY@PERPRODCUST”)

Calculation for the base planning level:

CONSENSUSDEMANDQTY@PERPRODCUST = IF(ISNULL(“CONSENSUSDEMANDQTY@PERPRODCUST”

“DEMANDPLANNINGQTY@PERPRODCUST”, “CONSENSUSDEMANDQTY@PERPRODCUST”)

 Note
Note that the input key gure can be either a stored or a calculated key gure. In this example, both inputs are stored key gures:

Key Figure Selected as Input Stored Value

CONSENSUSDEMAND@PERPRODCUST √ √

DEMANDPLANNINGQTY@PERPRODCUST √ √

[Link] 55/128
12/3/2020

 Note
Since the key gure is marked as both stored and calculated, on activation, the system generates a defaulting expression as follows:

IF(ISNULL(“CONSENSUSDEMANDQTY@PERPRODCUST”), “DEMANDPLANNINGQTY@PERPRODCUST”,
“CONSENSUSDEMANDQTY@PERPRODCUST”)

The system generates this expression provided the inputs for the calculation are stored key gures that are at the same base planning level as the Key gure
itself.

Simpli ed Key Figure Calculations

The following simpi ed key gure calculations are available:

IBP_CAGGR to perform cumulative aggregation across periods

For more information, see Cumulative Aggregation.

IBP_RAGGR to aggregate key gures across several time periods, for a speci ed time window

For more information, see Rolling Aggregation.

IBP_LPA to perform last period aggregation for a given time period

For more information, see Last Period Aggregation.

IBP_PERIODSHIFT to shift key gure values by time periods

For more information, see Period Shift.

IBP_WEIGHTEDAVG to calculate weighted average for a key gure.

For more information, see Weighted Average.

IBP_COVERAGE to calculate how many days or weeks the calculated projected stock will last based on the planned demand.

For more information, see Coverage.

IBP_CALENDAR to show working and non-working days by using values imported from SAP ERP calendars.

For more information, see Calendar.

IBP_GENERATE_MISSING_TP to generate missing time periods for the calculation horizon de ned by the parameters of the function.

For more information, see Generate Missing Time Periods.

To add a simpli ed key gure calculation to a key gure, go to the Planning Areas app, and select your planning area and key gure. Start typing IBP in the
expression editor, and choose the function you want to use from the dropdown. Then, enter the parameters as described in the respective sections below.

 Note
You cannot use these IBP functions in the calculation graph - at base planning level and below - of a key gure that is used either as the input or output of a
supply or forecast operator. You have the following options, if you want to use the IBP functions in the calculation graph of a supply or forecast operator:

Use these functions in calculations at planning levels other than the base planning level of the key gure in question.

Copy the result of these functions to another key gure and use it as the input or output of the supply or forecast operator.

Cumulative Aggregation
Cumulative aggregation is a chain of successive aggregations across periods. You can use the IBP_CAGGR function to con gure a cumulative aggregation in one
step.

Cumulative aggregation makes it easier to model typical cross-period calculations, such as projected stock, year-to-date and year-to-go calculations, or cumulative
average.

To create a cumulative aggregation calculation, use the IBP_CAGGR function like any other function (for example, SUM or MAX) in the calculation editor.

 Caution
For the cumulative aggregation to calculate correct values, the input key gure must have values for all time periods to be aggregated.

Make sure that key gure values exist for all periods to be aggregated. If this is not the case, upload NULL values for the periods where key gure values are
missing.

[Link] 56/128
12/3/2020

 Example
YTDATE_DEMAND@PERPRODCUST = IBP_CAGGR("DEMAND@PERPRODCUST",''SUM'',''FORWARD'',''PASTCURRENT'',6)

This is a year-to-date calculation, where the values of the DEMAND key gure at the PERPRODCUST planning level ("DEMAND@PERPRODCUST") from the past
and current periods (''PASTCURRENT'') are summed up (''SUM''), forward in time (''FORWARD''), with the cross-period aggregation restarting at the
beginning of each year (let's assume that year is time pro le level 6 in the time pro le assigned to the planning area).

The IBP_CAGGR function has four mandatory parameters and one optional parameter.

 Note
The values of the 2nd, 3rd, and 4th parameters must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single
quotation mark will result in an error during activation.

1. Input key gure at the input planning level (mandatory parameter)

Format: INPUTKEYFIGURE@INPUTPLANNINGLEVEL. The parameter value must be surrounded by double quotation marks.

2. Aggregation mode (mandatory parameter)

Possible values: SUM, AVG, MIN, or MAX.

This parameter speci es if a sum or an average should be calculated over the periods, or the minimum or maximum of the values should be taken forward.

3. Direction of the cumulative aggregation (mandatory parameter)

Possible values:

FORWARD: The calculation will aggregate the key gure values starting from a start period forward in time, for example, in a cumulative sum,
cumulative average or in a year-to-date calculation.

BACKWARD: The calculation will aggregate the key gure values starting from an end period backward in time, for example, in year-to-go calculations.

4. Horizon of the cumulative aggregation (mandatory parameter)

If separate key gures are used to calculate the past, present, and future values, this parameter lters the values, thus improves performance in the planning
view.

Possible values: PAST, PASTCURRENT, PASTCURRENTFUTURE, CURRENT, CURRENTFUTURE, and FUTURE.

If you use one key gure for cumulative aggregation, regardless of the horizon, use the PASTCURRENTFUTURE value for this parameter.

5. Time pro le level at which the cumulative aggregation should restart (optional parameter)

Speci es a time pro le level where cumulative aggregation should restart.

For example, you aggregate monthly values, and want to restart the aggregation at the start of the year. In this case, provide the time pro le level of the year
as the value of this parameter.

Possible values: numbers (positive integers) that correspond to the time pro le levels of the time pro le that is assigned to the planning area. Quotation
marks mustn't surround this parameter value.

 Note
When you de ne a cumulative aggregation, keep in mind the following:

The calculation must have one input only, which is the input key gure in the calculation expression.

The input and the output planning levels must be identical, and they cannot be REQUEST level.

When a calculation graph includes a cumulative aggregation, the topmost key gure in the calculation graph mustn't be editable.

The IBP_CAGGR function cannot be used in the calculation graph - at base planning level and below - of a key gure that is used either as the input or
output of a supply or forecast operator.

For more information about modeling requirements regarding cummulative aggregation, see section Checks for Cummulative Aggregation in Key Figures.

Related Information
Cumulative Sum, Cumulative Average, Minimum or Maximum
Year-To-Date and Year-To-Go Calculations
Projected Stock Calculations
Planning Areas

[Link] 57/128
12/3/2020

Last Period Aggregation

Use last period aggregation to display the key gure value for the last period in a given time period (for example, the last month of a quarter or the last month of a
year). You can use the IBP_LPA function to con gure last period aggregation in one step.

To use last period aggregation, use the IBP_LPA function in the calculation de niton of key gures in the Planning Areas app:
IBP_LPA("INPUTKFID@INPUTPLEVEL").

Last period aggregation must have exactly one input parameter, which is the key gure to be aggregated. This key gure must be the same as the input of the
calculation de nition. The input key gure can be stored and calculated as well. You cannot use IBP_LPA function without an input key gure as no defualt value is
provided. The result of last period aggregation is written to the output key gure.

Last period aggregation cannot be used in a REQUEST level calculation. Also, the IBP_LPA function cannot be used in the calculation graph - at base planning level
and below - of a key gure that is used either as the input or output of a supply or forecast operator.

For more information about modeling requirements regarding last period aggregation, see section Checks for Last Period Aggregation in Key Figures.

There are two ways to calculate last period aggregation depending on whether a root time pro le level is de ned in the output planning level.

Dynamic Aggregation
In case of dynamic last period aggregation, the time pro le level for which we aggregate is de ned during runtime. This means that the aggregated key gure can be
calculated on any time pro le level. The time aggregation will happen on the requested time granularity. Use this option when you want to ensure exibility at
querying key gures at request level.

To calculate dynamic aggregation, use the IBP_LPA function, and make sure that no root time pro le level is de ned in the output planning level of the aggregation
and in any of the calculations built on last period aggregation. Additionally, time pro le levels must be the same in the input and output planning levels.

Example

In this example, the input key gure shows the inventory level of a product on a daily basis. We use the IBP_LPA function to calculate the aggregated inventory
level; however, we do not de ne the time granularity at this point. The time pro le level for which aggregation takes place is de ned during runtime.

AGGRINVENTORY@PERPRODLOC = IBP_LPA("INVENTORY@DAYPRODLOC")

AGGRINVENTORY@REQUEST = SUM("AGGRINVENTORY@PERPRODLOC")

Static Aggregation
In case of static last period aggregation, aggregation is de ned for a speci c time pro le level. To calculate static aggregation, use the IBP_LPA function and
de ne a root time pro le level in the output planning level. The root time pro le level in the output planning level must be a possible parent of the root time pro le
level in the input planning level.

Example

In this example, the input key gure shows the inventory level of a product on a daily basis. First, we use the IBP_LPA fuction to calculate the aggregated inventory
level on a weekly basis (technical week), as all the other calculations built on this key gure are de ned for calendar and technical weeks. Then, on REQUEST level,
we can calculate the aggregated inventory for all time pro le levels that are built on technical week, for example, calendar week. In this case, aggregation to a higher
time pro le level will use the REQUEST level aggregation instead of last period aggregation.

AGGRINVENTORY@TECHWKPRODLOC = IBP_LPA("INVENTORY@DAYPRODLOC")

AGGINVENTORY@REQUEST = SUM("AGGINVENTORY@TECHWKPRODLOC")

Missing Inputs

[Link] 58/128
12/3/2020
The last period aggregation function does not generate missing time periods and key gure data in case the uploaded data is fragmented or missing. The input key
gure has to have data uploaded for the last time period. If there is no data available for the last period or for the entire time horizon, last period aggregation returns
no value.

Last period aggregation uses the time pro le of the planning area to nd out the related time periods. The IBP_LPA function works based on calendar only, it does
not consider product combinations at data upload. It means that if a product has no uploaded data for the requested last period, the function will return no value
and product either. It is the responsibility of the modeling expert to take care of key gure initialization or defualting when uploading and importing key gures.

Example: Missing key gure in the last period

In this example, there is no data uploaded for the last period (06.01.2019) in the given time period, so the IBP_LPA function returns no value.

Example: Missing key gure in product combination

In this example, there is no uploaded data for Product B and Product C for all time periods, so the IBP_LPA function returns value for Product A only.

The result of last period aggregation:

Aggregation and Disaggregation Rules

The same aggregation and disaggregation rules apply for last period aggregation as for any other type of aggregation, as described in section Checks for the
Aggregation and Disaggregation Mode in Planning Areas.

Last period aggregation is a time-based aggregation. From the available options, disaggregation mode Copy Value and proportionality No Proportional
Disaggregation and Same Key Figure - Stored Values return correct values after editing a key gure that was calculated using last period aggregation.

Example: Last period aggregation combined with Copy Value and No Proportional Disaggregation

[Link] 59/128
12/3/2020
Example: Last period aggregation combined with Copy Value and Same Key Figure - Stored Values

Related Information
Planning Areas

Rolling Aggregation

Use rolling aggregation to aggregate key gures across several time periods, for a speci ed time window. Instead of requesting an L script to create such an
aggregation, you can use the IBP_RAGGR function to con gure rolling aggregation in one step.

To use rolling aggregation, use the IBP_RAGGR function in the calculation de nition of key gures in the Planning Areas app. The parameters you de ne in the
calculation de nition specify the time window and the aggregation type of the rolling aggregation function.

Example
AGGREGATEDDEMAND@PERPRODLOC = IBP_RAGGR ("DEMAND@PERPRODLOC", ''SUM'', -1, 3, ''PASTCURRENTFUTURE'')

In this example, you can calculate the summary of the demand for the previous, actual, and upcoming months.

Parameters of the Rolling Aggregation (IBP_RAGGR) Function

The IBP_RAGGR function has ve mandatory parameters and one optional parameter.

 Note
The value of the 1st parameter must be surrounded by double quotation marks.

The values of the 2nd and 5th parameters must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation
mark will result in an error during activation.

1st parameter: input key gure at input planning level (mandatory)

The rst parameter of the IBP_RAGGR function is always the input key gure at the input planning level; for example, "DEMAND@PERPRODLOC".

2nd parameter: aggregation type (mandatory)

The second parameter de nes how the key gure is going to be aggregated over the time periods speci ed by the third and fourth parameters.

Possible values are MIN, MAX, SUM and AVG.

3rd parameter: start of rolling aggregation (mandatory)

[Link] 60/128
12/3/2020
The third parameter determines the start of the time window for which rolling aggregation is calculated for the input key gure. It speci es the starting time
period in relation to the actual time period, and it uses the root time period of the input planning level. It must be an integer.

Possible values:

Negative integer: rolling aggregation starts before the actual time period

Zero: rolling aggregation starts with the actual time period

Positive integer: rolling aggregation starts after the actual time period

For example, if the root time period is month, and the third parameter is -1, aggregation will always start in the previous month.

4th parameter: duration of rolling aggregation (mandatory)

The fourth parameter de nes the duration of the rolling aggregation, that is, the number of time periods for which the input key gure will be aggregated. It
has to be a positive integer.

For example, if the root time period is month, the third parameter is -1 and the fourth parameter is 3, the key gure will be aggregated for the previous,
actual, and the upcoming months.

5th parameter: calculation horizon (mandatory)

The fth parameter de nes the calculation horizon, which can control the output of the calculation. If separate key gures are used to calculate the past,
present, and future values, this parameter lters the values, thus improves performance in the planning view.

Possible values are PAST, PASTCURRENT, PASTCURRENTFUTURE, CURRENT, CURRENTFUTURE, and FUTURE.

If you use one key gure for rolling aggregation, regardless of the horizon, use the PASTCURRENTFUTURE value for this parameter.

Example

AGGREGATEDDEMAND@PERPRODLOC = IBP_RAGGR ("DEMAND@PERPRODLOC", ''SUM'', -1, 3, ''CURRENTFUTURE'')

In this example, the value of the calculation horizon is CURRENTFUTURE. This means that rolling aggregation is only calculated for the current and future
time periods, that is, the AGGREGATEDDEMAND@PERPRODLOC key gure does not have values for time periods before October 2018. However, values from
past time periods are used to calculate the values for current and future time periods.

6th parameter: restart of rolling aggregation (optional)

The last parameter is optional, and it speci es when rolling aggregation will restart. If you want to restart aggregation at certain time intervals, enter the time
pro le level at the end of which aggregation should stop and restart from 0.

Possible values: All time pro le levels that are assigned to the planning level, except for the root time pro le level.

For example, if you enter 6 (year), rolling aggregation will always restart at the rst root time period of the next year.

Example

AVERAGEDEMAND@PERPRODLOC = IBP_RAGGR ("DEMAND@PERPRODLOC", ''AVG'', -1, 3, ''PASTCURRENTFUTURE'', 6)

In this example, you can calculate the average demand for the previous, actual, and upcoming months, restarting at the rst month of every year.

Modeling Requirements for the Rolling Aggregation (IBP_RAGGR) Function

A rolling aggregation calculation must have exactly one input.

The input planning level and the output planning level of a rolling aggregation must be compatible with each other. That is, they must contain the same set of
attributes, including the same set of root attributes.

Rolling aggregations must be time dependent. That is, both the input planning level and the output planning level of the calculation must have one of the
PERIODID(n) attributes set as the time root attribute. The time root attribute mustn't be the PERIODID attribute.

The same PERIODID(n) attribute must be the time root attribute in both planning levels.

The output planning level must have master data type roots.

The IBP_RAGGR function must have values speci ed for the 5 mandatory parameters, and can have a value speci ed for one optional parameter.

[Link] 61/128
12/3/2020
The rst parameter must be the input key gure at the input planning level.

The value that is speci ed for the sixth parameter (time pro le level at which the rolling aggregation restarts) must exist in the time pro le assigned to the
planning area.

Only a time pro le level that is assigned to the planning level of the rolling aggregation as a time attribute (but not as a root attribute) can be speci ed as the
value of the sixth parameter of IBP_RAGGR (time pro le level at which the rolling aggregation restarts).

The IBP_RAGGR function cannot be used at REQUEST level.

When a calculation graph includes a rolling aggregation, the topmost key gure in the calculation graph mustn't be editable.

The IBP_RAGGR function cannot be nested in other calculations.

The IBP_RAGGR function cannot be used in the calculation graph - at base planning level and below - of a key gure that is used either as the input or
output of a supply or forecast operator.

Missing Inputs
You cannot use the IBP_RAGGR function without an input key gure as no default value is provided. The rolling aggregation function does not generate missing
time periods and key gure data in case the uploaded data is fragmented or missing. The input key gure has to have data uploaded for all time periods. There are
two cases of missing inputs.

Empty Value

If a time period for a planning object combination is missing, that time period is skipped and the value uploaded to the next time period is taken into account when
calculating rolling aggregation. Additionally, rolling aggregation is not calculated for the missing time period.

NULL Value

If the value of the input key gure is NULL, it is ignored during calculation, but the time window is not extended with another time period. You can default the NULL
value to 0 by adding another calculation if it is justi ed by your modeling requirements.

Example

AGGREGATEDDEMAND@PERPRODLOC = IBP_RAGGR ( "DEMAND@PERPRODLOC" , ''AVG'' , -1 , 3, ''PASTCURRENTFUTURE'')

In this example, time period March 2019 is missing. As shown in the table above, March 2019 is skipped and aggregation continues with the value uploaded to April
2019. That is, instead of calculating the average of January, February, and March, average is calculated for January, February, and April.

For time period August 2018, the value of the input key gure is NULL. In this case, August 2018 is ignored, that is, average is calculated for September and October
only.

Period Shift

Use period shift to shift key gure values by time periods. Instead of using complicated attribute transformations, you can use the IBP_PERIODSHIFT function to
con gure period shift in one step.

To use period shift, use the IBP_PERIODSHIFT function in the calculation de nition of key gures in the Planning Areas app: IBP_PERIODSHIFT(<KEY
FIGURE@PLANLEVEL>,<NUMBER OF PERIODS>,<AGGREGATION TYPE>).

Parameters of the Period Shift (IBP_PERIODSHIFT) Function

The IBP_PERIODSHIFT function has two mandatory parameters and one optional parameter:

1st parameter: input key gure at input planning level (mandatory)

The rst parameter of the IBP_PERIODSHIFT function is always the input key gure at the input planning level; for example,
"ACTUALSQTY@MTHPRODLOC". Period shift is based on the root time attribute of the planning level of the input key gure.

The value must be surrounded by double quotation marks.

2nd parameter: number of periods by which you want to shift the input key gure (mandatory)

You can specify the number of periods the following ways:

[Link] 62/128
12/3/2020
De ne the exact number of time periods, that is, use a constant.

Use an attribute, which is not a time pro le attribute, to de ne the number of time periods.

Use an attribute, which is a time pro le attribute, to de ne the number of time periods.

Use a key gure to specify the number of time periods.

If you use an attribute or key gure to specify the number of periods, the value must be surrounded by double quotation marks.

Con guration Flexibility Maintenance

Shift by a Constant * * *

Shift by an Attribute * ** **

Shift by a Time Pro le Attribute ** ** **

Shift by a Key Figure *** *** ***

3rd parameter: aggregation type (optional)

The third parameter de nes how the key gure value is going to be aggregated if the calculation uses values from more than one time period. If you shift a
key gure by a time pro le attribute or a key gure, you might end up with multiple values in some of the time buckets. In this case, you must use the third
parameter or create an aggregation calculation on top of the IBP_PERIODSHIFT function to de ne how the key gure value is calculated from the multiple
values of the given time buckets.

Possible values are MIN, MAX, SUM and AVG.

The value must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation mark will result in an error
during activation.

Shift by a Constant
Use a constant to de ne the number of periods by which you want to shift the input key gure. The number has to be either a positive integer (you shift into the
future) or a negative integer (you shift into the past). If you shift a key gure by a constant, you do not need to de ne the third parameter or create an aggregation
calculation on top of the IBP_PERIODSHIFT function.

Example

ACTUALSQTYOFFSET@REQUEST = SUM("ACTUALSQTYOFFSET@MTHPRODLOC")

ACTUALSQTYOFFSET@MTHPRODLOC = IBP_PERIODSHIFT("ACTUALSQTY@MTHPRODLOC", 12)

In this example, you can shift the value of actual quantity by 12 months in to the future.

Shift by an Attribute

Attribute Is Not a Time Pro le Attribute

Use an attribute, which is not a time pro le attribute, to de ne the number of periods by which you want to shift the input key gure. The type of the attribute has to
be integer. In this case, the attribute is not assigned to the time pro le; it is assigned to a master data type. If you shift a key gure by an attribute that is not a time
pro le attribute, you do not need to de ne the third parameter or create an aggregation calculation on top of the IBP_PERIODSHIFT function.

Example

ACTUALSQTYOFFSET@REQUEST = SUM("ACTUALSQTYOFFSET@MTHPRODLOC")

ACTUALSQTYOFFSET@MTHPRODLOC = IBP_PERIODSHIFT("ACTUALSQTY@MTHPRODLOC", "LEADTIME")

[Link] 63/128
12/3/2020
LEADTIME is an attribute to indicate lead times for supply planning for shifting key gures. Different products can have different lead times in terms of shipping
depending on the product characteristics (for example, size and weight). In this example, the value of LEADTIME is 1 for PRDID1, and 2 for PRDID2. That is, you
shift the value of actual quantity by 1 in case of product 1, and by 2 in case of product 2.

Attribute Is a Time Pro le Attribute

Use a time pro le attribute to de ne the number of periods by which you want to shift the input key gure. In this case, the attribute is assigned to the time pro le
for each period. If you shift a key gure by a time pro le attribute, you might end up with multiple values in some of the time buckets. In this case, you must use the
third parameter or create an aggregation calculation on top of the IBP_PERIODSHIFT function to de ne how the key gure value is calculated from the multiple
values of the given time buckets.

Example

ACTUALSQTYOFFSET@REQUEST = SUM("ACTUALSQTYOFFSET@MTHPRODLOC")

ACTUALSQTYOFFSET@MTHPRODLOC = IBP_PERIODSHIFT("ACTUALSQTY@MTHPRODLOC", "LAG")

In this example, LAG is a time pro le attribute, part of the MTHPRODLOC planning level, and it speci es the shipping time of a product from a manufacturer to the
distribution center. The value of LAG is 2 in 2019, whereas 1 in 2020.

Shift by a Key Figure

Use a key gure to de ne the number of periods by which you want to shift the input key gure. If you shift a key gure by another key gure, you might end up with
mutliple values in some of the time buckets. In this case, you must use the third parameter or create an aggregation calculation on top of the IBP_PERIODSHIFT
function to de ne how the key gure value is calculated from the multiple values of the given time buckets.

The planning level of the output key gure must be a subset of the planning level of the key gure used for shifting the input key gure.

Example

ACTUALSQTYOFFSET@MTHPRODLOC = IBP_PERIODSHIFT("ACTUALSQTY@MTHPRODLOC", "LAGDECIMAL@MTHPRODLOC", ''SUM'')

In this example, LAGDECIMAL@MTHPRODLOC is a key gure, and it speci es the lead time, which is different for different time periods and products. As a result,
the value of the ACTUALSQTYOFFSET key gure might be calculated from the values of more than 1 time periods, for example, as in the case of April 2019. For this
reason, the third parameter is also used to de ne how the key gure value is calculated from the multiple values of the given time periods. In this example, the sum
of the shifted values will be calculated for ACTUALSQTYOFFSET because the aggregation type is SUM in the function.

In case of decimals, the default rounding method is used. If you want to use another rounding mode, implement it in a separate calculation, as described in
Commonly Used Functions and Expressions.

Modeling Requirements for the Period Shift (IBP_PERIODSHIFT) Function

The rst parameter must be the input key gure at the input planning level.

A period shift calculation must have exactly one input if you shift by a constant or an attribute.

A period shift calculation must have exactly two inputs if you shift the input key gure by another key gure.

The input planning level and the output planning level of a period shift must be compatible with each other. That is, they must contain the same set of
attributes, including the same set of root attributes.

Period shift must be time dependent. That is, both the input planning level and the output planning level of the calculation must have one of the
PERIODID(n) attributes set as the time root attribute. The time root attribute mustn't be the PERIODID attribute.

The same PERIODID(n) attribute must be the time root attribute in both planning levels.

The IBP_PERIODSHIFT function cannot be used at REQUEST level.

When a calculation graph includes a period shift, the topmost key gure in the calculation graph mustn't be editable.

[Link] 64/128
12/3/2020
The IBP_PERIODSHIFT function cannot be nested in other calculations.

De ne the third parameter or create an aggregation calculation on top of the IBP_PERIODSHIFT function, if you shift the input key gure by a time pro le
attribute or key gure.

The IBP_PERIODSHIFT function must have values speci ed for the 2 mandatory parameters.

The IBP_PERIODSHIFT function cannot be used in the calculation graph - at base planning level and below - of a key gure that is used either as the input
or output of a supply or forecast operator.

Missing Inputs
You cannot use the IBP_PERIODSHIFT function without an input key gure as no default value is provided. The period shift function does not generate missing
time periods and key gure data in case the uploaded data is fragmented or missing. The input key gure has to have data uploaded for all time periods. If a time
period or a planning object combination is missing, that time period is skipped, and nothing is shifted. If the value of the input key gure is NULL or 0, it is shifted by
the de ned time periods.

If the second parameter, that is, the number of time periods, is empty, NULL or 0, the value of the input key gure is not shifted.

We recommend to upload data for all time periods, otherwise you might face performance issues.

Weighted Average
Instead of using several complex calculations, use the IBP_WEIGHTEDAVG function to calculate weighted average for a key gure in one step.

To calculate weighted average, use the IBP_WEIGHTEDAVG function in the calculation de nition of key gures in the Planning Areas app:
IBP_WEIGHTEDAVG(<KEY FIGURE@PLANLEVEL>,<KEY FIGURE@PLANLEVEL> or <ATTRIBUTE>,<TYPE OF NUMERATOR>)

Business Example

In this example, there are four products, all belong to the same product family (Smart TV). These products are shipped to three different markets: Germany, USA
and France. The same products have different prices at different locations. For each product/location combination, the following data is available: price, forecasted
quantity and forecasted revenue (calculated as price multiplied by forecasted quantity).

We can calculate the simple average price with the formula SUM(Price) / number of different product/location combinations (8); however, we are interested in
the weighted average price. The formula to calculate weighted average price is SUM(Price*Forecasted Qty) / SUM(Forecasted Qty). We can easily perform this
calculation on aggregated product family level with the IBP_WEIGHTEDAVG function using forecasted quantity as the weighting factor:

WEIGHTEDPRICE@REQUEST = IBP_WEIGHTEDAVG("STOREDPRICE@MTHPRODLOC", "FORECASTEDQTY@MTHPRODLOC",

''CALCULATEDNUMERATOR'')

Parameters of the Weighted Average (IBP_WEIGHTEDAVG) Function

The IBP_WEIGHTEDAVG function has three mandatory parameters:

1st parameter: input key gure at input planning level

The rst parameter of the IBP_WEIGHTEDAVG function is always the input key gure at the input planning level; for example,
STOREDPRICE@MTHPRODLOC. The sum of the rst parameter multiplied by the second parameter is the numerator of the calculation, for example,
SUM("STOREDPRICE@MTHPRODLOC"*"ACTUALSQTY@MTHPRODLOC").

The parameter value must be surrounded by double quotation marks.

[Link] 65/128
12/3/2020
2nd parameter: input key gure at the input planning level or attribute

The second parameter of the IBP_WEIGHTEDAVG function is the denominator of the calculation. In case a calculated numerator is used in the function, the
value of the second parameter is the denominator and the weight as well.

It is either an input key gure at the input planning level, for example, ACTUALSQTY@MTHPRODLOC or a master data type attribute (integer), for example,
WEIGHT. If it is a master data type attribute, it must be assigned to the input planning level of the rst key gure.

The parameter value must be surrounded by double quotation marks.

3rd parameter: type of numerator

The third parameter of the IBP_WEIGHTEDAVG function de nes whether the numerator is stored or calculated.

Possible values:

CALCULATEDNUMERATOR

The numerator is calculated; it is the sum of the rst parameter multiplied by the second parameter.

Example

WEIGHTEDPRICE = SUM(STOREDPRICE*ACTUALSQTY) / SUM(ACTUALSQTY)

STOREDNUMERATOR

The numerator is not calculated; it is simply the sum of the rst parameter. In this case, the numerator's value already includes a multiplication by the
weight.

Example

WEIGHTEDPRICE = SUM(STOREDREV) / SUM(ACTUALSQTY)

The value must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation mark will result in an error
during activation.

Example: Weighted Average with Calculated Numerator

In this example, we have two products (PRDID1 and PRDID2) available at three locations. For each product/location combination, we work with the following key
gures: actuals quantity and stored price. Actuals quantity and stored price are available in SAP IBP as stored or calculated key gures.

We want to calculate the weighted price for locations 1, 2 and 3 using stored price (STOREDPRICE) as the input for all three locations.

We calculate weighted average, using STOREDPRICE as the rst parameter and ACTUALSQTY as the second parameter in the IBP_WEIGHTEDAVG function.
Since we want STOREDPRICE to be multiplied by the weight, the value of the third parameter must be CALCULATEDNUMERATOR.

STOREDPRICE@REQUEST = SUM("STOREDPRICE@MTHPRODLOC")

ACTUALSQTY@REQUEST = SUM("ACTUALSQTY@MTHPRODLOC")

WEIGHTEDPRICE@REQUEST = IBP_WEIGHTEDAVG("STOREDPRICE@MTHPRODLOC","ACTUALSQTY@MTHPRODLOC",''CALCULATEDNUMERATOR'')

[Link] 66/128
12/3/2020

Let's take a look at FEB 2020, for example. For LOCID1, weighted price is calculated as follows: (50*100 + 100*200) / (50+100) = 166.6667

Example: Weighted Average with Stored Numerator

In this example, we have two products (PRDID1 and PRDID2) available at three locations again. For each product/location combination, we work with the following
key gures: actuals quantity and stored revenue. Both actuals quantity and stored revenue are available in SAP IBP as stored or calculated key gures.

We want to calculate the weighted price for locations 1, 2, and 3 using stored revenue (STOREDREV) as the input for all three locations.

We calculate weighted average, using STOREDREV as the rst parameter and ACTUALSQTY as the second parameter in the IBP_WEIGHTEDAVG function. Since
the numerator already contains a multiplication by weight, the value of the third parameter must be STOREDNUMERATOR. This means that in the
IBP_WEIGHTEDAVG function, the numerator is simply the sum of STOREDREV.

STOREDREV@REQUEST = SUM("STOREDREV@MTHPRODLOC")

ACTUALSQTY@REQUEST = SUM("ACTUALSQTY@MTHPRODLOC")

WEIGHTEDPRICE@REQUEST = IBP_WEIGHTEDAVG("STOREDREV@MTHPRODLOC","ACTUALSQTY@MTHPRODLOC",''STOREDNUMERATOR'')

Let's take a look at FEB 2020, for example. For LOCID1, weighted price is calculated as follows: (5000+20000) / (50+100) = 166.6667

Example: Weighted Average Based on Revenue and Quantity with Conversions

In this example, we have two products (PRDID1 and PRDID2) available at two customers and two locations. For each product/customer/location combination we
work with the following key gures: actuals quantity and actuals revenue.

[Link] 67/128
12/3/2020

We can calculate the actuals price (weighted average) for customer 1 and customer 2 using the IBP_WEIGHTEDAVG function:

1. Calculate ACTUALSQTY:

ACTUALSQTY@REQUEST = SUM("ACTUALSQTY@WKPRODLOCCUSTUOMTO")

ACTUALSQTY@WKPRODLOCCUSTUOMTO = "ACTUALSQTY@WKPRODLOCCUST" * "UOMCONVERSIONFACTOR@PRODUOMTO"

2. Calculate ACTUALSREV:

ACTUALSREV@REQUEST = SUM("ACTUALSREV@WKPRODLOCCUSTCURRCURRTOUOMTO")

ACTUALSREV@WKPRODLOCCUSTCURRCURRTO = "EXCHANGERATE@MTHCURRCURRTO" * "ACTUALSREV@WKPRODLOCCUSTCURR"

3. Calculate ACTUALSPRICE:

ACTUALSPRICE@REQUEST = IBP_WEIGHTEDAVG("ACTUALSREV@WKPRODLOCCUSTCURRCURRTO","ACTUALSQTY@WKPRODLOCCUSTUOMTO",
''STOREDNUMERATOR'')

 Note
As of the 2008 release, this example is available in the SAPIBP1 sample planning area.

Example: Weighted Average With an Attribute

In this example, we have two products (PRDID1 and PRDID2) available at one location. For both product/location combinations, the stored price (key gure) and
the weight (attribute) are available.

We can calculate weighted price with the IBP_WEIGHTEDAVG function, using the WEIGHT attribute as the second parameter. The attribute is assigned to the
Location master data type, and it is assigned to the MTHPRODLOC and MTHLOC planning levels.

WEIGHTEDPRICE@REQUEST = SUM("WEIGHTEDPRICE@MTHLOC")

WEIGHTEDPRICE@MTHLOC = IBP_WEIGHTEDAVG("STOREDPRICE@MTHPRODLOC", "WEIGHT", ''CALCULATEDNUMERATOR'')

Let's take a look at JAN 2020, for example. Weighted price is calculated as follows: (80*50 + 70*50) / (50+50) = 52.5

Modeling Requirements for the Weighted Average (IBP_WEIGHTEDAVG) Function

[Link] 68/128
12/3/2020
A weighted average calculation must have exactly 3 parameters.

The rst parameter must be the input key gure at the input planning level.

The second parameter must be either an input key gure at the input planning level or a master data type attribute.

If the second parameter is a master data type attribute (integer), it must be assigned to the input planning level of the rst key gure.

The third parameter must be either STOREDNUMERATOR or CALCULATEDNUMERATOR.

The IBP_WEIGHTEDAVG function cannot be nested in other calculations.

The planning level of the output key gure must be the subset of the union of the input planning levels.

The root time attributes of the input planning levels must be the same.

The input planning levels cannot be on REQUEST level.

If the second parameter of the IBP_WEIGHTEDAVG function is a key gure, the input planning levels must have at least one common non-time root
attribute that is included in the output planning level.

When a calculation graph includes a weighted average calculation, the topmost key gure in the calculation graph mustn't be editable.

 Note
Similarly to other aggregation functions (SUM, MIN, MAX and AVG), the IBP_WEIGHTEDAVG function does not impose lter blocks for attributes that are
dropped with the aggregation and removed from the planning level. This means that lters can be applied for these attributes before the aggregation, assuming
there is no other lter block in the calculations that are built on the IBP_WEIGHTEDAVG function.

Coverage

Use the IBP_COVERAGE function to calculate coverage for a key gure in one step. Using the coverage function, you can calculate how many days or weeks the
calculated projected stock will last based on the planned demand.

To use coverage, use the IBP_COVERAGE function in the calculation de nition of key gures in the Planning Areas app.

Example
DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''NEXTBUCKET'',
''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

In this example, we calculate days of coverage. On June 3, the projected stock (500) can cover the demand for 2 days, June 4 (300) and June 5 (200).

Parameters of the Coverage (IBP_COVERAGE) Function

The IBP_COVERAGE function has six mandatory parameters and one optional parameter. There is no connection between the parameters, that is, the value of one
parameter does not have an effect on the value of another parameter.

1st parameter: input key gure at input planning level (mandatory)

The rst parameter of the IBP_COVERAGE function is always the demand (input key gure) at the input planning level. Before performing the coverage calculation,
make sure that the demand is already available at the required planning level. If the value of the key gure is negative, it is counted as zero.

The parameter value must be surrounded by double quotation marks.

2nd parameter: input key gure at input planning level (mandatory)

The second parameter of the IBP_COVERAGE function is always the projected stock (input key gure) at the input planning level. Before performing the coverage
calculation, make sure that the projected stock is already available at the required planning level. If the value of the key gure is negative, it is counted as zero.

The parameter value must be surrounded by double quotation marks.

3rd parameter: number of working days (mandatory)

[Link] 69/128
12/3/2020
The third parameter de nes the number of working days for the given time period. First, coverage is calculated from the demand and projected stock for each
period, then the values are multiplied by the number of working days and summed up.

You have the following options to de ne the number of working days:

Use a key gure, for example, WORKDAYS@PERPRODLOC, to de ne the number of working days for each time period in your planning horizon. For example,
if demand and projected stock are on a monthly level, you can calculate coverage in days with the help of this key gure.

The parameter value must be surrounded by double quotation marks.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC" , "PROJECTEDSTOCK@PERPRODLOC" ,

"WORKDAYS@PERPRODLOC" , ''CURRENTBUCKET'', ''USEZEROSTOCK'' , ''PASTCURRENTFUTURE'')

In this example, demand and projected stock are on a monthly level, but we want to calculate the coverage in days. To do so, we use a key gure that de nes
the number of working days for each time period. When performing the calculation, we multiply the value of coverage with the number of working days for
each time period and then sum up the values. In March 2020, the projected stock (600) can cover the demand of March 2020 (400) and April 2020 (200).
The number of working days is 22 for both periods, so the days of coverage is 44 (2*22) for March 2020.

If the value of the key gure is negative, it is counted as zero.

Example: Number of Workdays Is Zero

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC" , "PROJECTEDSTOCK@PERPRODLOC" ,

"WORKDAYS@PERPRODLOC" , ''CURRENTBUCKET'', ''USEZEROSTOCK'' , ''PASTCURRENTFUTURE'')

In this example, the number of workdays is zero on week 4. When calculating the days of coverage for week 3, the projected stock of week 3 can cover the
demand of weeks 3, 4, and 5. However, since week 4 has no workdays, the days of coverage for week 3 is the sum of workdays of weeks 3 and 5.

De ne the number of working days with a positive integer. In this case, we assume that each time period in your planning horizon is made up of that many
working days.

Quotation marks must not surround this parameter value.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC" , "PROJECTEDSTOCK@PERPRODLOC" , 4 ,

''CURRENTBUCKET'', ''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

In this example, a week always consists of 4 workdays, so for each time period we multiply coverage value with 4 to calculate the days of coverage.

When no time-based multiplication is required, the value of the parameter must be 1. For example, if demand and projected stock are on a daily level, and
you want to calculate coverage in days as well, enter 1.

4th parameter: start of coverage (mandatory)

The fourth parameter determines whether coverage calculation starts with the demand value of the current or next bucket.

Possible values:

NEXTBUCKET

If the value of the projected stock key gure refers to the stock at the end of the day, calculate coverage starting from the next bucket using the
NEXTBUCKET parameter.

Example

[Link] 70/128
12/3/2020
DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''NEXTBUCKET'',
''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

CURRENTBUCKET

If the value of the projected stock key gure refers to the stock at the beginning of the day, calculate coverage starting from the current bucket using the
CURRENTBUCKET parameter.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1,

''CURRENTBUCKET'', ''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

The value must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation mark will result in an error during
activation.

5th parameter: zero demand coverage by zero stock (mandatory)

With the fth parameter, you can de ne whether zero stock can cover zero demand or not in your coverage calculation.

The value must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation mark will result in an error during
activation.

Possible values:

USEZEROSTOCK

If you want zero stock to cover zero demand in your coverage calculation, enter USEZEROSTOCK. In this case, when calculating days or weeks of coverage,
time periods with zero demand will be included in the calculation.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 7,

''CURRENTBUCKET'', ''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

In these examples, zero stock can cover zero demand. In the rst example, though the projected stock on week 3 is consumed by the demands of weeks 3, 4,
and 5; it can still cover the zero demands of weeks 6 to 12. As a result, the days of coverage is 70 for week 3.

In the second example, though the projected stock is zero on week 5, it can cover the demand of weeks 5 to 11.

If you have zero projected stock and zero demand for a given time frame, the days of coverage will equal the sum of the working days of the given time frame.

IGNOREZEROSTOCK

If you do not want zero stock to cover zero demand in your coverage calculation, enter IGNOREZEROSTOCK. In this case, when calculating days or weeks of
supply, time periods with zero demand will not be included in the calculation.

Example

[Link] 71/128
12/3/2020
DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 7,
''CURRENTBUCKET'', ''IGNOREZEROSTOCK'', ''PASTCURRENTFUTURE'')

As opposed to the previous examples, zero stock cannot cover zero demand in these examples. In the rst example, the projected stock on week 3 is
consumed by the demands of weeks 3, 4, and 5; which means that it cannot cover any further demands, not even zero demands. As a result, the days of
coverage is 21 for week 3.

In the second example, both demand and projected stock equal zero for weeks 5 to 11. Since zero projected stock cannot cover zero demand, days of
coverage will be zero as well for these weeks.

If you have zero projected stock and zero demand for a given time period, the days of coverage for that time period will be zero as well.

6th parameter: calculation horizon (mandatory)

The sixth parameter de nes the calculation horizon. If separate key gures are used to calculate the past, present, and future values, this parameter lters the
values; thus, coverage will only be calculated for the speci ed time horizon.

Possible values are PAST, PASTCURRENT, PASTCURRENTFUTURE, CURRENT, CURRENTFUTURE, and FUTURE.

If you use one key gure for coverage, regardless of the horizon, use the PASTCURRENTFUTURE value for this parameter.

The value must be surrounded by two pairs of single quotation marks. A double quotation mark instead of two single quotation mark will result in an error during
activation.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", "WORKDAYS@PERPRODLOC",

''CURRENTBUCKET'', ''USEZEROSTOCK'', ''CURRENTFUTURE'')

In this example, days of coverage is only calculated for current and future time periods.

7th parameter: full horizon covered (optional)

The seventh parameter is optional. You can use it to notify the planner that the projected stock of a time period is larger than the sum of the demands in all the
subsequent periods in the planning horizon.

It has to be an integer, possibly a high enough number (for example, 999), to indicate that there is missing demand or excessive stock.

If the parameter is not de ned and the projected stock is larger than the sum of the demands, the number of the remaining future time periods (or the sum of the
working days for the remaining future time periods) is displayed as the coverage.

Quotation marks must not surround this parameter value.

Example

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 7, ''CURRENTBUCKET'',

''USEZEROSTOCK'', ''PASTCURRENTFUTURE'', 999)

[Link] 72/128
12/3/2020

In both examples, we use the calculation horizon parameter to indicate excessive demand or lack of projected stock. We use 999 to indicate if projected stock is
larger than the sum of the demands. In the rst example, the projected stock on week 3 equals the sum of the demands for the remaining time periods, so the days
of coverage is the sum of the remaining days in the planning horizon. In the second example, the projected stock on week 3 is larger than the sum of the demands
for the remaining time periods, so the value of the days of coverage is 999 for week 3.

Using Aggregation
The input key gures (demand and projected stock) always have to be on the same aggregation level. However, if you want to calculate coverage on a different
aggregation level, we suggest that you aggregate the input key gures rst and then perform the calculation. For example, if you have demand and projected stock
on product/location level, however, you want to calculate coverage on a product family/location level, rst aggregate your input key gures to product
family/location level and then perform the IBP_COVERAGE function. Doing the other way round, that is, aggregating the coverage value might result in incorrect
data.

The same applies for time-based aggregation. If you have input key gures on weekly level and you want to calculate coverage in months, rst aggregate your input
key gures to monthly level and then perform the coverage calculation. If you want to calculate coverage in days with the same key gures, you can use the
IBP_COVERAGE function rst, and de ne the number of working days as the third parameter.

Modeling Requirements for the Coverage (IBP_COVERAGE) Function

The coverage calculation has 6 mandatory parameters and one optional parameter.

The IBP_COVERAGE function must have 2 or 3 input key gures.

The rst parameter must be an input key gure.

The second parameter must be an input key gure.

The third parameter must be an input key gure or a positive integer.

The input planning levels must be the same.

The input planning levels and the output planning level of a coverage calculation must be compatible with each other. That is, they must contain the same
set of attributes, including the same set of root attributes.

Coverage calculations must be time dependent. That is, both the input planning level and the output planning level of the calculation must have one of the
PERIODID(n) attributes set as the time root attribute. The time root attribute mustn't be the PERIODID attribute.

The same PERIODID(n) attribute must be the time root attribute in both planning levels.

The output planning level must have master data type roots.

The IBP_COVERAGE function cannot be nested in other calculations.

The IBP_COVERAGE function cannot be used at REQUEST level.

When a calculation graph includes a coverage calculation, the topmost key gure in the calculation graph mustn't be editable.

Missing Inputs
You cannot use the IBP_COVERAGE function without input key gures as no default values are provided. The coverage function does not generate missing time
periods and key gure data in case the uploaded data is fragmented or missing. The input key gures have to have data uploaded for all time periods. There are two
cases of missing inputs: empty value and NULL value.

Empty Value

If a time period for a planning object combination is missing, that time period is skipped and the value uploaded to the next time period is taken into account when
calculating coverage. Coverage is not calculated for the missing time period.

Example: Empty Value

[Link] 73/128
12/3/2020
DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''CURRENTBUCKET'',
''USEZEROSTOCK'', ''PASTCURRENTFUTURE'')

In this example, time period June 9 is missing. As shown in the table above, June 9 is skipped and coverage calculation continues with the value uploaded to June
10. Consequently, the days of coverage for June 8 is 2.

NULL Value

If the value of the planned demand is NULL, it is considered as zero. If the value of the projected stock is NULL, the value of days or weeks of coverage will be NULL
as well.

You can default the NULL value to 0 by adding another calculation if it is justi ed by your modeling requirements.

Example: Demand is NULL

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''CURRENTBUCKET'',

''USEZEROSTOCK'', ''PASTCURRENTFUTURE'', 999)

In this example, the value of planned demand is NULL from June 7, that is, planned demand is zero for June 7 and the remaining time periods. As a result, days of
coverage is 999 from June 6, as projected stock is larger than the sum of the demands for the remaining time periods.

Example: Projected Stock is NULL

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''CURRENTBUCKET'',

''USEZEROSTOCK'', ''PASTCURRENTFUTURE'', 999)

In this example, days of coverage is NULL on June 7 and June 8 because projected stock is NULL on these days as well. Now, let's take a look at June 5. Projected
stock is 600 on June 6, which can cover the demands from June 6 to June 10 (600=500+NULL+NULL+100+0). As a result, days of coverage is 5 on June 5.

Zero or Negative Values

If the value of the planned demand, projected stock or number of working days key gure is negative, it is counted as zero. The handling of zero demand and zero
projected stock depends on the value of the 5th parameter (zero demand coverage by zero stock), as discussed above.

If the value of the number of working days is negative or zero, then the coverage value is zero for the current period, that is, this period will not increase the value of
days of coverage. For more information, see the description of the third parameter above.

Example: Demand is Negative

DAYSOFSUPPLY@PERPRODLOC = IBP_COVERAGE("DEMAND@PERPRODLOC", "PROJECTEDSTOCK@PERPRODLOC", 1, ''CURRENTBUCKET'',

''USEZEROSTOCK'', ''PASTCURRENTFUTURE'', 999)

Negative demand is counted as zero demand. In this example, the demand is negative on June 1, which is calculated as zero. The projected stock on June 1 (600)
can cover the demand of June 1 (0) and 75% of the demand for June 2 (600), so days of coverage equals 1.75.

Calendar

[Link] 74/128
12/3/2020
Use the calendar function to count with different calendars (integrated from SAP ERP) in key gure calculations.

To use the calendar function, use the IBP_CALENDAR function in the calculation de nition of key gures in the Planning Areas app: IBP_CALENDAR(<KEY
FIGURE@PLANLEVEL, <CALENDAR ATTRIBUTE>)

Parameters of the Calendar (IBP_CALENDAR) Function

The IBP_CALENDAR function has two mandatory parameters:

1st parameter: input key gure at input planning level

The rst parameter of the IBP_CALENDAR function is always the input key gure at the input planning level, for example, DEMAND@DAYPRODLOC. It has
to be a read-only key gure.

The value must be surrounded by double quotation marks.

2nd parameter: calendar attribute

The second attribute of the IBP_CALENDAR function is a calendar attribute. It must be available at the planning level of the input key gure and must be
assigned to a master data type.

It has to be uploaded with values (calendar IDs) that are imported from SAP ERP and de ne working and non-working days.

The value must be surrounded by double quotation marks.

Output of the Calendar (IBP_CALENDAR) Function

The default output of the calendar function is 1 for working days and 0 for non-working days. However, you can change it, if it is required by your business needs.

For example, you might want to use 0 for working days and 1 for non-working days:

IF( IBP_CALENDAR("DEMAND@DAYPRODLOC", "CALID") = 1, 0, 1)

The IBP_CALENDAR function can be nested in other calculations.

Example: Single Calendar Calculation

In this example, we calculate the value of the DEMANDADJUSTED key gure for two locations (Berlin and Shanghai) using the DEMANDCALENDARID calendar
attribute. There are 2 calendars integrated from SAP ERP into this calendar attribute:

Chinese calendar (CN)

German calendar (DE)

The DEMANDCALENDARID calendar attribute is assigned to the LOCATION master data type.

If a certain day is a working day, the output of the calendar function is 1; if it is a non-working day, the output is 0. As you can see below, there is a difference
between the two calendars for the 24th, 25th and 31st of December. They are working days in China, but not in Germany. The 20th, 26th and 27th of December are
weekend days, so the output of the function is 0 in both cases.

Chinese Calendar (CN)

Calendar ID Date IBP_CALENDAR("DEMAND@DAYPRODLOC",

"DEMANDCALENDARID")

CN 2020.12.20. 0

CN 2020.12.21. 1

CN 2020.12.22. 1

CN 2020.12.23. 1

CN 2020.12.24. 1

CN 2020.12.25. 1

CN 2020.12.26. 0

CN 2020.12.27. 0

CN 2020.12.28. 1

CN 2020.12.29. 1

CN 2020.12.30. 1

[Link] 75/128
12/3/2020

Calendar ID Date IBP_CALENDAR("DEMAND@DAYPRODLOC",

"DEMANDCALENDARID")

CN 2020.12.31. 1

German Calendar (DE)

Calendar ID Date IBP_CALENDAR("DEMAND@DAYPRODLOC",

"DEMANDCALENDARID")

DE 2020.12.20. 0

DE 2020.12.21. 1

DE 2020.12.22. 1

DE 2020.12.23. 1

DE 2020.12.24. 0

DE 2020.12.25. 0

DE 2020.12.26. 0

DE 2020.12.27. 0

DE 2020.12.28. 1

DE 2020.12.29. 1

DE 2020.12.30. 1

DE 2020.12.31. 0

Counting with these outputs of the calendar function, the value of the DEMANDADJUSTED key gure is the following for the different locations.

DEMANDADJUSTED@REQUEST = SUM("DEMANDADJUSTED@DAYPRODLOC")

DEMANDADJUSTED@DAYPRODLOC = IBP_CALENDAR("DEMAND@DAYPRODLOC", "DEMANDCALENDARID") * "DEMAND@DAYPRODLOC"

Shanghai has the Chinese calendar assigned to it; whereas Berlin has the German calendar assigned to it. Since the 24th, 25th and 31st of December are non-
working days in Germany, the value of the DEMANDADJUSTED key gure is 0 (0 * DEMAND) for the German location. However, they are working days in China, so
the value of the DEMANDADJUSTED key gure is 150 (1 * DEMAND) for Shanghai.

Example: Multiple Calendar Calculations

In this example, we calculate the value of the PRODUCTIONADJUSTED key gure for a planned maintenance affecting a set of product/location combinations. To
do so, we need to maintain different calendars for different locations and different products as well. We can easily do that by using two calendar functions with two
different calendar attributes, LOCCALID and PRODCALID, in one calculation. LOCCALID is assigned to the LOCATION master data type, and PRODCALID is
assigned to the PRODUCT master data type.

PRODUCTIONADJUSTED@REQUEST = SUM("PRODUCTIONADJUSTED@DAYPRODLOC")

PRODUCTIONADJUSTED@DAYPRODLOC = IBP_CALENDAR("PRODUCTION@DAYPRODLOC", "PRODCALID") *

IBP_CALENDAR("PRODUCTION@DAYLOC", "LOCCALID") * PRODUCTION@DAYPRODLOC"

Modeling Requirements for the Calendar (IBP_CALENDAR) Function

The calendar function must have exactly 2 parameters.

The rst parameter must be the input key gure at the input planning level.

The second parameter must be a calendar attribute.

[Link] 76/128
12/3/2020
The calendar attribute has to be added to the planning level of the input key gure.

The input planning levels and the output planning level must have the same set of time attributes, including the time root attribute.

The calendar function cannot be used on REQUEST level.

When a calculation graph includes a calendar function, the topmost key gure in the calculation graph mustn't be editable.

Missing Inputs
The input key gure must have data for all time periods and planning objects, as the IBP_CALENDAR function does not provide default values. The calendar
function does not generate missing time periods and key gure data in case the uploaded data is fragmented or missing. The input key gure has to have data
uploaded for all time periods. There are two cases of missing inputs: empty value and NULL value.

Empty Value

If a time period for a planning object combination is missing, that time period is skipped. The calendar function is not calculated for the missing time period.

NULL Value

If the value of the input key gure is NULL, the result of the IBP_CALENDAR function will be NULL as well. You can default the NULL value to 0 by adding another
calculation if it is justi ed by your modeling requirements.

Related Information
Planning Calendars

Generate Missing Time Periods

Use the IBP_GENERATE_MISSING_TP function to generate missing time buckets for the calculation horizon de ned by the parameters of the function.

To generate missing time periods, use the IBP_GENERATE_MISSING_TP function in the calculation de nition of key gures in the Planning Areas app:
IBP_GENERATE_MISSING_TP(<KEY FIGURE@PLANLEVEL>,<START OF CALCULATION HORIZON>,<END OF CALCULATION HORIZON>)

Using the generate missing time periods function, you can generate time periods for the calculation horizon de ned by the second and third parameters of the
function. The input key gure values are kept intact, the generated time periods have a default NULL value. Missing time periods are generated runtime; no data is
stored in the database. The generated combinations are only stored until the key gures that use the input key gure are calculated.

The IBP_GENERATE_MISSING_TP function only affects the time dimension. It does not generate combinations in other dimensions like product, location, or
customer.

The generate missing time periods function does not create a lter block in the time dimension. This means that if there are no calculations built on the
IBP_GENERATE_MISSING_TP function that create a time lter block, you can use time lters effectively. However, if there is at least one calculation in the
calculation graph that imposes a time lter block, you cannot use time lters, that is, missing periods will be generated for each combination in the planning
horizon.

If you want to generate missing time periods for a key gure combination, you must ensure that there is at least one entry for the given key gure combination in
the input data set as described below:

If there are no calculations built on the IBP_GENERATE_MISSING_TP function that create a time lter block, the entry must exist within the time horizon
of your planning view in the SAP Integrated Business Planning, add-in for Microsoft Excel.

If there is at least one calculation built on the IBP_GENERATE_MISSING_TP function that imposes a time lter block, the entry must exist within the
planning horizon de ned in the Planning Areas app.

 Caution
The IBP_GENERATE_MISSING_TP function is used most often as an input of L script and cross-period calculations. These calculations impose a time lter
block that is inherited by the generate missing time periods calculation; that is, you cannot reduce data volume in the IBP_GENERATE_MISSING_TP
calculation by ltering. Furthermore, the function generates time periods for all possible key gure combinations for which you have at least one entry available.
As a result, you might experience runtime performance issues and might run out of memory as well. For this reason, it is essential that you test the performance
with productive data.

To avoid performance issues, we suggest that you use the IBP_GENERATE_MISSING_TP function as close to the calculations that impose lter blocks as
possible. To improve performance, use other effective lters on the REQUEST-level calculations.

For more information about lter blocks and effective ltering, see Filter Blocks.

Example

[Link] 77/128
12/3/2020
In this example, we generate missing time periods for the November 2019 - November 2021 period. The current month is November 2020. We have the following
time periods and data available for the ACTUALSREV key gure at the base planning level:

We use the IBP_GENERATE_MISSING_TP function to generate the missing time periods.

ACTUALSREV@MONTHPRODLOCCUSTCURRCURRTO = IBP_GENERATE_MISSING_TP("ACTUALSREV@MONTHPRODLOCCUSTCURRCURRTO", -12, 12)

As a result, te following data set is generated in the database tables:

As a result, the existing input key gure values stay the same, and the missing time periods are generated with a default NULL value for the calculation horizon.
Please keep in mind that no data is stored in the database. The combinations are stored in the memory until the topmost key gures in the calculation graph of the
ACTUALSREV key gure are calculated.

Parameters of the Generate Missing Time Periods (IBP_GENERATE_MISSING_TP) Function

The IBP_GENERATE_MISSING_TP function has three mandatory parameters:

1st parameter: input key gure at input planning level

The rst parameter of the IBP_GENERATE_MISSING_TP function is always the input key gure at the input planning level. It has to be a stored key gure.
For the existing time periods, the value of the input key gure stays the same, whereas the generated time periods have a default NULL value.

The parameter value must be surrounded by double quotation marks.

2nd parameter: start of calculation horizon

The second parameter de nes the start of the time window for which missing time periods are generated. It speci es the starting time period in relation to
the current time period, and it uses the root time period of the base planning level of the input key gure. It must be an integer.

For example, if the root time period is month, and the third parameter is -12, the generation of missing time periods will always start 12 months before.

[Link] 78/128
12/3/2020
Quotation marks must not surround this parameter value.

3rd parameter: end of calculation horizon

The third parameter de nes the end of the time window for which missing time periods are generated. It speci es the last time period in relation to the
current time period, and it uses the root time period of the base planning level of the input key gure. It must be an integer.

For example, if the root time period is month, and the third parameter is 12, the generation of missing time periods will always end in 12 months' time. The
third parameter must be larger than or equal to the second parameter.

Quotation marks must not surround this parameter value.

Example: Time Period Generation Without a Filter Block

In this example, we calculate the average revenue for the November 2019 - November 2021 period. The current month is November, 2020. We have the following
time periods and data available for the ACTUALSREV key gure at the base planning level:

First, we generate the missing time periods for the calculation horizon. Since the IF statement and the AVG function, built on the IBP_GENERATE_MISSING_TP
function, do not impose lter blocks, data is ltered based on the time horizon of the planning view before the missing time periods are generated.

ACTUALSREV@MONTHPROD = IBP_GENERATE_MISSING_TP("ACTUALSREV"@MONTHPROD", -12, 12)

As a result, the following data set is generated in the database tables:

As you can see in the gure, the combinations are already ltered according to the calculation horizon. Time buckets are only created for the November 2019 -
November 2021 period. August 2019 and February 2022 fall outside of the calculation horizon, so data is not stored for these periods in the memory. Furthermore,
since there is no exsisting combination for Pedal in the calculation horizon, time periods are not generated for this product at all.

Then, we continue with an IF statement on the MONTHPROD planning level.

AVGREVENUE@MONTHPROD = IF(ISNULL("ACTUALSREV@MONTHPROD"), "ACTUALSREVPRIORYEAR@MONTHPROD",

"ACTUALSREV@MONTHPROD")

[Link] 79/128
12/3/2020

Finally, we calculate the average on REQUEST level.

AVGREVENUE@REQUEST = AVG("AVGREVENUE@MONTHPROD")

Example: Time Period Generation With a Filter Block

In this example, we calculate rolling aggregation for the ACTUALSREV key gure. The current month is November, 2020. We have the following time periods and
data available for the ACTUALSREV key gure at the base planning level:

First, we generate the missing time periods. As opposed to the previous example, the IBP_RAGGR function creates lter blocks in the calculation chain. This
means that we can only lter after the IBP_RAGGR function has been performed; that is, missing time periods are generated for all possible combinations.

ACTUALSREV@MONTHPROD = IBP_GENERATE_MISSING_TP("ACTUALSREV"@MONTHPROD", -12, 12)

[Link] 80/128
12/3/2020
As a result, the following data set is generated in the database tables:

As you can see in the gure, time periods are created for all combinations, there is no ltering yet. Periods that fall outside of the calculation horizon (August 2019
and February 2022) are stored, and combinations for Pedal are created and stored. As a result, there are more time buckets and more data generated than in the
previous example; which might cause performance issues.

Then, we calculate rolling aggregation.

AVGREVENUE@MONTHPROD = IBP_RAGGR("ACTUALSREV@MONTHPROD", ''AVG'', 0, 1, ''PASTCURRENTFUTURE''')

[Link] 81/128
12/3/2020
Now, that the calculation that imposes the lter block has been performed, we can lter the data set. As a result, time periods August 2019 and February 2022 are
removed as they fall outside of the calculation horizon.

Finally, we calculate the rolling aggregation on REQUEST level.

AVGREVENUE@REQUEST = SUM("AVGREVENUE@MONTHPROD")

Modeling Requirements for the Generate Missing Time Periods (IBP_GENERATE_MISSING_TP) Function
The generate missing time periods function must have exactly 3 parameters.

The rst parameter must be the input key gure at the input planning level.

The third parameter must be larger than or equal to the second parameter.

The calculation horizon de ned by the second and third parameter must fall within the planning horizon.

The input planning level and the output planning level of a generate missing time periods function must be compatible with each other. That is, they must
contain the same set of attributes, including the same set of root attributes.

The generate missing time periods function must be time dependent. That is, both the input planning level and the output planning level of the calculation
must have one of the PERIODID(n) attributes set as the time root attribute. The time root attribute mustn't be the PERIODID attribute.

The same PERIODID(n) attribute must be the time root attribute in both planning levels.

The output planning level must have master data type roots.

The IBP_GENERATE_MISSING_TP function cannot be nested in other calculations.

The IBP_GENERATE_MISSING_TP function cannot be used at REQUEST level.

When a calculation graph includes a generate missing time peridos function, the topmost key gure in the calculation graph mustn't be editable.

Using Attributes in Key Figure Calculations

You can use attributes in calculation expressions. Please note the following:

An attribute that is used in a calculation must belong to the planning level of at least one of the inputs to the calculation.

An attribute cannot be used in a calculation if all the inputs are speci ed at calculation level.

 Note

[Link] 82/128
12/3/2020
This is no longer required with the new, enhanced version of planning area activation. For more information about enhanced activation and whether it is
used in your system, see Enhanced Version of Planning Area Activation.

Attributes, just like KF@PL forms are to be surrounded by double quotation marks in the calculation expression, for example: "RESTYPE". However, if you use a
constant in an expression, you must use two (!) single quotation marks before the attribute value and two (!) single quotation marks after the attribute value (for
example, ''constant'').

 Caution
Please note that a double quotation mark (") won't work, even though it looks similar to a combination of two single quotation marks.

 Example
HUSAGE@WKRESLOC = IF ("RESTYPE" = ''STORAGE'', "HCAPAUSAGE@WKRESLOC", "HPCAPAUSAGE@WKRESLOC")

 Note
String constants are always in upper case in calculations. If you want to compare the string constant with the actual attribute value in a calculation, use the
UPPER function to change the attribute value to upper case.

Example: KF1@PERPRODCUST = IF(UPPER(''ATTR1'') = ''APPROVED'', "KF2@PERPRODCUST", NULL)

Using Time Periods in Key Figure Calculations

You may sometimes need to de ne calculations that are based on criteria relating to time periods.

For example, imagine that for key gure Sales Forecast Qty, you want to show the Actuals Qty for time periods that lie in the past:

Actuals Qty Shown for Sales Forecast Qty in Past Time Periods

Key Figure Current Time Period Current Time Period Current Time Period Current Time Period Current Time Period
-2 -1 +1 +2

Prod1/Cust1 Actuals Qty 100 120

Sales Forecast 100 120 150 175 100

Qty

To achieve this, de ne the following calculation expression:

SALESFCSTQTY@BASEPLANNINGLEVEL = IF(PERIODIDn >=$$PERIODIDnCU$$,

SALESFCSTQTY@BASEPLANNINGLEVEL,ACTUALSQTY@BASEPLANNINGLEVEL)

 Note
If you have key gures at different planning levels (Week, Month, Quarter, Year), you might want to use PERIODIDn.:

$$PERIODIDnCU$$: Fixed variable for the current period.

$$PERIODIDnFR$$: First period of the given planning horizon.

$$PERIODIDnTO$$: Last period of the given planning horizon.

PERIODIDn: Time period attribute

"n" refers to the time period level. For example, in a planning area where the time pro le has the levels "Week", "Month", "Quarter", and "Year", the period
IDs would be as follows:

Period ID Time Period Level

PERIODID0 Week

PERIODID1 Year

PERIODID2 Quarter

PERIODID3 Month

If Sales Forecast Qty is de ned at the base planning level with Month as the root, then PERIODIDn would be replaced by PERIODID3.

[Link] 83/128
12/3/2020
Related Information
PERIODID and PERIODID(n) Attributes in Time Pro le Levels

Exceeding the 12-Digit Integer and 6-Digit Decimal Limit in Key Figure Calculations

The maximum number of digits is 18 in SAP IBP. Values can consist of maximum 12-digit integers and 6-digit decimals. However, it might happen that the results
(both intermediate and nal) of key gure calculations would require more than 12 integers or 6 decimals. Let's see a couple of examples and solution proposals for
this issue.

Exceeding the 12-Digit Integer Limit

In this case, the result (intermediate or nal) of a calculation would consist of more than 12 digits. Therefore, you receive an error message and the calculation is not
performed.

Example

We have three key gures with the following values:

KF1=10000000000

KF2=100

KF3=1000

We want to perform the following calculations:

KF1*KF2

The result would be 1000000000000. This value has 13 digits, however, SAP IBP can only work with integers up to 12 digits. As a result, you receive a
numeric over ow error.

KF1*KF2/KF3

The result would be 1000000000. This number consists of less than 12 digits, however, the intermediate value KF1*KF2 would need 13 digits. This is not
possible in SAP IBP, therefore, you receive an error message again.

Solution

Remodel your calculations so that the results of the calculations do not exceed the limit. You can do that, for example, by changing the unit of measures or the unit
of currency. The most common cause of numeric over ow is the conversion of income to another currency unit. If this is the case, use currency conversion to solve
the problem.

If it is only the intermediate value that exceeds the limit of 12 digits, you can also use different dimensions for the key gures. For example in the case of
KF1*KF2/KF3, you can divide the value of KF2 by 1000 and then multiply the nal result by 1000. This way you will not have values of more than 12 digits.

Exceeding the 6-Digit Decimal Limit

Decimal values in SAP IBP can consist of up to 6 digits. If a number has more than 6 decimals, the rst 6 is kept and the rest is simply cut off without rounding the
value. For example, in case of the decimal number 123,123456789, the system will store and work with 123,123456.

Result is Lower Than Expected

Example

We work with the following calculations:

ACTUALSPURCHASE@REQUEST = SUM("ACTUALSPURCHASE@DAYPRODLOC")

ACTUALSPURCHASE@DAYPRODLOC = "ACTUALSPURCHASE@DAYPRODLOC"/3

In this example, we store values on daily level, however, we have values on weekly level. For example, the value of ACTUALSPURCHASE is 30 for week 1. To calculate
ACTUALSPURCHASE@DAYPRODLOC we need to divide 30 by 7 (number of weekdays), and then by 3.

30/7/3=1.428571428571429.

Since SAP IBP can only work with values with up to 6 decimals, value 1.428571 is going to be stored. Then, we query ACTUALSPURCHASE on a weekly level. As a
result, the daily value is aggregated (1.428571*7), and the result is 9.999997. However, this is not accurate; the result should be 10 (30/3).

Solution 1: Remodel Your Calculations (Recommended)

[Link] 84/128
12/3/2020
Remodel your calculations so that the intermediate values do not exceed the limit by using different dimensions for the key gures. You can again change the unit of
measures or unit of currency, or multiply the value of the kef gure by 1000 and divide by 1000 after the calculation has been performed. Keep in mind that on the
one hand you cannot exceed the limit of 6-digit decimals, but on the other hand you cannot have more than 12-digit integers.

Solution 2: Round Values in the Back End

Use rounding if there is a disaggregation in the key gure calculation to achieve exact results. To do so, add one of the rounding functions to the SUM function on
REQUEST level.

For more information about the rounding functions, see Commonly Used Functions and Expressions.

Solution 3: Round Values in SAP IBP, Add-in for Microsoft Excel

Set the number of decimals to be displayed to 6, so that it is the same as in SAP IBP. You can also add rounding functions to the cells in Microsoft Excel.

We suggest that you represent intermediate results step-by-step in Microsoft Excel instead of having one complex calculation in one step. This way, you can easily
check whether all intermediate values t into the 6-digit decimal (and 12-digit integer) limit.

Result is Higher Than Expected

Example

In this example, the number of decimal places is to 2 in Microsoft Excel. As result, value 999.999 is displayed as 1000.00.

Solution

Set the number of decimals to be displayed to 6 and set the rounding precision in Microsoft Excel.

Business Meaning

In con guration, you can assign business meaning to attributes and key gures to provide a semantic connection between the attribute ID or key gure ID that you
specify and the code. The use of business meaning replaces the need to use hard-coded attribute and key gure IDs. This means that you do not have to follow
SAP's naming conventions for naming key gures and attributes to be able to let the system know what purpose you want to use a certain key gure or attribute.

When setting business meanings for attributes, keep in mind the following:

You can use a business meaning once in a planning area.

If you select a description business meaning for an attribute, you must also select its corresponding ID business meaning for a different attribute in the
planning area.

If an attribute has a description attribute in the master data type, these two attributes can only have the same relationship in the planning area. The
assigned attribute that has the description attribute must have ID business meaning and its description attribute must have the corresponding description
business meaning in the planning area. For example, if in the PRODUCT1 master data type ATTR2 is the description attribute of ATTR1, then ATTR1 has
Product ID business meaning and ATTR2 has Product Description business meaning in the PA1 planning area.

Business meaning is used in the integration of promotion data. The Analyze Promotions app considers data from planning areas that have attributes and key
gures with the relevant business meaning assigned. For more information, see Setting Up a Planning Area for Integrating Promotion Data.

 Example
You create a key gure with the following details:

Key gure name: UPLIFT

Key gure description: Promotion Uplift

Business meaning: Promotion Uplift (Source)

As you assign the business meaning Promotion Uplift (Source) to the key gure, the system considers the planning area that the key gure belongs to as
possibly relevant for the integration of promotion data. If other prerequisites are also met, you can use the planning area for promotions.

The SAP6 sample planning area for demand contains attributes and key gures that have business meaning assigned to them. For more information, see SAP6
Sample Planning Area for Demand.

Planning Operators
A planning operator uses an algorithm to compute large amounts of key gure data within a planning session. You can schedule a planning operator to be processed
in the background.

SAP delivers the following planning operator types:

[Link] 85/128
12/3/2020

Planning Operator Type Name Use

ADVSIM Advanced Simulation Preprocessing and postprocessing operations for

simulation

COPY Copy Key Figure Data Copy values of source key gures to target key gures in
the same version (base or other) of a planning area.

DISAGG Copy and Disaggregate Key Figure Data Copy and disaggregate values of source key gures to
target key gures in the same version (base or other) of
a planning area.

DDR Demand-driven Replenishment Run demand-driven replenishment (DDR) operators.

As of SAP Integrated Business Planning 1911, you de ne

demand-driven replenishment pro les for demand-
driven replenishment algorithms instead of DDR
planning operators. You do this using the Demand-
Driven Replenishment Pro le app.

For more information, see Planning Pro les for Demand-

Driven Replenishment.

Note the following about upgrading from a lower release

to 1911 or higher:

All DDR planning operators created prior to 1911

will still be available in display mode in the
Planning Areas app.

Existing DDR planning operators that are

assigned to a planning area will be migrated
automatically to the new app and will be
available there as pro les.

Existing planning operators that are not

assigned to a planning area will not be
automatically migrated.

IO Inventory Optimization Run inventory optimization for a given supply chain

network.

SCM S&OP Run global supply planning across your supply chain
network.

As of SAP Integrated Business Planning 1802, you de ne

S&OP Operator Pro les for the time-series-based
supply planning algorithms instead of SCM planning
operators. You do this using the S&OP Operator Pro les
app.

For more information, see Planning Pro les for Time-

Series-Based Supply Planning.

Note the following about upgrading from a lower release

to 1802 or higher:

All SCM planning operators created prior to 1802

will still be available in display mode in the
Planning Areas app.

Existing SCM planning operators that are

assigned to a planning area will be migrated
automatically to the new app and will be
available there as pro les.

Existing planning operators that are not

assigned to a planning area will not be
automatically migrated.

SNAPSHOT Snapshot Take a snapshot of a prede ned set of key gures.

SNAPSHOTREDO Redo Snapshot Overwrite the most recent snapshot with a new
snapshot of a prede ned set of key gures.

Creating a Planning Operator

Prerequisites

[Link] 86/128
12/3/2020
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
You can create most planning operator types in the Planning Operators app. Snapshot operators and redo snapshot operators, however, are generated when you
create a snapshot de nition on the Snapshots tab of the Planning Areas app.

Procedure
1. In the Planning Operators app, select a planning operator type from the list of planning operator types on the left side of the screen.

2. Select + (Add Planning Operators).

You can specify the following pieces of information for your planning operator:

Planning operator name and description

Required modes (one or more): interactive, batch, or lter mode

Planning operator parameters

For more information, see the following table:

Field Description

Interactive Mode Speci es whether the user can run the planning operator interactively in the
current planning session in IBP Excel add-in (by choosing Simulate and then the
operator name).

Batch Mode Speci es whether the user can schedule the planning operator to run in the
background (either immediately or as a scheduled job).

Filter Mode Speci es whether the user can use lters when running or scheduling the planning
operator in IBP Excel add-in.

For example, if you activate the lter mode for the planning operator type
SNAPSHOT, the user can use a stored lter or create an ad-hoc lter when taking
the snapshot from IBP Excel add-in. Only the data that satis es the lter is
included in the snapshot.

De ne Parameters Parameters that are relevant for the planning operator (parameter name and
parameter value).

3. Save your changes.

Next Steps
Once you created and de ned your planning operators, assign them to a planning area. For more information see Assigning a Planning Operator to a Planning Area.

Assigning a Planning Operator to a Planning Area

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Make sure you have already created planning operators for the planning operator types available in the system. For more information see Creating a Planning
Operator.

Procedure
1. Open the Planning Areas app.

2. Select your planning area from the list of planning areas and open it.

3. Go to the Planning Operators tab.

4. Choose Add.

The Planning Operators dialog appears.

5. Select the planning operators you want to assign to your planning area and choose OK.

[Link] 87/128
12/3/2020

Advanced Simulation (ADVSIM) Operator

The Advanced Simulation (ADVSIM) operator copies key gure values from source key gures to target key gures during simulation. The ADVSIM operator
supports disaggregation based on calculated key gures. It cannot be run in batch mode.

External key gures and key gures using external key gures in their calculation rules can't be used in the Advanced Simulation (ADVSIM) operator.

 Recommendation
The ADVSIM operator is a workaround for disaggregation with reference to a calculated key gure whose values changed during a previous simulation. SAP
recommends that you use this operator only when absolutely necessary because it may affect performance during simulation or during saving and because it
requires a stored key gure. If the value of the referenced calculated key gure does not change frequently, it is advisable to copy the calculated key gure to a
stored key gure using a regularly scheduled copy operator job and to use the stored key gure as a reference.

The following are sample use cases for the ADVSIM operator:

Disaggregate the sales forecast quantity based on the last 12 months of sales history.

Perform a complex calculation based on key gures at different planning levels before disaggregation.

The operator supports the following operations:

Pre-Copy: Copies con gured source key gure values to target key gure values before disaggregation

Post-Copy: Copies con gured source key gures to target key gures after disaggregation

Disaggregation Key Figures: Whenever a change is made to a key gure de ned as a disaggregation key gure, the advanced simulation operator is
triggered.

When a key gure is con gured in an ADVSIM operator as a disaggregation key gure and its value is subsequently changed or simulated in a planning view, the
ADVSIM operator is triggered and does the following for the changed cells only:

1. Pre-copy

2. Regular disaggregation of the key gure

3. Post-copy

Before calculated key gures can be used for disaggregation, the value of the calculated key gure must be stored in another stored key gure at the same base
planning level as the key gure that is being disaggregated. This is done in the Pre-copy or the Post-copy operations of the ADVSIM operator.

The following table lists the con guration settings for the ADVSIM operator:

Parameter Explanation Mandatory/Optional

PRE_SOURCE_KFID1m Source key gure ID Optional

PRE_TARGET_KFID1m Target key gure ID Optional

POST_SOURCE_KFID1m Source key gure ID Optional

POST_TARGET_KFID1m Target key gure ID Optional

DISAGG_KFID1m Key gures that invoke that ADVSIM operator when their Mandatory
values change.

 Note
Note the following with respect to the parameter IDs:

"m" is a number that represents the key gure pair for source and target key gures. You con gure it as follows:

PRE_SOURCE_KFID11 = KF1, PRE_TARGET_KFID11 = KF2;

PRE_SOURCE_KFID12 = KF3, PRE_TARGET_KFID12 = KF4

KF1 is then copied to KF2, and KF3 is copied to KF4 as part of pre-copy, allowing copying of multiple key gures in a single operator call.

 Note
If an operator contains multiple DISAGG key gures and there is a value change in any of the DISAGG key gures, the system copies the values between all
contained key gure pairs.

[Link] 88/128
12/3/2020
Other important conditions for the ADVSIM operator are as follows:

Like any other simulation, the ADVSIM operator uses the lters from the planning view and applicable for changed cell values of the DISAGG_KFID key
gure.

The source key gure for the copy operation can be either stored or calculated. The source key gures are queried and then copied at the base planning level
of the target key gures. The attributes available at request level for the source key gure must be a superset of the base planning level of the target key
gure.

The target key gure for Pre-copy and Post-copy must be a stored key gure and must have the same base planning level as the DISAGG_KFID key gure.

For more information, see Planning with Microsoft Excel in the application help.

Example: Setting Up the ADVSIM Operator

Prerequisities
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
The ADVSIM planning operator type is delivered as part of the standard SAP content for planning operators. In this example, an ADVSIM operator is created to
copy the calculated value of ACTUALSQTY offset by 12 months (ACTUALQTYOFFSET) to a stored key gure ACTUALSQTYOFFSETSTORED.

To create an ADVSIM operator, use the Planning Operators app.

Steps
1. In the Planning Operators app, choose ADVSIM from the list of planning operator types on the left side of the screen.

2. Select + (Add Planning Operators).

Make the following entries:

Field Entry

Name COPYACTUALOFFSET

Description Copy Actuals Offset

Interactive Mode Yes

Batch Mode No

Filter Mode No (system always uses the planning view lter)

3. Choose De ne Parameters.

4. Add the parameters for the COPYACTUALOFFSET operator as follows:

Parameter Name Parameter Value

DISAGG_KFID11 SALEFCSTQTY

PRE_SOURCE_KFID11 ACTUALQTY12OFFSET

PRE_TARGET_KFID11 ACTUALSQTYOFFSETSTORED

5. Assign the operator to your planning area.

Result
When SALESFCSTQTY is simulated or saved, the following takes place:

1. ACTUALQTY12OFFSET is calculated and copied to ACTUALSQTYOFFSETSTORED.

2. The disaggregation is performed on SALESFCSTQTY based on ACTUALSQTYOFFSETSTORED.

Note that SALESFCSTQTY is con gured as follows with ACTUALSQTYOFFSETSTORED in the disaggregation expression:

[Link] 89/128
12/3/2020

SALESFCSTQTY

Copy Operator (Advanced)

This operator is used to copy key gure values within a planning area as well as between two planning areas. If necessary, source key gure values are aggregated
and target key gure values are disaggregated.

Using the Copy Operator Pro les app, you con gure the details of the copy process and save them in a copy operator pro le. You can set up the copy process for
multiple key gures on different copy levels in one copy operator pro le and then copy all key gures that are required for a certain process step with one copy
operator run.

The Copy Operator (Advanced) combines the features of the existing Copy (COPY) Operator and Disaggregation (DISAGG) Operator and offers a simpli ed
con guration using the Copy Operator Pro les app. We recommend using the Copy Operator (Advanced). You can copy or migrate your existing operators using
the Copy Operator Pro les app.

Scheduling the Copy Operator (Advanced)

You can schedule the Copy Operator (Advanced) in the Application Jobs app.

We recommend using the application job template Copy and Disaggregate Key Figure Operator. Future enhancements will only be added to this template.

The following application jobs templates are available for the different operator types:

Application Job Templates for Copy Operator (Advanced)

Supported Use Case of Copy Operator Job Template Copy Operator Job Template Copy Operator with Time Job Template Copy and Disaggregate
(Advanced) Period Filter Key Figure Operator

Copy operator pro le to copy values yes yes yes

within a planning area (manually created)

Copy operator pro le to copy values yes yes yes

within a planning area (migrated from a
COPY Operator)

[Link] 90/128
12/3/2020

Supported Use Case of Copy Operator Job Template Copy Operator Job Template Copy Operator with Time Job Template Copy and Disaggregate
(Advanced) Period Filter Key Figure Operator

Copy operator pro le to copy values no no yes

within a planning area (migrated from a
DISAGG Operator)

Copy operator pro le to copy values no no yes

between planning areas (manually
created or migrated from a DISAGG
Operator)

You can also schedule the Copy Operator (Advanced) from the SAP IBP, add-in for Microsoft Excel.

Keeping Track of Your Operator Jobs

To track your operator jobs, you can use the Monitor System Tasks app. Here you get an overview of the most important indicators, like runtime, number of key
gures written and read.

Related Information
Copy Operator Pro les

Copy Operator Pro les

You can use this app to con gure the Copy Operator (Advanced). This operator is used to copy key gure values within a planning area as well as between two
planning areas.

You can set up the copy process for multiple key gures on different copy levels in one copy operator pro le and then copy all key gures that are required for a
certain process step with one copy operator run.

For a detailed description of all available settings and options, see the Web assistant help in the app.

Key Features

Key Figure Selection

Here you select the source and target key gure pairs. When you copy key gure values within one planning area, the system automatically defaults the lowest
attribute and time levels on which the key gures can be read and written. When you copy key gure values between two planning areas, you need to manually
select the copy levels.

You can generate missing time period entries and initialize target key gures.

If your copy operator pro le contains several pairs of source and target key gures, you can choose to copy key gures sequentially. This way you control how
dependencies between the key gures are handled in the copy process. Please only use this feature, if dependencies require it. It may lead to longer operator
runtimes.

The following key gure types are supported for source key gures:

Calculated and stored key gures

Key gures de ned on a time-independent base planning level, if they have a time-dependent REQUEST level calculation with one key gure.

External key gures

For target key gures, only stored key gures are supported.

Time and Attribute Selection

You can choose a rolling time selection and select key gures by date, by period, or by period offset and duration.

When you schedule the operator in the SAP Integrated Business Planning, add-in for Microsoft Excel, you can adjust the period selection afterwards. This
feature is only available for pro les with one time pro le level.

You can manually adjust period offset, period duration, and period shift, if necessary.

You can optionally de ne lters based on attribute values.

You can units of measure as attribute selections.

Processing Options

[Link] 91/128
12/3/2020
You can specify how key gure values are processed:

Missing planning objects can be generated.

Proportional disaggregation can be disabled.

Key gure xing can be considered in multiple ways.

Processing can be spilt into packages to limit memory consumption and the risk of locking issues.

Copying Key Figure Values Between Planning Areas

You can copy key gure values within one planning area or between two planning areas. If you’re copying values between planning areas, there are some additional
points to consider:

You can choose if the execution of the operator can be triggered from the source or from the target planning area.

In the section Mapping, you can map time pro le levels and attributes, if nessecary.

Additionally, if the two planning areas use different attribute IDs you can map these attributes, if necessary.

You can use attribute selections while reading the source key gures and/or while writing the target key gures.

If you copy key gure values between two planning areas, it's not possible to change the time selection or change the version or scenario when you execute
or schedule the operator in the SAP IBP, add-in for Microsoft Excel.

Copying or Migrating Existing Operators

You can copy existing copy and disaggregation operator con gurations into the Copy Operator Pro les app. The system creates a copy operator pro le containing
an independent copy of the selected operator. The selected operator is unassigned from the planning area but isn't changed.

You additionally have the option to migrate existing copy or disaggregation operators into a copy operator pro le. Application jobs and application job templates
that use the migrated operator will automatically use the newly created copy operator pro le instead. When you save the draft version of the created copy operator
pro le for the rst time, the copy or disaggregation operator will be removed from the panning area.

After migrating an operator, jobs and application job templates that use this copy operator still refer to the old copy operator ID. Nevertheless, the system uses the
copy operator pro le created by the migration for execution. To replace the copy operator ID by the migrated copy operator pro le ID in the job template, you can
open the template in edit mode, select Check, and save.

Supported Device Types

Desktop

Tablet

Related Information
Copy Operator (Advanced)

Processing of Key Figures

When you execute a copy operator, the key gure values are copied for the selected versions and scenarios in one or several key gure groups. Key gure groups are
always processed sequentially. Within a key gure group, values are copied in one or several packages.

Processing of Key Figures in Groups

For performance reasons, the system tries to process all key gures in one group. If it isn't possible, the system splits the key gure processing into several groups.
Reasons for processing key gures in groups include:

The Copy Key Figures Sequentially option is selected.

The key gure pairs use different copy levels.

The settings for Create Missing Periods or Clear Values differ.

If you select the Copy Key Figures Sequentially option, every key gure pair is processed as a separate group. As this may result in longer run times, we
recommend using this option only if it's necessary.

 Note
You can see the key gure processing groups in the execution log of the operator but not in the Copy Operator Pro les app.

[Link] 92/128
12/3/2020
Packaging Within a Key Figure Group
To reduce the memory consumption and the risk of locking issues, we recommend using packages. Unless you set a speci c number of processing packages in your
pro le, the system uses the default number of processing packages as de ned in the global con guration parameter NUMBER_OF_PROCESSING_PACKAGES. For
more information, see Global Con guration Parameters. The system then generates packages for processing of key gure values within a key gure group. As
packages are built by period, this is only possible if the copy operator pro le is used for more than one period. Packages are processed sequentially and saved
independently.

In some cases, for example for operator pro les that are used to copy large data sets, it makes sense to specify in the copy operator pro le how many processing
packages you want the system to generate.

 Note
Depending on the con guration of the source key gures, reading only one or few periods may lead to different values. When copying such key gures, we
recommend that you disable packaged processing by setting the Number of Processing Packages to 1.

Example
Example of Profile Settings

Pro le Key Figure Pairs Copy Key Figures Sequentially Copy Level / Clear Values / Key Figure Groups
Create Missing Periods

A 3 no Identical for all key gure pairs 1

B 2
Identical for two key
gure pairs

Different for third key

gure pair

C yes not relevant 3

Let's assume the pro les are used to copy key gure values for 52 periods and the number of processing packages is set to 5.

If you run the same operator for two versions, you get the following number of packages:

Pro le A: 2 Versions * 1 Key Figure Group * 5 Packages/ Key Figure Group → 10 Packages

Pro le B: 2 Versions * 2 Key Figure Groups * 5 Packages/ Key Figure Group → 20 Packages

Pro le C: 2 Versions * 3 Key Figure Groups * 5 Packages/ Key Figure Group → 30 Packages

Copy (COPY) Operator

 Note
This operator is only available to customers who licensed IBP prior to SAP Integrated Business Planning for Supply Chain 2005. Please use Copy Operator
(Advanced) instead. For more information, see Copy Operator (Advanced) .

The copy (COPY) operator is primarily used to copy calculated or stored values from one key gure to a stored key gure in the same version of a planning area
(base or other). In addition, it can create any missing time periods for the target key gure and assign an empty value to them. It can also be used to clear key gure
values.

If the copy operator is applied for version key gures, both the source and target key gures must be added to the version.

Key gures can be copied only if the source key gure can be calculated at the base planning level of the target key gure. The copy operator calculates values of
the source key gure at the base planning level of the target key gure for all possible combinations, and updates the target key gure values. Values are calculated
based on the calculation con guration.

 Example
KF1 is a stored key gure with base planning level PRODLOCCUST, and KF2 is a stored key gure with base planning level PRODLOC.

If you de ne a COPY operator to copy KF1 to KF2, the operator calculates values of KF1 for all possible combinations of PROD-LOC and stores the result in
KF2.

You can con gure this operator in a similar way to other batch operators, and make it available in the SAP Integrated Business Planning, add-in for Microsoft Excel
by adding it to the roles.

[Link] 93/128
12/3/2020

 Note
Only time-dependent target key gures are supported for the copy operator.

 Caution
In some cases, a user may have a role that grants unlimited read access but restricted write access. The restriction may be based on a permission lter or may
be set for speci c key gures. If this user runs the copy operator, it will copy values of the key gure for all possible attribute combinations from the source to
the target without considering the user's authorizations.

To prevent this, de ne the restrictions at read level of the source key gure.

For more information, see SAP Note 2445262 .

Parameters

Parameter Explanation Mandatory/Optional

SOURCE_KFIDn Source key gure ID. n is a number starting from 1 Mandatory for copy

Optional if you only want to create the missing time

periods for the target key gure For more information,
see the CREATE_TIMEPERIODS parameter below.

TARGET_KFIDn Target key gure ID. n is a number starting from 1. Mandatory

 Note
De ne source and target key gures in pairs. For
example, SOURCE_KFID1 is copied to
TARGET_KFID1, SOURCE_KFID2 is copied to
TARGET_KFID2, and so on. This allows execution of
multiple key gure copies in a single operator call.

PERIOD_OFFSET Offset relative to the current period. If this parameter Optional

isn’t speci ed, it defaults to zero, in which case only
values in future buckets are copied. If you want to copy
values in the past, specify a negative offset.

The offset is applied as follows:

1. Determine the current bucket at the most

granular level of the time pro le.

2. Determine the current bucket at the granularity

speci ed in the base planning level of the target
key gure.

3. Apply the offset to the current bucket

determined in step 2.

 Example
If the time pro le has week, month, quarter, and year,
and the base planning level of the target key gure is
month:

1. Determine the current week.

2. Determine the month that contains the

current week.

3. Add the offset to the current month to

determine the beginning of the month to
which the data will be copied.

[Link] 94/128
12/3/2020

Parameter Explanation Mandatory/Optional

DURATION Number of periods to be copied starting from the offset Optional (Mandatory if PERIOD_OFFSET is speci ed.)
de ned in PERIOD_OFFSET. Can be used with
PERIOD_OFFSET to restrict the copy to a speci c range
of time buckets.

If not speci ed or zero, it is considered to be until the

end of the horizon.

 Example
If you want to copy values from the past and future,
for example 12 months in the past and 12 months in
the future, then you de ne the following:
PERIOD_OFFSET: -12 and DURATION: 25.

<Attribute>_VALUEn Con gured lter Optional

<Attribute> is the name of an attribute.

n is a number starting from 1 for each attribute,

which enumerates the allowed values.

You can specify multiple values for a single

attribute.

You can specify multiple attributes.

This con gured lter is applied for every COPY

operation. It cannot be overridden from the SAP
IBP, add-in for Microsoft Excel , but users can
specify a user lter when scheduling the
operator to restrict it further. The system
considers the intersection of con gured lter
and user-speci ed lter.

CREATE_TIMEPERIODS Creates the missing periods for the target key gure and Optional
assigns these periods an empty value. The parameters
listed above are taken into account.

If you activate this parameter (by setting the parameter

value to X), the copy operator does the following:

If you have speci ed a source key gure, the

copy operator copies the source key gure to the
target key gure and creates the missing
periods.

If you have not speci ed a source key gure, the

copy operator only lls in the missing time
periods for the target key gure.

Note that this parameter is not taken into account if the

copy operator is run for scenarios.

PERIOD_SHIFT Number of periods by which the source key gure values Optional
are shifted.

TARGETCONVATTRTO1 Target attribute used if you want to copy a source key Mandatory if you want to directly copy key gure values
gure value that has a conversion, such as a unit of that have a conversion without having to create
measure or currency conversion intermediate key gures. Otherwise, optional.

TARGETCONVATTRTOVAL1 Value of the target attribute used if you want to copy a Mandatory if you want to directly copy key gure values
source key gure value that has a conversion, such as a that have a conversion without having to create
unit of measure or currency conversion intermediate key gures. Otherwise, optional.

CLEAR_KF_VALUES Clears the value of the target key gure, that is, sets the Optional
value to null.

If you enter a source key gure, the operator rst copies

the values to the target key gure, thereby creating any
planning combinations that don't already exist. It then
clears the value of the target key gure. If you don't
enter a source key gure, the operator simply clears the
target key gure values. No planning combinations are
created in this case.

Note that this parameter is not taken into account if the

copy operator is run for scenarios.

[Link] 95/128
12/3/2020

Parameter Explanation Mandatory/Optional

PARALLEL_MODE Copies the source key gure values to the target key Optional
gure values without taking into account any
dependencies.

Note that this parameter is not taken into account if the

copy operator is run for scenarios.

 Example
You have the following key gure values in your
system:

SKF1 = 2 (stored or calculated)

TKF1 = 1 (stored)

SKF2 = 10 * TKF1 (calculated)

TKF2 = 10 (stored)

SKF1 is to be copied to TKF1 and SKF2 is to be copied

to TKF2.

If you run the operator in sequential mode, the value

of SKF1 is rst written to TKF1, meaning that TKF1 is
now equal to 2. Then the value of SKF2, which is now
20 (10 * 2) is read and written to TKF2. The value of
TKF2 is therefore 20.

If you run the operator in parallel mode, the values of

SKF1 and SKF2 are read rst before any copy
operation takes place. SKF1 is therefore 2 and SKF2
is 10. The values are then copied to the
corresponding target values, and so TKF1 is equal to
2 and TKF2 is equal to 10.

SAP_UI_SORT_ORDER The SAP_UI_SORT_ORDER parameter speci es the Optional

position of the planning operator in the list of operators
in the IBP Excel Add-In (for example, in the dropdown
lists). To set the position, enter 10 for the rst position,
20 for the second position, and so on.

IS_FILTER_REQUIRED Indicates whether the user must specify a planning lter Optional
when scheduling the COPY operator. If this parameter is
set to X, the user cannot schedule the operator without
selecting a planning lter.

Related Information
Example: Clearing Key Figure Values

Example: Setting Up the Copy Operator

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
To set up the Copy operator, use the Planning Operators app.

 Note
To con gure planning operators, the Planning Model business catalog must be assigned to a business role assigned to your user.

The following example illustrates how to set up the Copy operator.

Steps
1. In the Planning Operators app, choose COPY from the list of planning operator types on the left side of the screen.

2. Select + (Add Planning Operators).

[Link] 96/128
12/3/2020
Make the following entries:

Field Entry

Name COPY_STORED

Description Copy from Stored KFs to Stored KFs

Interactive Mode No

Batch Mode Yes

Filter Mode Select or deselect according to whether you want the user to use lters when
running or scheduling the operator in IBP Excel add-in.

De ne parameters as follows:

Parameter Name Parameter Value Stored/Calculated Base Planning Level

DURATION 5

PERIOD_OFFSET 0

SOURCE_KFID1 FINANCEPLANPROFIT Stored PERPRODFMLCUSTREG

SOURCE_KFID2 FINANCEPLANQTY Stored PERPRODFMLCUSTREG

TARGET_KFID1 FINANCEPLANREV Stored PERPRODFMLCUSTREG

TARGET_KFID2 CMPAVAILABLEQTY Stored PERPRODLOC

SM1PRDID_VALUE1 x101 Phone

SM1PRDID_VALUE2 x101 Media Player

3. Add a second planning operator.

Make the following entries:

Field Name

Name COPY_CALCULATED

Description Copy from Calculated KFs to Stored KFs

Interactive Mode No

Batch Mode Yes

Filter Mode Yes

De ne parameters as follows:

Parameter Name Parameter Value Stored/Calculated Base Planning Level

DURATION 100

PERIOD_OFFSET 0

SOURCE_KFID1 FINANCEPLANPRICE Calculated PERPRODFMLCUSTREG

SOURCE_KFID2 INVENTORYTARGETCOST Calculated PERPRODFMLCUSTREG

TARGET_KFID1 FINANCEPLANREV Stored PERPRODFMLCUSTREG

TARGET_KFID2 FINANCEPLANPROFIT Stored PERPRODLOC

4. Save your entries.

5. Assign the planning operator to the relevant planning area. For more information see Assigning a Planning Operator to a Planning Area.

Example: Clearing Key Figure Values

Parameter CLEAR_KF_VALUES can be set to nullify the values of the target key gure. Depending on how you con gure the operator, planning combinations and
time periods can also be created.

[Link] 97/128
12/3/2020
Source Key Figure Speci ed and Time Periods Not Created
If you enter a source key gure, the copy operator rst copies the values to the target key gure, thereby creating any planning combinations that don't already
exist. It then clears the value of the target key gure.

Example

Stored source key gure SKF1 has been de ned for the planning level Month – Customer ID – Product ID. Stored target key gure TKF1 has been de ned for the
base planning level Month – Customer Region – Product Family.

Before the copy operator runs, the data in your system is as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

NA Phones Sept 2017 15000

APAC Phones Sept 2017 11000

When the copy operator runs, it copies the values from the source key gure to the target key gure. During this process, it checks whether planning combinations
of Customer Region and Product Family exist. If they don't, the operator creates them and copies key gure values to them.

Customer Region Product Family Period SKF1

EMEA Phones Sept 2017 20000

NA Phones Sept 2017 10000

In this case, the planning combination EMEA – Phones exists for the source key gure but not for the target key gure. The copy operator therefore creates this
planning combination for the target key gure.

After the copy operator has run, the planning data in your planning area will be as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

NA Phones Sept 2017

APAC Phones Sept 2017

EMEA Phones Sept 2017

The planning combination EMEA and Phones has been created for the planning level Month – Customer Region – Product Family. The values for target key gure
TKF1 have been cleared for the planning combinations NA – Phones, APAC – Phones, and EMEA – Phones.

Source Key Figure Not Speci ed and Time Periods Not Created
If you don't specify a source key gure for the target key gure, the copy operator only clears target key gure values. No new planning combinations are created for
target key gure.

Example

Stored target key gure TKF1 has been de ned for the base planning level Month – Customer Region – Product Family.

Before the copy operator runs, the data in your system is as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

[Link] 98/128
12/3/2020

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

NA Phones Sept 2017 15000

APAC Phones Sept 2017 11000

After the copy operator has run, the planning data in your planning area will be as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

NA Phones Sept 2017

APAC Phones Sept 2017

No new planning combination has been created for the planning level Month – Customer Region – Product Family. The values for target key gure TKF1 have been
cleared for the planning combinations NA – Phones and APAC – Phones.

Source Key Figure Speci ed and Time Periods Are Created

If you have speci ed that time periods are to be created and you have also entered a source key gure, the copy operator rst copies the values to the target key
gure, thereby creating any planning combinations that don't already exist. It then creates any missing time periods for the target key gure, and nally it clears the
value of the target key gure.

Example

Stored source key gure SKF1 has been de ned for the planning level Month – Customer ID – Product ID. Stored target key gure TKF1 has been de ned for the
base planning level Month – Customer Region – Product Family.

You de ne a copy operator with the following parameters:

Parameter Parameter Value

SOURCE_KFID1 SKF1

TARGET_KFID1 TKF1

CREATE_TIMEPERIODS X

CLEAR_KF_VALUES X

DURATION 3

PERIOD_OFFSET 1

Before the copy operator runs, the data in your system is as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

C1 EMEA P1 Phones Nov 2017 10000

C2 EMEA P1 Phones Nov 2017 10000

C3 NA P1 Phones Nov 2017 10000

NA Phones Sept 2017 15000

NA Phones Nov 2017 15000

APAC Phones Sept 2017 11000

Let's assume that the current month is August 2017.

[Link] 99/128
12/3/2020
When the copy operator runs, it copies the values from the source key gure to the target key gure. During this process, it checks whether planning combinations
of Customer Region and Product Family exist. If they don't, the operator creates them and copies key gure values to them. It then creates missing periods within
the time interval Sept 2017—Nov 2017 with key gure values of “null”. Finally, it clears any other target key gure values.

Customer Region Product Family Period SKF1

EMEA Phones Sept 2017 20000

NA Phones Sept 2017 10000

In this case, the planning combination EMEA – Phones exists for the source key gure but not for the target key gure. The copy operator therefore creates this
planning combination for the target key gure.

After the copy operator has run, the planning data in your planning area will be as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

C1 EMEA P1 Phones Nov 2017 10000

C2 EMEA P1 Phones Nov 2017 10000

C3 NA P1 Phones Nov 2017 10000

NA Phones Sept 2017

NA Phones Oct 2017

NA Phones Nov 2017

APAC Phones Sept 2017

APAC Phones Oct 2017

APAC Phones Nov 2017

EMEA Phones Sept 2017

EMEA Phones Oct 2017

EMEA Phones Nov 2017

The planning combination EMEA – Phones has been created for the planning level Month – Customer Region – Product Family. Missing periods within the time
frame Sept 2017—Nov 2017 have been created. The values for target key gure TKF1 have been cleared for the planning combinations NA – Phones, APAC –
Phones, and EMEA – Phones.

Source Key Figure Not Speci ed and Time Periods Are Created
If you have speci ed that time periods are to be created but you have not speci ed a source key gure for the target key gure, the copy operator rst creates any
missing periods for the target key gure, and then it clears the target key gure values. No new planning combinations are created for target key gure.

Example

Stored target key gure TKF1 has been de ned for the base planning level Month – Customer Region – Product Family.

You de ne a copy operator with the following parameters:

Parameter Parameter Value

TARGET_KFID1 TKF1

CREATE_TIMEPERIODS X

CLEAR_KF_VALUES X

DURATION 3

PERIOD_OFFSET 1

Before the copy operator runs, the data in your system is as follows.

[Link] 100/128
12/3/2020

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

C1 EMEA P1 Phones Nov 2017 10000

C2 EMEA P1 Phones Nov 2017 10000

C3 NA P1 Phones Nov 2017 10000

NA Phones Sept 2017 15000

NA Phones Nov 2017 15000

APAC Phones Sept 2017 11000

Let's assume that the current month is August 2017.

When the copy operator runs, it creates missing periods within the time interval Sept 2017—Nov 2017 with key gure values of “null”. It then clears any other target
key gure values.

After the copy operator has run, the planning data in your planning area will be as follows.

Customer ID Customer Region Product ID Product Family Period SKF1 TKF1

C1 EMEA P1 Phones Sept 2017 10000

C2 EMEA P1 Phones Sept 2017 10000

C3 NA P1 Phones Sept 2017 10000

C1 EMEA P1 Phones Nov 2017 10000

C2 EMEA P1 Phones Nov 2017 10000

C3 NA P1 Phones Nov 2017 10000

NA Phones Sept 2017

NA Phones Oct 2017

NA Phones Nov 2017

APAC Phones Sept 2017

APAC Phones Oct 2017

APAC Phones Nov 2017

Missing periods within the time frame Sept 2017—Nov 2017 have been created for planning combinations NA – Phones and APAC – Phones. The values for target
key gure TKF1 have also been cleared for these planning combinations.

Snapshot (SNAPSHOT) Operator

The snapshot (SNAPSHOT) planning operator allows users to take snapshots of key gures in the SAP Integrated Business Planning, add-in for Microsoft Excel or
the Application Jobs app.

When you de ne a snapshot on the Snapshots tab of the Planning Areas app, the system automatically creates a Snapshot planning operator and a Redo
Snapshot planning operator for the de nition. All further snapshot de nitions are added to the same planning operators.

Planning operators of this type are not editable.

Related Information
Con guring Original Snapshots

Redo Snapshot (SNAPSHOTREDO) Operator

The redo snapshot (SNAPSHOTREDO) planning operator allows users to retake a snapshot if there are errors in the data. The operator overwrites the most recent
snapshot with a new snapshot for the same set of key gures in a batch process.

When you de ne a snapshot on the Snapshots tab of the Planning Areas app, the system automatically creates a Snapshot planning operator and a Redo
Snapshot planning operator for the de nition. All further snapshot de nitions are added to the same planning operators.

[Link] 101/128
12/3/2020
Planning operators of this type are not editable.

Related Information
Con guring Original Snapshots

Disaggregation (DISAGG) Operator

The disaggregation (DISAGG) operator can be used to copy key gure values within the same version of a planning area, as well as between two planning areas.

 Note
This operator is only available to customers who licensed IBP prior to SAP Integrated Business Planning for Supply Chain 2005. Please use Copy Operator
(Advanced) instead. For more information, see Copy Operator (Advanced) .

You can con gure this operator in a similar way to other batch operators and make it available in the SAP IBP, add-in for Microsoft Excel by adding it to a business
role. The disaggregation operator works in batch mode only.

Copying and Disaggregating Key Figure Data

You can use the disaggregation (DISAGG) operator to copy key gure values between key gures on a certain aggregation level. If required, source key gure values
are aggregated and target key gure values are disaggregated.

For calculated (and stored) source key gures, the calculated value is copied. For stored source key gures, the stored value is copied.

Within one planning area, key gure values can only be copied in the same version. When copying key gure values between two planning areas, the source and
target version can be selected and may differ.

 Note

The DISAGG operator does not copy xing by default. You can enable copying xing information by using the parameter COPY_KF_FIXING. As a
prerequisite, the source and target key gures must be enabled for xing and the aggregation level must be the same as the base planning level of the
source key gures.

Aggregated constraint key gure values are stored only at the aggregate level (that is, the planning level where you entered them in the Microsoft Excel
planning view), and there is no disaggregation. Therefore, aggregated constraint key gures can't be used in the DISAGG operator. For more information
see Aggregated Constraints.

Creating Missing Planning Objects

The Disaggregation operator can also create missing planning objects, if the following prerequisites are met:

The aggregation level of the DISAGG operator (ATTRIBUTE1, ATTRIBUTE2, and so on) must be the same as the root attributes of the base planning level of
the target key gures.

Planning objects can only be created if the required master data values are available. The DISAGG operator does not create missing master data type
values.

Handling the Aggregation Level and Time Pro le Level

The disaggregation operator can read values of the source key gure at a higher level than the base planning level of the target key gure (at the aggregation level).
The operator then copies the values from the source key gure to the target key gure, disaggregating the values to the base planning level of the target key gure.

 Example

[Link] 102/128
12/3/2020
KF1 is a stored key gure with base planning level product-customer, and KF2 is a stored key gure with base planning level product-location.

If you de ne the DISAGG operator to copy and disaggregate the values from KF1 to KF2 at the aggregation level of PRDID, then the DISAGG operator reads the
key gures values of KF1 at the aggregation level of product, then disaggregates and writes the values to KF2 at product-location level.

 Note

The source key gure can be calculated or stored, but the target key gure must be stored.

Disaggregation works even if the source key gure cannot be calculated at the base planning level of the target key gure.

If the disaggregation operator is used for version key gures, both source and target key gures must be added to the version.

Parameters
When you de ne a new planning operator of the DISAGG planning operator type, specify values for the following parameters in the Planning Operators app:

Parameters

Parameter Explanation Mandatory/Optional Comment

ATTRIBUTEn The aggregation level is the level at which Mandatory to specify at least one
the source key gure is read and copied attribute for the aggregation level.
to the target key gure (before
disaggregation takes place).

 Example
You want to read the source key gure
data at product-customer level.
Specify the root attributes of the
respective master data types, such as
PRDID and CUSTID , as
ATTRIBUTE1, and ATTRIBUTE2.

DURATION The number of periods to be copied and Optional

disaggregated starting from the offset
Mandatory if PERIOD_OFFSET is
de ned in PERIOD_OFFSET. Can be used
speci ed
with PERIOD_OFFSET to restrict the
copy and disaggregation to a speci c
range of time buckets.

If you have not speci ed DURATION and

PERIOD_OFFSET, the operator
processes the key gure values in the
whole planning horizon.

FILTER_ATTRIBUTEn The attribute for the con gured lter. You Optional
can de ne multiple lter attributes.

No matter if you are copying key gure

values within one planning area or
between planning areas, lters are
considered as follows:

While writing the target key gure

values, lters for attributes that
are part of the base planning level
of the target key gure are
applied.

While reading the source key

gure values, all lters are
applied.

[Link] 103/128
12/3/2020

Parameter Explanation Mandatory/Optional Comment

FILTER_VALUEn The value for the corresponding lter Optional To lter for multiple values of the same
attribute that you have speci ed. attribute, you need to specify the lter
attribute for every lter value, for
 Note example:

This con gured lter is applied for FILTER_ATTRIBUTE1: LOCID

every DISAGG operation. It cannot be
overridden with a lter de ned in the FILTER_VALUE1: Distribution
SAP Integrated Business Planning, Center 1
add-in for Microsoft Excel, but users
FILTER_ATTRIBUTE2: LOCID
can specify a user lter when
scheduling the operator to restrict it
further. The system takes this
combination of con gured and user- FILTER_VALUE2: Distribution
speci ed lters into account. Center 2

PERIODID Technical ID of the time level (for Either PERIODID or PERIODNAME is

example, ). mandatory. Specify only one of them.

 Note
The PERIODID does not correspond
to the number of the time level.

PERIODNAME The name of the time level at which you Either PERIODID or PERIODNAME is
want to read and disaggregate the data as mandatory. Specify only one of them.
de ned in the time pro le of your
planning area (for example, Monthly).

PERIODSHIFT The period shift is the source key gure Optional

value from period n copied and
disaggregated to target key gure value in
period n plus the value de ned for the
PERIODSHIFT parameter.

 Example
You specify Yearly for PERIODNAME.
In this case, the value 1 for the
PERIODSHIFT parameter means that
the values of the source key gure are
copied and disaggregated to the next
year period of the target key gure.

PERIOD_OFFSET Offset relative to the current period. Optional

If you have speci ed a value for

DURATION, the default value for
PERIOD_OFFSET is 0.

SEQUENTIAL If you have multiple pairs of source and Optional

target key gures, you can specify that
the system processes them sequentially.
With sequential processing, the system
includes the result of a key gure copy
and disaggregation in the subsequent
copy and disaggregation.

For an example about the use of this

parameter, see Example: Setting Up the
Disaggregation Operator.

CREATE_NO_PLANNING_OBJECTS This parameter speci es that you do not Optional By default, missing planning objects are
want to create missing planning objects created if the aggregation level is the
during the process of copying key gure same as the base planning level of the
data between two planning areas. target key gure. You can use this
parameter to prevent the creation of
missing planning objects.

[Link] 104/128
12/3/2020

Parameter Explanation Mandatory/Optional Comment

NO_PROPORTIONAL_DISAGG Allows the system to disable the Optional You can use this parameter in the
proportional disaggregation of a key following way to redistribute key gure
gure. If you set the value to X or x, No values which are stored in technical
Proportional Disaggregation is used as weeks according to period weight factors:
Proportionality, that is, the key gure
Select the relevant key gure as
values are disaggregated according to
source key gure
their disaggregation mode (Equal or
(SOURCE_KFIDn) and target key
Copy). If a period weight factor is de ned,
it is considered. gure (TARGET_KFIDn)

Select the root attributes of the

base planning level of the key
gure as aggregation level
(ATTRIBUTEn parameter)

Select calendar week as time

level (PERIODID or
PERIODNAME)

The disaggregation operator will

read key gure values on calendar
week level and disaggregate them
to technical weeks according to
the period weight factors.

SOURCE_KFIDn Source key gure ID. n is a number Mandatory to de ne at least one source
starting from 1. key gure.

TARGET_KFIDn Target key gure ID. n is a number Mandatory to de ne at least one target
starting from 1. key gure.

 Note

De ne source and target key gures in

pairs. For example, SOURCE_KFID1 is
copied to TARGET_KFID1,
SOURCE_KFID2 is copied to
TARGET_KFID2, and so on. This enables
the execution of multiple key gure
copies and disaggregations in a single
operator call.

COPY_KF_FIXING Speci es that when copying key gure Optional This parameter cannot be used in
values, xing information is also copied. combination with parameter
UNFIX_TARGET_KF.

UNFIX_TARGET_KF Speci es that when copying key gure Optional This parameter cannot be used in
values, the target key gures are un xed. combination with parameter
COPY_KF_FIXING.

IS_FILTER_REQUIRED Indicates whether the user must specify a

lter value when scheduling the DISAGG
operator. If this parameter is set to X, the
user cannot schedule the operator
without selecting a lter.

SAP_UI_SORT_ORDER Speci es the position of the planning

operator in the list of operators in the
SAP Integrated Business Planning, add-in
for Microsoft Excel (for example, in the
dropdown lists). To set the position, enter
10 for the rst position, 20 for the second
position, and so on.

NUMBER_OF_PROCESSING_PACKAGES The number of packages you want the Optional For more information, see Packaged
system to split the processing of the Processing of the DISAGG Operator
DISAGG operator into.

Additional Parameters for Copying Key Figure Values from one Planning Area to Another Planning Area

Parameter Explanation Mandatory/Optional Comment

SOURCE_PLAREA Source planning area Required if you want to copy key gure You must assign the DISAGG operator
data between a source planning area and either to the source or to the target
TARGET_PLAREA Target planning area a target planning area. planning area.

[Link] 105/128
12/3/2020

Parameter Explanation Mandatory/Optional Comment

SOURCE_VERSION Source planning version Required if you want to copy key gure
If not speci ed, the base version
data between a source planning area and
is used.
a target planning area.

The base version can be selected

 Caution explicitly using the constant
When you want to copy data within BASELINE.
TARGET_VERSION Target planning version one planning area, a version copy is
If you want to copy data within
not allowed. In such a case, the
one planning area, you must use
parameters SOURCE_VERSION and
the Copy (COPY) operator.
TARGET_VERSION must be equal or
not speci ed.

SOURCE_MAP_ATTRIBUTEn The source attribute from which you want Required if attribute mapping is
The master data types of the
to copy data when copying data between necessary, for example, if the source
attributes are not relevant.
two planning areas. planning area has the attribute PRDID
(for example in Demand), while the target Only attributes of data type
planning area has MATID (for example in INTEGER can be mapped to
Response). attributes of data type INTEGER
or DECIMAL.

In the case of all other data types,

the mapped attributes must be
identical.

Mapping is applied to aggregation

level and lters.

TARGET_MAP_ATTRIBUTEn The target attribute to which you want to Required if attribute mapping is
The master data types of the
copy data when copying data between necessary
attributes are not relevant.
two planning areas.

Mapping is applied to aggregation

level and lters.

TARGET_PERIODID or The technical ID or name of the target Required if different time pro les are used
If the time pro le level of the
TARGET_PERIODNAME time pro le level when copying key gure and target time pro le level cannot be
target planning area differs from
data between two planning areas. defaulted via the period type.
that of the source planning area,
the DISAGG operator
automatically derives the target
time pro le level based on the
same period type (for example,
Week).

The time pro le level of the target

planning area can be explicitly
speci ed via parameters
TARGET_PERIODID or
TARGET_PERIODNAME.

Attribute Mapping for Copying Key Figure Data Between Planning Areas

As seen in the table above, the parameters SOURCE_MAP_ATTRIBUTEn and TARGET_MAP_ATTRIBUTEn can be used to map attributes between the source
and target planning areas. You can map also attributes that are not part of the planning level; attribute mapping is applied to the aggregation level and lters.

The DISAGG operator maps attributes as follows:

If no attribute mapping is de ned, the operator automatically searches for identical attributes in both planning areas.

If only some attributes are mapped, the operator tries to add missing attributes if they exist in both planning areas.

You can also set up attribute mapping to let the operator know that an attribute exists only in one planning area. This can be used, for example, to apply an attribute
lter only to the source planning area. The following example shows you how to do this:

SOURCE_MAP_ATTRIBUTEn TARGET_MAP_ATTRIBUTEn What does it mean?

PRDID MATID Normal attribute mapping

PRDGROUP PRDGROUP exists only in the source planning area

Handling Conversion-Relevant Key Figures

[Link] 106/128
12/3/2020
If either the source or the target key gure in the disaggregation process is relevant for conversion (for example, currency or unit of measure conversion), you must
specify a conversion-to attribute, for example CURRENCYTO, or UOMTO, in one of the following ways:

As a lter in the planning operator de nition

As a lter in the Run or Schedule dialog box in the SAP IBP, add-in for Microsoft Excel

Scheduling Jobs for the Operator

You can schedule jobs for the DISAGG operator in the following ways:

In the Application Jobs app

In the SAP IBP, add-in for Microsoft Excel

When you want to copy data from one planning area to another, the planning area you specify must be either the source or the target planning area.

 Note
Time selection by dates is not supported if you want to use the DISAGG operator for copying key gure data from one planning area to another.

Copying data between scenarios is not possible.

Packaged Processing of the DISAGG Operator

To optimize the consumption of system memory, and to reduce the risk of locking issues, the system splits the processing of the DISAGG operator into smaller
packages.

Depending on your con guration and system settings, for example, key gure con guration and the aggregation level speci ed, running the disaggregation
(DISAGG) operator can consume a lot of system memory and may even result in out of memory situations.

To help you identify DISAGG operator runs in your system that might potentially consume a lot of system memory, warnings to this effect are added to the operator
log in the following cases:

Data for more than one period is changed

Disaggregation changes more than <n> records on base planning level

The value for the number of records <n> in the warning message comes from the MIN_RECORDS_FOR_MEMORY_WARNING global con guration parameter which
is available in the DISAGGREGATION parameter group. You can change this threshold in the Global Con guration app.

To prevent out of memory situations, and improve system performance, the processing of the DISAGG operator is split into packages of 5 by default. You can
change the number of packages the operator is split into in the following ways:

How? What is the result?

Specify the number of packages you want the DISAGG operator run to be split into by The system splits the run of all of the DISAGG operators in your system that are based
entering the value in the NUMBER_OF_PROCESSING_PACKAGES global con guration on the DISAGG operator type into the number of packages you specify.
parameter.

Specify the number of packages you want the DISAGG operator run to be split into by The system splits the run of the speci c DISAGG operator for which you specify the
entering the value in the NUMBER_OF_PROCESSING_PACKAGES parameter of a value into the number of packages you enter.
speci c DISAGG operator.

Specify 1 to disable packaged processing by entering this number in the The processing of the DISAGG operator is not split into packages.
NUMBER_OF_PROCESSING_PACKAGES global con guration parameter or the
NUMBER_OF_PROCESSING_PACKAGES parameter of a speci c DISAGG operator.  Note
This setting may be used for operator runs that are executed as part of an
interactive planning process on a small volume of data.

The system takes your entries into consideration in the following order:

1. It checks whether there is a value entered in the NUMBER_OF_PROCESSING_PACKAGES parameter of the speci c DISAGG operator.

2. If there is no value for the speci c DISAGG operator, it checks whether there is a value entered in the NUMBER_OF_PROCESSING_PACKAGES global
con guration parameter.

3. If the default value of the global con guration parameter has not been changed, it takes the default value of the global con guration parameter.

If a value is de ned for parameter NUMBER_OF_PROCESSING_PACKAGES the system tries to split the processing into smaller packages in the following way:

[Link] 107/128
12/3/2020
The packages are created by periods. If the number of copied periods is less than the value of the NUMBER_OF_PROCESSING_PACKAGES parameter, then
one package is created per period.

The packages are processed sequentially.

Changed key gure values are stored per package. This means that if the process fails while processing a certain package, the key gure values changed by
previous packages are already stored.

If the target key gure is enabled for change history, then the changes of every package get a unique change history ID (with the same reason code and
comment).

Related Information
Global Con guration Parameters
Disaggregation (DISAGG) Operator

Example: Setting Up the Disaggregation Operator

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context
The DISAGG planning operator type is delivered as part of the standard SAP content for planning operators. In this example, a DISAGG_PROMO operator is created
to read values of the PROMOUPLIFT key gure at product-customer level, and to disaggregate the key gure values to the PROMOSPLITALL key gure at product-
location-customer level.

To set up the disaggregation operator, use the Planning Operators app.

 Note
To con gure planning operators, the Planning Model business catalog must be assigned to a business role assigned to your user.

The following example illustrates how to set up a disaggregation operator.

Steps
1. In the Planning Operators app, choose DISAGG from the list of planning operator types on the left side of the screen.

2. To add a planning operator, select the + (Add Planning Operators) button.

Make the following entries:

Field Entry

Name DISAGG_PROMO

Description Disaggregation for Promotion

Interactive Mode No

Batch Mode Yes

Filter Mode Select or deselect according to whether you want the user to use lters when
running or scheduling the operator in the IBP add-in for Microsoft Excel.

3. Choose De ne Parameters, and enter the following parameters:

Parameter Name Parameter Value

ATTRIBUTE1 PRDID

ATTRIBUTE2 CUSTID

ATTRIBUTE3 PROMOTIONID

ATTRIBUTE4 PROMOTIONSOURCE

DURATION 156

[Link] 108/128
12/3/2020

Parameter Name Parameter Value

PERIODNAME Weekly

PERIOD_OFFSET -104

SOURCE_KFID1 PROMOUPLIFT

TARGET_KFID1 PROMOSPLITALL

4. Save your entries.

5. Assign the planning operator to the relevant planning area. For more information see Assigning a Planning Operator to a Planning Area.

Example: Using the SEQUENTIAL Parameter

You can use the SEQUENTIAL parameter to control whether the system takes the result of one key gure copy and disaggregation into consideration when
performing the subsequent key gure copy and disaggregation.

Study this example about the use of the SEQUENTIAL parameter. To keep the example simple, all key gures have the same base planning level.

Parameter Initial Key Figure Value for a Given Key Figure Value After DISAGG Run Key Figure Value After DISAGG Run
Period
SEQUENTIAL Parameter not Set SEQUENTIAL Parameter Value = X

SOURCE_KFID1 = MARKETINGFCSTQTY 100 100 100

TARGET_KFID1 = 50 100 100

DEMANDPLANNINGQTY

SOURCE_KFID2 = 50 100 100

DEMANDPLANNINGQTY

TARGET_KFID2 = 50 100
CONSENSUSDEMANDPLAN

Inventory Optimization (IO) Operator

The Inventory Optimization (IO) planning operator allows you to run inventory optimization for a given supply chain network.

 Caution
To run the inventory operators, speci c technical IDs de ned by SAP must be used for the relevant master data types, attributes, and key gures. If these
technical IDs are not used, the inventory operators will fail. For more information, see Master Data Types and Key Figures in the application help.

Operators
You can de ne the following inventory operators:

Inventory Operator Algorithm Type Parameter Name in Excel Add-In Explanation

Single-Stage Inventory Opt SINGLE STAGE IO Decomposed (single-stage) inventory Optimizes recommended safety stock
optimization locally for each customer-facing product-
location combination in a decomposed
manner. Ideal for running simulations
where you want to determine the impact
on recommended safety stock of local
changes to the input key gures after
multistage inventory optimization has
been run.

Multi-Stage Inventory Opt MULTI STAGE IO Global (multi-stage) inventory Optimizes recommended safety stock
optimization globally across all products and locations
of the supply chain. Minimizes total
safety stock holding cost while ensuring
that all customer service level targets are
met.

[Link] 109/128
12/3/2020

Inventory Operator Algorithm Type Parameter Name in Excel Add-In Explanation

Calculate Inventory Components IO_DETERMINISTIC Calculate Target Inventory Components Calculates Inventory components, that is,
the types of inventory that comprise the
total inventory for a given item. By
delineating what type of inventory exists
in the supply chain, more granular
inventory optimization calculations can
be made.

 Note
The Multi-Stage Inventory Opt operator, the Calculate Inventory Components, the Calculate DDMRP buffer levels, and the Recommend Decoupling Points
(Solve) operators calculate outputs for all demand streams, and therefore do not take permission lter settings into consideration during calculations.

The operator Single-Stage Inventory Opt takes permission ltering into consideration when calculating outputs.

Planning Horizon Parameter

To use different planning horizons than the standard for a planning area, you can de ne the planning horizon parameter for inventory optimization operators. The
following operators support the planning horizon parameter:

Multi-Stage Inventory Opt

Calculate Inventory Components

Parameter Description

PLANNING_HORIZON Positive integer value that represents calendar weeks.

Example: Create Multi-Stage Inventory Opt Operator With a Planing Horizon

The following example illustrates how to set up a Multi-Stage Inventory Opt operator with a planning horizon of ve calendar weeks:

Steps

1. Navigate to Planning Operators app.

2. Select the IO planning operator type and click the “+” button to add a planning operator.

Make the following entries:

Field Entry

Name Multi-Stage IO PH 5

Description Multi-Stage IO PH 5

Interactive Mode No

Batch Mode Yes

Filter Mode Yes

3. Choose De ne parameters.

4. Enter the ALGORITHM_TYPE parameter with MULTI STAGE IO as the parameter value.

5. Enter the PLANNING_HORIZON parameter with 5 as the parameter value.

6. Assign the operator to the relevant planning area (see Assigning a Planning Operator to a Planning Area).

Result

You can run the planning operator in the SAP Integrated Business Planning add-in for Microsoft Excel in simulation mode and batch mode.

Activating Planning Models

Before you can use the data you have set up in the application, you have to activate your planning model. When the model is activated, the infrastructure to store
and access planning data is created based on the metadata of the custom model you created.

[Link] 110/128
12/3/2020

 Recommendation
We recommend that before activation, you run the consistency checks on the model entities you want to activate. If the check log contains errors, correct them
before you activate the model entities.

You must activate your model entities in the following order:

1. Time pro les

2. Master data types

3. Planning areas

You can also activate a planning model in one step, by activating a planning area together with its related time pro le and related master data types.

 Note
Activating a planning area doesn't activate the data sharing plans. You have to activate data sharing plans, if needed, in a separate step.

Activation runs as an application job. You can monitor the job status, display the job details, and cancel the job in the Application Jobs app.

You can schedule the activation of time pro les, master data types, and planning areas using the prede ned Planning Model Activation template in the Aplication
Jobs app.

 Recommendation
SAP recommends that you arrange a business downtime when you want to perform model activation. Particularly, the following tasks, application jobs, and
processes mustn't run when you activate a planning area, otherwise the system may not be able to schedule the activation job, or activation may run
signi cantly longer, or it may fail:

Data integration (using the Data Integration Jobs app, SAP Cloud Platform Integration for data services, or SAP HANA Smart Data Integration)

Data integration for time periods and master data types mustn't run while an activation is running. Data integration for snapshots and key gure values
mustn't run for the planning area you're going to activate.

Creation and change of planning views, editing data, and simulations in the IBP Excel add-in

No users should be logged on in the IBP Excel add-in while activation is running.

Application jobs for planning operators

Make sure that no planning operators are running in the planning area you're going to activate.

Application jobs for creating time periods for time pro les

Make sure that no time period creation jobs are running for the time pro le you're going to activate either directly, or together with a planning area.

Application jobs for data lifecycle management

Make sure that no data purging jobs are running that could con ict with the master data types or with the key gures in the planning area you're going to
activate.

 Note
You can activate a planning model and run the consistency checks for a different model in parallel, but you can't activate two planning models or two sets of
modeling entities at the same time.

Once you have activated your planning model, you can copy it, and, if needed, delete model entities by active deletion.

Related Information

Statuses of Model Entities

The background information provided in this chapter can help you better understand how modeling and activation in SAP Integrated Business Planning works.

Model Entities and Their Activation

In SAP Integrated Business Planning, planning models are based on the following model entities:

Attributes

Master data types

[Link] 111/128
12/3/2020
Time pro les

Planning areas

Planning levels

Key gures

Versions

Miscellaneous additional entities: planning operators, global con guration parameters, and reason codes

Activating Model Entities

Out of these entities, you can perform activation for the following ones:

Master data types

The activation of a master data type will activate all attributes assigned to the master data type as well.

Time pro les

The activation of a time pro le will activate all attributes assigned to the time pro le as well.

Planning area

The activation of a planning area will activate all attributes assigned to the planning area, the key gures, planning levels and versions as well.

You can also include the master data types used in the planning area (and with them, the attributes they include) in the activation.

Other entities can be activated only together with the higher-level entity that includes them.

Statuses of a Model Entity

A time pro le, a master data type, and a planning area can have the following statuses:

Inactive

An entity has the inactive status either when it’s created and rst saved, or when the active entity is changed and saved.

Active

An entity has the active status after it has been activated, either directly or indirectly (together with a higher-level entity).

Pending deletion

If an active entity is marked for deletion, it has the pending deletion status. Actual deletion takes place with the next activation of the entity. Until then, you
can revert the pending deletion status to active.

 Note
Planning levels, key gures, and versions can have the same three statuses. However, you can't activate these model entities on their own, only via the planning
area that includes them.

Attributes are a special case. An attribute has a status on its own, but you can activate it only as part of the activation of a higher level entity (master data type, time
pro le, planning area). An attribute can have the following statuses:

Inactive

An attribute has the inactive status either when it’s created and rst saved, or when the active attribute is changed and saved.

Active

An attribute has the active status after it has been activated (together with a master data type, a time pro le, or a planning area).

Instances of a Model Entity

Along with statuses, entity instances are also a key concept in model activation. An instance is a saved state of a model entity, and it is classi ed by the status.

One or two instances – which have different statuses – of a model entity can exist at the same time:

Inactive

The entity is created and rst saved, but not activated yet.

Active

[Link] 112/128
12/3/2020
The entity has been activated, and has not been changed since the last activation.

Active and inactive

The entity has been activated (active instance), and changed since the last activation (inactive instance).

Active and pending deletion

The entity has been activated (active instance), and marked for deletion since the last activation (pending deletion instance).

In the planning area worklist of the Planning Areas app, you can choose to display the most recent instance of the model entity (Show Latest), or the latest active
instance (Show Active). You can only display the latest active version of a model entity, you cannot edit it.

 Note
The inactive instance of a higher-level entity refers to the latest instance of the dependent entity, be it active or inactive.

For example, if both an attribute and a master data type that uses the attribute have inactive and active instances, the active instance of the master data type
uses the active instance of the attribute, while the inactive instance of the master data type uses the inactive instance of the attribute.

Status Changes of a Model Entity

The life cycle of a model entity starts with the inactive status, after the entity has been created and saved. The entity can get into the active status by activation.

Changing an Active Entity

When an active entity is changed, but not activated yet, the active instance of the entity stays unchanged, and an inactive instance is created, which stores the
changes.

The active instance is used throughout SAP Integrated Business Planning, for example, in the IBP Excel add-in, in planning operators, and in data integration. Once
the entity is activated again, the changes take effect, and the inactive instance becomes the active (and, until the next changes, the only) instance of the entity.

 Note
If you have activated an entity, you cannot restore the previous active instance.

Deleting an Entity

You can use active deletion to delete active master data types, planning levels, key gures, planning areas, and time pro les. For more information, see Deleting
Active Objects (Active Deletion).

With active deletion, the inactive instance of the entity is immediately deleted. If there is an active instance of the entity, the active instance remains unchanged,
and a pending deletion instance is created. These two instances exist in parallel until the next activation of the entity.

Until the next activation, the active instance of the entity is used throughout SAP Integrated Business Planning, for example, in the IBP Excel add-in, in planning
operators, and in data integration. The next activation will delete the entity (both the active and the pending deletion instances), and the data that has been
uploaded for the given entity.

If the entity has only an inactive instance, it is immediately deleted if you choose Delete (active deletion is not available in this case).

 Note
In the case of a planning area deletion, choosing Delete (or Delete with Dependencies) deletes the planning area together with its dependent master data types
and time pro le.

If all objects (the planning area and its dependencies) are inactive, you can delete them in one step, while active objects are rst set to Pending Deletion and you
need to activate them in the relevant app to complete the deletion. In the case of inactive objects with an active instance existing in the system, the inactive
instances are deleted and the active instances are set to Pending Deletion.

Example: Changing Model Entities That Are Dependent on Each Other

In this example, we start with 3 attributes (A1, A2, and A3), which are used in a master data type (MDT1), which is then used in a planning area (PA1).

We then create a new attribute, A4, add it to the MDT1 master data type, and activate the master data type. After it, we assign the A4 attribute to the PA1 planning
area, and activate the PA1 planning area.

The next step is creating a new attribute, A5, and adding it to the MDT1 master data type, without activating the master data type.

As the last step, we change the period offset in the PA1 planning area (this change does not have any effect on attributes or master data types).

[Link] 113/128
12/3/2020
Starting Point

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3

Planning area PA1 Uses A1, A2, A3, and MDT1 Active

Step 1: Creating the A4 Attribute, and Adding It to the MDT1 Master Data Type

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Attribute A4 Selected for use in MDT1 Inactive The A4 attribute is saved, and included in
the MDT1 master data type.

Until MDT1 is activated, only the inactive

instance of A4 exists.

Master data type MDT1 Used in PA1 Active Until MDT1 is activated again, the active
instance is unchanged.
Uses A1, A2, A3

Used in PA1 Inactive The inactive instance of MDT1 is created

to store the changes - in this case, the A4
Uses A1, A2, A3, A4
attribute added to MDT1.

Planning area PA1 Uses A1, A2, A3, and MDT1 Active

The SAP Integrated Business Planning, add-in for Microsoft Excel (SAP IBP, add-in for Microsoft Excel), the data integration, and other functions of SAP IBP
continue using the active instance of the MDT1 master data type.

Step 2: Activating the MDT1 Master Data Type

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Attribute A4 Used in MDT1 Active The A4 attribute becomes active when

the MDT1 master data type is activated.

The inactive instance of A4 does not exist

any longer.

Master data type MDT1 Used in PA1 Active The previously inactive instance of MDT1
becomes the active - and only - instance
Uses A1, A2, A3, A4
of MDT1.

There is no inactive instance of MDT1.

Planning area PA1 Uses A1, A2, A3, and MDT1 Active Activating the MDT1 master data type has
no effect on the PA1 planning area. It still
has one active version, which is
unchanged

Step 3: Transporting or Exporting and Importing the MDT1 Master Data Type

Step 4: Assigning the A4 Attribute in the PA1 Planning Area and Activating the PA1 Planning Area
[Link] 114/128
12/3/2020

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Attribute A4 Used in MDT1 and in PA1 Active The A4 attribute is now used in the PA1
planning area as well.

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3, A4

Planning area PA1 Uses A1, A2, A3, A4, and MDT1 Active The active instance of the PA1 planning
area now also includes the A4 attribute.

The new active instance of PA1

overwrites the previous active instance.

Step 5: Transporting or Exporting and Importing the PA1 Planning Area

Step 6: Creating the A5 Attribute, and Adding It to the MDT1 Master Data Type

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Attribute A4 Used in MDT1 and in PA1 Active

Attribute A5 Used in MDT1 Inactive The A5 attribute has been saved, and
included in the MDT1 master data type.
Until MDT1 is activated, only the inactive
instance of A5 exists.

Master data type MDT1 Used in PA1 Active As no activation has happened, the active
instance of MDT1 is unchanged.
Uses A1, A2, A3, A4

Used in PA1 Inactive Adding A5 to MDT1 results in an inactive

instance of MDT1.
Uses A1, A2, A3, A4, A5

Planning area PA1 Uses A1, A2, A3, A4, and MDT1 Active

The SAP IBP, add-in for Microsoft Exce, the data integration, and other functions of SAP IBP continue using the active instance of the MDT1 master data type.

Step 7: Changing the Period Offset of the PA1 Planning Area

Changing the period offset affects the planning area only, and not the master data types and attributes the planning area uses.

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Attribute A4 Used in MDT1 and in PA1 Active

Attribute A5 Used in MDT1 Inactive

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3, A4

Used in PA1 Inactive

Uses A1, A2, A3, A4, A5

[Link] 115/128
12/3/2020

Entity Uses Instance Comment

Planning area PA1 Uses A1, A2, A3, A4, and MDT1 Active The active instance of PA1 still refers to
the active instance of MDT1.

Uses A1, A2, A3, A4, A5, and MDT1 Inactive The inactive instance of PA1 still refers to
the inactive instance of MDT1.

 Note
In such cases, when an inactive instance of a planning area refers to an inactive instance of a master data type, you should either activate the master data type
before you activate the planning area, or activate the planning area with the Include Related Time Pro le and Master Data Types option selected.

Step 8: Activating the PA1 Planning Area

Step 9: Transporting or Exporting and Importing the PA1 Planning Area

Example: Deleting an Attribute from an Active Master Data Type and Active Planning Area
In this example, we start with 3 attributes (A1, A2, and A3), which are used in a master data type (MDT1), which is then used in a planning area (PA1). Our goal is to
delete the A3 attribute.

To delete the A3 attribute, which is used in a master data type, which is then used in a planning area, you must work top down. First, remove the attribute from the
planning area, then from the master data type.

Starting Point

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3

Planning area PA1 Uses A1, A2, A3, and MDT1 Active

 Note
Make sure that the A3 attribute is not used in any planning levels. You cannot delete an attribute if it is used in higher-level entities.

Step 1: Marking the A3 Attribute for Deletion in the PA1 Planning Area

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 and in PA1 Active

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3

Planning area PA1 Uses A1, A2, A3, and MDT1 Active

Uses A1, A2, and MDT1 Inactive The inactive instance of the PA1 planning
area does not include the A3 attribute.

Step 2: Activating the PA1 Planning Area

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

[Link] 116/128
12/3/2020

Entity Uses Instance Comment

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 Active The attribute is not used in the PA1
planning area anymore

Master data type MDT1 Used in PA1 Active

Uses A1, A2, A3

Planning area PA1 Uses A1, A2, and MDT1 Active The PA1 planning area has an active
instance only, which does not include the
A3 attribute.

Step 3: Transporting or Exporting and Importing the PA1 Planning Area

Step 4: Marking the A3 Attribute Pending Deletion in the MDT1 Master Data Type

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 Used in MDT1 Active

Master data type MDT1 Used in PA1 Active The active instance is unchanged, it still
includes the A3 attribute.
Uses A1, A2, A3

Used in PA1 Inactive An inactive instance of the MDT1 master

data type has been created, which does
Uses A1, A2
not include the A3 attribute.

Planning area PA1 Uses A1, A2, and MDT1 Active

An attribute does not have a pending deletion status, so the active instance of the attribute is unchanged. The A3 attribute is pending deletion in relation to the
MDT1 master data type only. If, unlike this example, other maser data types also use the A3 attribute, A3 is still available to them.

Step 5: Activating the MDT1 Master Data Type

Entity Uses Instance Comment

Attribute A1 Used in MDT1 and in PA1 Active

Attribute A2 Used in MDT1 and in PA1 Active

Attribute A3 No uses Active The A3 attribute is not used in any

higher-level entities.

The active instance of the attribute is

unchanged.

Master data type MDT1 Used in PA1 Active The active instance now does not include
the A3 attribute.
Uses A1, A2

Planning area PA1 Uses A1, A2, and MDT1 Active

Step 6: Transporting or Exporting and Importing the MDT1 Master Data Type

Activating Time Pro les

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Context

[Link] 117/128
12/3/2020
You must activate the time pro le to be able to create time periods for it, and to store and calculate time-dependent planning data in a planning area that uses this
time pro le.

 Note
Activate a time pro le before you activate the planning areas that use the time pro le.

Alternatively, when you activate a planning area, you can select to activate it together with the related time pro le and the related master data types in one
activation run.

Procedure
1. In the Time Pro les app, select the time pro le you want to activate.

You can select multiple time pro les.

2. (Optional) Choose Check.

The system executes three types of checks:

Validating the de nition of the time pro le

Validating the dependencies and connections of the time pro le, for example, connections to planning areas

Checking if the changed time pro le is still consistent with the already existing time periods

A log with the check results is available. The link in the Last Action Status column takes you to the check log in the Application Logs app.

 Note
There are checks that can be executed only during activation. Thus, activation of a time pro le might fail even if the previously executed checks were
successful.

3. Select the time pro le you want to activate, and choose Activate.

You can select multiple time pro les.

An application job is scheduled. If the job has nished, and activation was successful, the time pro le is active. To monitor the job and to check the job
details, launch the Application Jobs app.

The activation log is available. The link in the Last Action Status column takes you to the activation log in the Application Logs app.

Related Information
Time Pro les
Application Logs

Activating Master Data Types

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

If you want to activate a planning area, make sure that you activate the model entities in a speci c order. Activate the master data types only after you have
activated the relevant time pro les, or activate them together when you activate a planning area.

You can activate a master data type that is not assigned to a planning area independently of the time pro le.

 Recommendation
The following tasks, application jobs and processes mustn't run while activation of one or more master data types is running, otherwise activation may run
signi cantly longer, or it may fail:

Data integration (using the Data Integration Jobs app, SAP Cloud Platform Integration for data services, or SAP HANA Smart Data Integration)

Data integration for master data types and key gure values mustn't run while an activation is running.

Creation and change of planning views, editing data, and simulations in the IBP Excel add-in

No users should be logged on in the IBP Excel add-in while activation is running.

Application jobs for planning operators

Make sure that no planning operators are running in the planning area you're going to activate.

[Link] 118/128
12/3/2020
Application jobs for data lifecycle management

Make sure that no data purging jobs are running that could con ict with the master data types you're going to activate.

Context
You must activate a master data type to be able to create the master data records (through data integration).

Procedure
1. In the Master Data Types app, select one or more master data types you want to activate.

2. (Optional) Choose Check.

By default, the system checks the consistency of the master data types you selected together with their dependent master data types. To check only the
master data types you selected, choose Check Without Dependencies.

The system performs the following three types of checks:

Checking the de nition of the master data type

Checking the dependencies and connections of the master data type, for example, connections to other master data types, to planning areas, or the
existence of attributes.

Checking if the changed master data type is still consistent with the already existing data.

A log with the check results is available. The link in the Last Action Status column takes you to the check log in the Application Logs app.

If there are errors in the check log, correct them before you activate the master data types.

 Note
There are checks that run only during activation. Thus, activation of a master data type might fail even if the previous checks were successful.

3. After a successful check, choose Activate.

By default, the system activates the master data types you selected together with their dependent master data types. To activate only the master data types
you selected, choose Activate Without Dependencies.

An application job is scheduled. If the job has nished, and activation was successful, the master data types are active. To monitor the job and to check the
job details, launch the Application Jobs app.

The activation log is available. The link in the Last Action Status column takes you to the activation log in the Application Logs app.

 Note
When you activate a master data type, the attributes the master data type uses are activated as well. You can't activate an attribute separately.

Next Steps
If you selected numerous master data types for activation, and activation takes longer, you don't have to wait until activation is complete. You can leave the Master
Data Types app. To check the activation status and steps, go to the Application Logs app to display the activation log.

Related Information
Master Data Types
Application Logs
Data Integration Scenarios

Activating Planning Areas

Activate your planning areas to be able to upload data into them, and to perform your planning tasks.

 Note
We recommend to activate your planning areas every 90 days or with every new release. This is needed to enable further features and to improve performance.
To nd out when your planning areas were last activated, go to the Planning Areas app, and search for the planning area you are interested in. You can nd the
date of the last activation in the Activated On column.

You can activate your planning areas in the Planning Areas app only; the Con guration app is no longer available.

[Link] 119/128
12/3/2020
When you activate your planning area, you can decide to activate full scope or limited scope (for certain releases only); with dependencies and without
dependencies, as described below.

Activate with Dependencies

Use this option if you want to activate your planning area with the dependent time pro le and master data types.

Activate without Dependencies

Use this option if you you have already activated the dependent time pro le and master data types as well, so you only have to activate your planning area.

Activate with Full Scope (Recommended)

Use this option if you want to run all the activation checks and do not want to suppress any errors when you activate your planning areas.

To make sure that your planning area is complete and does not contain erroneous con guration, SAP recommends that you activate your planning area with full
scope.

Activate with Limited Scope

For certain releases, you have the possibility to suppress certain activation errors (suppressible errors) and activate your planning area with limited scope.

If you activate with limited scope, you can decide to skip certain error types for a given activation of a planning area. By doing so, you can activate your planning
area successfully, but it might result in erroneous con guration and incomplete functionality. Please note that this is a temporary solution; you need to correct your
model con guration - as described in the long text of the error – as soon as possible. After the lifespan of a suppressible error is over, the error cannot be
suppressed anymore and the activation of the planning area will fail.

You can nd a complete list of error typess that you can suppress in Suppressible Errors.

How to Suppress Errors and Activate with Limited Scope

1. In the Planning Areas app, select the planning area you want to activate.

2. Expand the Activate button, and choose Limited Scope, with Dependencies or Limited Scope, No Dependencies depending on your preferences.

3. In the Suppressible Errors dialog box, select the error categories you want to suppress.

Click on the error types you want to suppress to nd additional information about how to correct the incomplete or erroneous con guration. Make sure you
x the issue before the Correct Before Release date. After that, you cannot suppress the error anymore, and the activation of the planning area will fail if the
cause of this error still persists.

4. Choose Activate with Limited Scope.

Suppressing an error is applied for the given activation only. If you don't correct the con guration, the next activation will fail.

 Recommendation
SAP recommends that you arrange a business downtime when you want to perform model activation. Particularly, the following tasks, application jobs and
processes mustn't run while activation is running, otherwise activation may run signi cantly longer, or it may fail:

Data integration (using the Data Integration Jobs app, SAP Cloud Platform Integration for data services, or SAP HANA Smart Data Integration)

Data integration for time periods and master data types mustn't run while an activation is running. Data integration for snapshots and key gure values
mustn't run for the planning area you're going to active.

Creation and change of planning views, editing data, and simulations in the IBP Excel add-in

No users should be logged on in the IBP Excel add-in while activation is running.

Application jobs for planning operators

Make sure that no planning operators are running in the planning area you're going to activate.

Application jobs for creating time periods for time pro les

If you're going to active the planning area with its related time pro le, make sure that no time period creation jobs are running for that time pro le.

Application jobs for data lifecycle management

Make sure that no data purging jobs are running that could con ict with the master data types or with the key gures in the planning area you're going to
activate.

[Link] 120/128
12/3/2020

Activating Planning Areas in the Planning Areas App

Activate your planning areas in the Planning Areas app.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

You have activated the time pro le and the master data types that are assigned to the planning area, or you activate the planning area together with its related time
pro le and related master data types.

Context
You must activate the planning area rst to be able to upload data into it, and to perform planning tasks. If you make any changes to your planning area after
activation, activate it again to be able to work with the changed palnning area.

Procedure
1. Select the planning area you want to activate.

2. (Optional) Click Check or choose Check with Dependencies from the dropdown.

The system validates the following:

The de nition of the planning area, of the versions and planning levels of the planning area, and the de nitions and calculations of the key gures in
the planning area.

The dependencies and connections of the planning area, for example, connection to a time pro le, or the existence of the assigned attributes

You can decide to check the planning area with or without dependencies. If you choose Check or Check With Dependencies, connection to the latest
inactive instance of the master data and time pro les are checked, in addition to the planning area. If you choose Check Without Dependencies, connection
to the latest active instance of the master data and time pro les are checked, in addition to the planning area. We recommend that you run the check and x
any errors before activating the planning area.

 Note
Check

If you choose Check Without Dependencies and the check detects a model entity that does not have an active instance, it issues an error message, and
stops performing the remaining checks for the given model entity.

You can view the detailed progress of your check by clicking the Last Action Status link.

Clicking the link opens a dialog, where your can view the details of the action and check its progress while it is running. The status and progress of a running
action is automatically updated in the dialog every 5 seconds, but you can also update it manually using the Refresh button, which becomes active 5
seconds after each refresh.

From the dialog you can navigate to the Application Logs app and view all logs or display the log details for the current item.

In the Application Logs app, for certain messages, which originate from complex situations, you'll nd additional information in the long text attached to the

message, which you can call up by clicking the  (Details View) icon in the Long Text column.
If there are errors in the check log, correct them before you activate the planning area.

 Note
There are checks that run only during activation. Thus, activation of a planning area might fail even if the previous checks were successful.

3. After a successful check, choose Activate, and select the type of activation you want to run from the dropdown list. You can choose from the following types
of activation:

Full Scope, with Dependencies

Full Scope, No Dependencies

Limted Scope, with Dependencies

Limited Scope, No Dependencies

An application job is scheduled. If the job has nished, and activation was successful, the planning area is active. To monitor the job and to check the job
details, launch the Application Jobs app.

You can view the detailed progress of your activation by clicking the Last Action Status link.

[Link] 121/128
12/3/2020
Clicking the link opens a dialog, where your can view the details of the action and check its progress while it is running. The status and progress of a running
action is automatically updated in the dialog every 5 seconds, but you can also update it manually using the Refresh button, which becomes active 5
seconds after each refresh.

From the dialog you can navigate to the Application Logs app and view all logs or display the log details for the current item.

In the Application Logs app, for certain messages, which originate from complex situations, you'll nd additional information in the long text attached to the

message, which you can call up by clicking the  (Details View) icon in the Long Text column.

Results
If you activate a planning area, all attributes assigned to the planning area, the key gures, planning levels and versions will be activated, as well as the time pro le
that is assigned to the planning area, and the master data types used in the planning area (and with them, the attributes they include).

If you have selected the Activate Without Dependencies option, only the attributes assigned to the planning area, the key gures, planning levels and versions will
be activated.

Next Steps
Activating a planning area doesn't activate the data sharing plans. Activate data sharing plans, if needed, in the Manage Data Sharing Plans app.

Related Information
Planning Areas
Time Pro les
Master Data Types
Application Logs
Data Integration Scenarios

Enhanced Version of Planning Area Activation

An enhanced version of the planning area activation has been enabled for all customers as of 1911.

The enhanced activation not only provides a faster, more stable and robust activation of the planning area, but forms the basis of certain new features, such as
simpli ed key gure calculations, as well.

This change is also depicted in the activation log. Open the log of an activation that took place after the upgrade to IBP 1911. Message Activation of &1 selected
objects started (enhanced activation). (&1 stands for the number of objects) indicates that the system uses the enhanced version of planning area activation.

Pay attention to the speci c modeling cases described below.

Aggregation of a Key Figure Other Than the Output Key Figure

 Example
KF1@REQUEST = SUM(KF111@PERS1), and KF111 is speci ed as the input key gure.

This case is relevant only in planning areas that were created earlier than IBP 1705.

To identify the affected calculation de nitions, in the activation log, or in the log of the consistency check of the planning area, look for messages of this type:
Calculation &1@&2 must not contain aggregation of a different key gure., where &1 stands for the ID of the key gure, and &2 stands for the ID of the calculation
de nitions listed in the log.

To have the same values for the affected key gures as before, modify the calculation de nition so that the key gure in the calculation expression is identical with
the key gure marked as input, and with the output key gure.

Using Calculated Key Figure Value Even If Stored Value Exists

 Example
Let's take the SKF@BASEPLLEVEL stored key gure, and the CKF@PL1 calculated key gure.

Calculation 1 is a defaulting: SKF@BASEPLLEVEL=IF(ISNULL(SKF),1,0), where SKF is speci ed as a stored input.

Calculation 2: CKF@PL1 = KF1@BASEPLLEVEL * SKF@BASEPLLEVEL, where both KF1@BASEPLLEVEL and SKF@BASEPLLEVEL are speci ed as
stored inputs, even though a calculation for SKF@BASEPLLEVEL exists.

[Link] 122/128
12/3/2020
To identify the affected calculation de nitions, in the activation log, or in the log of the consistency check of the planning area, look for warning messages of this
type: Calculation &1@&2: Calculation for KF &3 exists, but stored value is used., where &1 stands for the ID of the key gure, &2 stands for the ID of the planning
level, and &3 stands for the ID of the input key gure.

Case by case, review the listed calculation de nitions, and make corrections if needed.

In the previous version of activation, sometimes (typically in calculations at base planning level) the calculated value of the input key gure was used, even if a
stored value existed, and was speci ed as input for the calculation. With the enhanced version of activation, the system consistently uses the stored value if that
was speci ed as input for the calculation. From the different behaviors of the activation versions, differences may occur in the output key gure values of the
affected calculations.

If there is a difference, and you want to go on with the values that were calculated previously using the calculated value of the input key gure, change the inputs of
the calculation by not selecting the input as stored.

Suppressible Errors
For certain releases, you have the possibility to suppress the activation errors below and activate your planning area with limited scope. After this grace period is
over, and the suppressible errors have turned into errors, you can no longer activate your planning areas if these errors occur. Correct the invalid con gurations as
soon as possible to be able to activate your planning areas.

For more information about how to suppress these errors and activate with limited scope, see Activating Planning Areas.

*S* Calculation &1@&2: Expression doesn't start with aggregation function

In the calculation for the key gure at the planning level, the input planning level contains one or more root attributes that aren't root attributes of the output
planning level, or the output planning level doesn't contain these attributes at all. Such a calculation is an aggregation, and its calculation expression must start with
one of the aggregation functions: SUM, MIN, MAX, or AVG.

To correct the con guration and activate with full scope, make one of the following changes:

Split up the calculation into two calculations: an aggregation and a defaulting, for example. Pay attention to the sequence of these calculations.

In case you assign a value to a key gure, and the output planning level doesn't contain all root attributes of the input planning level. Specify the aggregation
function (SUM, MIN, MAX, or AVG).

Choose a different input planning level that has the same set of root attributes as the output planning level.

*S* PL &1 and PL &2: Both cannot be used as base PL of stored key gures
There are planning levels that share the same set of root attributes (not considering the time attribute), but they have different sets of non-root attributes (not
considering the time attribute). Both planning levels are used as the base planning level of one or more stored key gures.

To correct the con guration and activate with full scope, make one of the following changes:

Change one of the planning levels, so that they have the same set of root attributes and the same set of non-root attributes. Only attributes from master
data types are taken into consideration, the time attributes don't need to match.

Decide which of the planning levels you want to use as the base planning level of stored key gures. Choose a different base planning level for each stored
key gure whose base planning level is the other planning level. Each planning level that is used as the base planning level of stored key gures must have a
different set of root attributes.

For more information see, SAP Knowledge Base Article 2875816 .

*S* Stored values of KFs, with different base PLs, are read from PL &1
In multiple key gure calculations, where the stored values of key gures are used at the same input planning level, the key gures cannot have different base
planning levels.

All key gures that are used as stored inputs at the same planning level must have the same base planning level.

To correct the con guration and activate with full scope, make one of the following changes:

Before making any corrections, check your activation log and look for the error message Stored key gure read from an incompatible planning level. If you have
run into this error during activation as well, x it rst as it might solve the problem of stored key gures with different base planning levels.

If the problem still persists, proceed as follows:

The attachment of the messages in the activation log contains a list of calculations divided into the sections below:

[Link] 123/128
12/3/2020
Calculations where the input planning level of stored key gures is their base planning level.

Calculations where the input planning level of stored key gures does not match their base planning levels.

Depending on your business requirements, make one of the following changes:

Use the base planning level of the key gures as the input planning level in the calculation de nitions.

Change only the calculations where the input planning level (where the stored value of a key gure is used) is not the base planning level of the key gure. As
result, all stored key gures will be sourced from their base planning levels, which are the recommended approach.

If your business requirements justify that you use the stored values of key gures at a planning level other than their base planning levels, create a copy of
each base planning level (with the same set of root and non-root attributes), and use the stored value of the key gure at this compatible planning level.

As a result, all stored key gures will be sourced from a planning level that is compatible with their base planning level, that is, they share the same root and
non-root attributes.

Select one of the base planning levels listed in the attachment, and for each key gure use it as its base planning level.

As a result, all stored key gures sourced from the same input planning level, will have the same base planning level.

*S* Calc. &1@&2: PL of input KF &3 has more attr. than base PL &4
In calculation de nitions, an input planning level where the stored value of a key gure is used cannot have more attributes than the base planning level of the given
key gure. That is, the input planning level of a calculation cannot contain attributes that cannot be sourced from the base planning level.

To correct the con guration and activate with full scope, make one of the following changes:

Use the base planning level of the key gure as the input planning level.

If you want to use the extra attributes that are not available from the base planning level, create a calculation (if not yet available) and use the calculated
value of the key gure instead of the stored value.

Remove these extra attributes from the planning level where the stored value of a key gure is used.

Use a planning level that has the same attributes as the base planning level.

*S* Calc. &1@&2: PL of input KF &3 doesn't contain root attr. of base PL. (Calculation does not exist.)
In calculation de nitions, an input planning level where the stored value of a key gure is used must contain all root attributes of the base planning level of the given
key gure.

To correct the con guration and activate with full scope, make one of the following changes:

Use the base planning level of the key gure as the input planning level.

Create a calculation on the input planning level and use the calculated value of the key gure instead of the stored value. If the aggregation level of the input
key gure is lower, use Split Factor Calculation; if it is higher, use an aggregation.

Use a planning level that has the same attributes as the base planning level.

*S* Calc. &1@&2: PL of input KF &3 doesn't contain root attr. of base PL. (Calculation exists.)
In calculation de nitions, an input planning level where the stored value of a key gure is used must contain all root attributes of the base planning level of the given
key gure.

To correct the con guration and activate with full scope, make one of the following changes:

Since there is a calculation already de ned on the input planning level, use the calculated value of the key gure instead of the stored value.

Use the base planning level of the key gure as the input planning level.

Use a planning level that has the same attributes as the base planning level.

*S* Calc. &1@&2: PL of input KF &3 doesn't contain root attr. of base PL. (Calculation is not used.)
In calculation de nitions, an input planning level where the stored value of a key gure is used must contain all root attributes of the base planning level of the given
key gure.

Furthermore, the calculation is not used in any REQUEST level calculation in the calculation graph.

To correct the con guration and activate with full scope, make one of the following changes:

[Link] 124/128
12/3/2020
1. If you do not want to create a REQUEST level calculation in the calculation graph that is based on this calculation, delete this calculation and all other
calculations that are built on it.

If you want to use the calculation, make one of the following changes depending on your business requirements:

Use the base planning level of the key gure as the input planning level.

Create a calculation (for example, an aggregation) on the input planning level and use the calculated value of the key gure instead of the stored
value.

Use a planning level that has the same attributes as the base planning level.

*S* Key Figure &1 has generated key gure assignment problem
The xing-enabled key gure is inconsistent for either of the following reasons:

There is a missing or inconsistent database entry for the mapping between the xing-enabled key gure and its generated key gures.

The xing-enabled key gure has one or two generated key gures missing.

If a key gure is enabled for xing, it needs to have two generated key gures with an active or inactive (but not pending deletion) mapping between the xing-
enabled key gure and the generated key gures.

To resolve the inconsistency, perform the following steps:

1. Activate the planning area (choose Limited Scope, with Dependencies or Limited Scope, No Dependencies). There will be cases when your activation fails.
Go on to step 2 nevertheless.

2. Select the Enable Fixing checkbox and save the key gure.

3. Deselect the Enable Fixing checkbox and save the key gure.

4. Again: deselect the Enable Fixing checkbox and save the key gure.

5. Again: select the Enable Fixing checkbox and save the key gure.

 Note
These two steps might seem redundant but they are needed to resolve some special cases of the problem, therefore should not be skipped.

6. Perform a check on the planning area, and - provided it doesn't contain any errors - perform a full-scope activation. If the planning area does contain errors,
choose Limited Scope for your activation.

You must resolve the inconsistency before the 2102 release.

*S* Key Figure &1 has version assignment problem in Version &2
The xing-enabled key gure is inconsistent for either of the following reasons:

There is a version that the xing-enabled key gure itself is not assigned to but its generated key gure is.

There is a version that the xing-enabled key gure is assigned to but its generated key gure is not.

If a key gure is enabled for xing, its generated key gures need to be assigned to the same versions that the key gure itself is assigned to.

To resolve the inconsistency, perform the following steps:

1. Deselect the Enable Fixing checkbox for the key gure.

2. If the key gure isn't assigned to the version, assign it and save it.

3. Select the Enable Fixing checkbox and save the key gure again.

4. Perform a check on the planning area, and - provided it doesn't contain any errors - perform a full-scope activation. If the planning area does contain errors,
choose Limited Scope for your activation.

You must resolve the inconsistency before the 2105 release.

Deleting Active Objects (Active Deletion)

SAP Integrated Business Planning allows you to delete active time pro les, master data types, planning levels, key gures, and planning areas. You can also delete
active time pro les, provided the time pro le is not associated with any planning areas.

With active deletion, you change the status of objects to Pending Deletion. The objects are then deleted the next time they are activated.

[Link] 125/128
12/3/2020
When performing active deletion, observe the following sequence:

1. Delete key gures from the version, and activate the planning area.

2. Delete all key gures from any and all calculations, and delete all key gures that are assigned to any planning levels containing the attributes you want to
delete. Activate the planning area.

3. Delete all planning levels that contain the attributes that you want to delete, and activate the planning area.

4. Delete all attributes of the master data type from the planning area, and activate the planning area.

5. Delete the master data type, and then activate the master data type.

6. Delete the relevant time pro les, and then activate the time pro les.

 Note
Virtual and compound master data types: If you select the component or referenced master data types for deletion, the join conditions and all the attributes
associated with those master data types are also marked Pending Deletion. You can independently mark for deletion the assigned attributes and join conditions
associated with the master data types.

Steps for Planning Levels, Key Figures, and Planning Areas

1. In the Planning Areas app, select the speci c object that you want to delete.

2. Click the Delete button.

The Delete dialog appears.

 Note
In the case of a planning area deletion, clicking Delete or choosing Delete with Dependencies in the dropdown deletes the planning area together with its
time pro le and dependent master data types. To delete the planning area only, choose Delete Without Dependencies.

3. Con rm that you want to delete the object.

The status of the object changes to Pending Deletion.

If you want to revoke deletion, choose Restore Active Instance.

4. Activate the planning area.

Result

Once activation is complete, the object you deleted no longer appears in the list of objects.

Steps for Time Pro les and Master Data Types

1. In the Time Pro les or in the Master Data Types app, select the speci c object that you want to delete.

2. Choose Delete.

The Delete dialog appears.

3. Con rm that you want to delete the object.

The status of the object changes to Pending Deletion.

If you want to revoke deletion, choose Restore Active Instance.

4. Choose Activate.

Result

Once activation is complete, the object you deleted no longer appears in the list of objects.

Troubleshooting for Active Deletion

If you receive any of the error messages listed below during active deletion of objects, refer to the Solution column for information about how to proceed.

Deleting Active Master Data Types

Error Message Solution

[Link] 126/128
12/3/2020

Error Message Solution

The selected items are still assigned to one or more planning areas. Unassign the Before deleting the active master data types, delete them from the planning areas
items rst and then delete them. with Active Deletion.

Deleting Master Data Types (and Attributes) from an Active Planning Area

Error Message Solution

The planning area attribute is used in the con guration of planning levels. The Before removing the master data types (and associated attributes) from the planning
deletion may affect calculations. Do you want to continue? area, remove the attributes from each active planning level to which they are assigned.

Deleting Attributes from an Active Planning Level

Error Message Solution

This planning level attribute is used in the con guration of key gures or attribute Before deleting the attribute (or planning level), remove all key gures from the
transformation. The deletion may affect calculations. Do you want to continue? planning level.

This planning level attribute is used in the con guration of key gures or attribute Check whether this action makes sense.
transformation. The deletion may affect calculations. You need to re-import the
data for the affected key gures. Do you want to continue?

Deleting an Active Key Figure

Error Message Solution

Key Figure is being used in (key gure) (version) and cannot be deleted. The key gure you are trying to delete is being used in an active version. Before you
can delete the key gure, remove it from the version with Active Deletion.

Key Figure is being used in (key gure) and cannot be deleted. The key gure you are trying to delete is being used in the calculation of other key
gures (as indicated in the Used in Key Figures eld). Before you can delete the key
gure, you must delete it from all the calculations it is being used in.

Active Deletion Sequence Error

Error Message Solution

I: Activation Running You have activated objects in the incorrect sequence. Proceed as follows (in the
sequence given):

Delete key gures from the version and activate the planning area.

Delete all key gures from any and all calculations, and delete all key gures
that are assigned to any planning level containing the attributes you want to
delete.

Activate the planning area.

Delete all planning levels that contain the attributes you want to delete, and
activate the planning area.

Delete all attributes of the master data type from the planning area, and
activate the planning area.

Delete the master data type and then activate the master data type.

Reason Codes
Reason codes are a set of tags that you can use to keep track of decisions and changes made throughout the planning process.

Reason codes are available in various areas throughout IBP: In the IBP Excel add-in, in the Web-Based Planning app, and in certain application job templates. They
can be viewed in change history and can be shared in SAP Jam.

A user can enter a reason code when saving data in the planning view using the Save Data button or when scheduling an application job. If your organization uses
SAP Jam, users can share the reason code and information about the change and SAP Jam. If your organization uses change history, reason codes are saved for
changes to change-history-enabled key gures they apply to and can be viewed in the change history views.

You can create your own reason codes in the Reason Codes app. Some useful reason codes are provided with SAP Integrated Business Planning.

Creating Reason Codes

[Link] 127/128
12/3/2020
Use the Reason Codes app to create reason codes.

Prerequisites
Make sure you have the necessary authorizations for this activity, that is, the business catalogs required for this activity are assigned to a business role that is
assigned to your business user. For more information see Business Catalogs.

Procedure
1. Open the Reason Codes app.

2. Create a new reason code.

3. In the popup window provide the details for the reason code.

4. Save your changes.

[Link] 128/128