Integrated Planning

Modeling Planning Scenarios  

PurposeTo model your planning scenarios, BI Integrated Planning provides you with the Planning Modeler and the Planning Wizard.

Both tools are Web dynpro-based applications that have to be installed on the SAP J2EE Server. You can allow access to these applications using links or iViews in the portal. It is not necessary, therefore, to install the SAP front end locally.

Planning Modeler

You use the planning modeler to model, manage, and test all the metadata that belongs to a planning scenario.

Interface

The tab pages InfoProvider, Aggregation Levels, Filters, Planning Functions and Planning Sequences are structured in such a way that in the upper part of the screen you have the option to search using objects that can be selected in the system, and a table which displays the results of the search. If you select or create an entry, in the lower part of the screen the system displays the properties of the respective object and provides the user with options to edit the object.

You can modify the interface as required by hiding or showing the subareas.

To modify the table layout, you can:

●     Choose Filter On and enter descriptions in the input-ready rows by which the table columns are filtered. 

●     Choose Settings and select table columns and define the sequence and the general settings for the table layout. When you upgrade, it cannot be guaranteed that the user-specific settings for the table views in the planning modeler will be retained, or that you will be able to reuse them if you have saved them locally.

Functions

The planning modeler provides the following functions: 

●     InfoProvider selection, characteristic relationship and data slice assignments, selection, modification, and creation of InfoProvider of type aggregation level

You define the corresponding settings on the InfoProvider und Aggregation Levels tab pages in the planning modeler.

Tab Page Related Information

InfoProvider The InfoProvider defines the data basis for planning. This involves real-time InfoCubes and MultiProviders. See InfoProviders.

For real-time InfoCubes you can define permitted combinations of characteristic values in the form of characteristic relationships and create data slices for data that you want to protect. For more information, see Characteristic Relationships and Data Slices.

On the Settings tab page, you can set a Key Date as the default key date for planning. See Standard Key Date in Planning Functions.

Aggregation Levels

An aggregation level is a virtual InfoProvider that has been especially designed to be able to plan data manually or change it using planning functions. An aggregation level represents a selection of characteristics and key figures for the underlying InfoProvider and determines as such the granularity of the planning. You can create several aggregation levels for an InfoProvider and, therefore, model various levels of planning and, for example, hierarchical structures. Note, however, that aggregation levels cannot be nested.

You can change an aggregation level by selecting InfoObjects in the lower part of the screen that are to be used or not. For more information, see Aggregation Level.

The following InfoProviders are can be used as the basis for an input-ready query:

●      The InfoProvider is an aggregation level that is defined on a real-time-enabled InfoCube (simple aggregation level).

●      The InfoProvider is an aggregation level that is defined on a MultiProvider (complex aggregation level). The following prerequisites must be fulfilled: The MultiProvider includes

○      at least one real-time InfoCube, and

○      no simple aggregation level.

●      The InfoProvider is a MultiProvider that contains at least one simple aggregation level.

●     Creating and changing filters

With regards to the underlying InfoProvider, filter objects are global objects that restrict the dataset that is used in queries and planning functions. You require filters if you want to use a planning function in a planning sequence.

You define the corresponding settings on the Filter tab page.

Tab Page

Related Information

Filter You can restrict selected characteristics of the InfoProvider to single values, value ranges, hierarchy nodes, history, or favorites and determine whether they can be changed when you execute them. For more information, see Filter.

●     Creating and changing planning functions and planning sequences

You define the corresponding settings on the Planning Functions and Planning Sequences tab pages.

Tab Page Related Information

Planning functions

The system offers you standard planning functions. You can create the following types of planning functions:

●     Unit conversion

●     Generate combinations

●     Formula

●     Copy

●     Delete

●     Delete invalid combinations

●     Repost

●     Repost by characteristic relationships

●     Revaluate

●     Distribute by reference data

●     Distribute by key

●     Currency translation

You can use FOX formulas for complex tasks or define customer-specific planning function types in ABAP using an exit.

For more information, see Planning Functions.

Planning sequences

You can determine steps for the input templates or planning functions by selecting the required aggregation level, filter, and planning function (if applicable). For more information, see Planning Sequences.

●     Creating and changing variables

Variables can be used in queries and different areas of the planning model (see Variables). The system provides a variable wizard wherever you might want to use variables: 

○     When defining characteristic relationships and data slices (InfoProvider tab page)

○     When defining filters (Filter tab page)

○     To parameterize planning functions (Planning Functions tab page)

○     To parameterize queries (in the BEx Query Designer) 

Planning Wizard

To assist you in modeling planning for the first time, the planning wizard offers support in the form of an assistant that leads you through a simple scenario, starting with one InfoProvider.

You perform the following steps:

Step Related Information

InfoProvider You can select an InfoProvider. (You cannot, however, define characteristic relationships, data slices, and settings.)

Aggregation level

You create one or more aggregation levels.

Filter You create one or more filters.

Planning function

You create one or more planning functions.

Test environment

The system integrates your planning model into a planning sequence. You can then execute this in the test environment.

PrerequisitesYou require real-time-enabled InfoCubes as data stores. You have created these InfoCubes in the Data

Warehousing Workbench. For more information, see  Real-Time InfoCubes.

Process Flow       1.      You choose the appropriate InfoProvider.

       2.      You create one or more aggregation levels.

       3.      You create one or more filters.

       4.      You create one or more planning functions.

       5.      You create a planning sequence.

       6.      You test the planning model.

ResultYou have created a planning model on the basis of which you can now run input-ready queries and automatic planning functions.

For more information, see Input-Ready Query.

Modeling Scenarios 

Actual and Plan Data in One InfoCubeIn the simplest case, you have the actual data and the plan data in a real-time InfoCube. You define an aggregation level based on this InfoCube.

The following graphic illustrates this model:

A model of this type allows you to analyze data and enter plan data for one InfoProvider using one query. You also have the option of using planning functions.

You have to use characteristic 0VERSION (or an equivalent characteristic) in the filter to distinguish between the dimensions of the InfoCube that you want to evaluate for reporting and planning, and the dimensions that you want to evaluate using planning functions.

This modeling scenario has the following disadvantages:

●      A large amount of data is contained in one InfoCube.

●      You cannot load actual and plan data in parallel. In the InfoCube, you can only set the mode for

entering plan data or the mode for loading data manually (see  Real-Time InfoCubes).

Due to the manual maintenance effort involved and the corresponding downtime of the InfoCube, we do not recommend this model.   

Actual and Plan Data in Different InfoCubesIn most cases it is useful to have the actual data in an InfoCube and the plan data in a separate real-time InfoCube.

●      The InfoCubes contain less data.

●      If the real-time InfoCube only contains plan data, it is not necessary to switch manually to the data load mode.

However, this model is more complex.

There are various options for filling the plan InfoCube with data.

Use Copy Function to Copy Actual Data to Plan InfoCube

You can use the standard Copy function type to copy data from the actual InfoCube into the plan InfoCube. In this case you require an additional MultiProvider. You define the aggregation levels on the basis of this MultiProvider.

The following graphic illustrates this model:

If you use a planning function to copy the data you can either start this function online from the plan query or include the copy function in a process chain in a planning sequence (see Planning Sequences).

With this type of model the system supports a characteristic relationship check.

Use Data Transfer Process to Load Plan Data

You can use a data transfer process to load data from the actual InfoCube into the plan InfoCube. In this case, you define the aggregation level either on the plan InfoCube or on the basis of a MultiProvider that contains the actual InfoCube and the plan InfoCube.

The following graphic illustrates this model:

Compared with using a planning function to copy data, a data transfer process has the following advantages: It is quicker and it supports delta handling. You can also include a DTP in a process chain.

A DTP allows you to use the transformation functions (see  Transformation).

With this type of model the system does not support a characteristic relationship check.

Complex Planning Integration The following example illustrates how you integrate planning-specific InfoProviders for a sales, production, and profit and loss planning into one complex planning application. Changes made manually to the Sales planning should automatically impact on the Production and Profit and Lossplanning. You achieve this by using planning functions.

The following graphic illustrates this model:

If manual changes are made to sales planning through the input-ready Sales query, these changes are also visible in the Cross query. The Cross query is defined on aggregation level Cross ALVL which also contains the sales InfoCube.

The customer has implemented planning function Simulate which specifies the relationship between the different key figures in the Sales, Production, and Profit and Loss InfoCubes. This function copies any changes to sales planning to the Production and Profit and Loss planning.

A prerequisite for a complex scenario of this type is that all the InfoCubes contain some common characteristics on which you can define an aggregation level. 

Overview of InfoProvider Modeling

InfoProvider

Characteristic Key Figure

InfoCube 1 CALYEAR, CALMONTH, VERSION, CUSTOMER, PRODUCTGROUP, PRODUCT

SALNET, AMOUNT

InfoCube 2 CALYEAR, CALMONTH, VERSION, PRODUCT

PRODAMOUNT, PRODCOSTS

InfoCube 3 CALYEAR, CALMONTH, VERSION NETCOSTS, NETREV

Cross ALVL CALYEAR, CALMONTH, VERSION, 0INFOPROV

SALNET, AMOUNT, PRODAMOUNT, PRODCOSTS, NETCOSTS, NETREV

Planning AutomationYou can integrate process chains in planning sequences. This allows you to schedule the execution of planning sequences together with data load processes. You can use BI information broadcasting to automatically send alerts or updated versions of the plan query.

The following graphic illustrates this model:

FeaturesInfoProvider Selection

You can restrict the number of InfoProviders displayed by specifying the technical name or description or by making an entry for last changed by.

You can change, check and save the selected InfoProviders.

InfoObjects

On the InfoObjects tab page, the system displays the InfoObjects that belong to the InfoProvider

(see  InfoObject). They are listed in the following tables:

●     Dimensions, with the characteristics assigned to them

●     Navigation Attributesfor the characteristics contained in the InfoProvider

●     Key figures

Under Settings, you can choose to display additional columns. 

Characteristic Relationships and Data Slices

In change mode you can define the permitted combinations of characteristic values in the form of characteristic relationships and create data slices for the data that you want to protect for real-time-enabled InfoCubes.

For more information, see Characteristic Relationships and Data Slices.

Default Key Date for Planning

On the Settings tab page in change mode, you can set a Key Date as the default key date for planning. If time-dependent objects, such as attributes or hierarchies, are used in objects of the planning model, you can always refer to the default key date for planning. In this way, you can ensure that a uniform key date is used in the planning model. The objects in the planning model that are relevant for this are characteristic relationships, data slices and parameters of planning functions.

For more information see Standard Key Date in Planning Functions.

 Characteristic Relationships 

UseYou use characteristic relationships to link characteristics that have similar content. You can use characteristic relationships to define rules to check permitted combinations of characteristic values for real-time InfoCubes. You can also define rules for the system to use to derive values from one characteristic for another characteristic. This is useful, for example, if you want the derivable characteristics to be available for further analysis.

You can define characteristic relationships for the master data of a characteristic (type attribute), a hierarchy (type hierarchy), a DataStore object (type DataStore) or an exit class (type exit).

IntegrationIf you define characteristic relationships for the attributes or hierarchies of characteristics, the system

proposes the attributes or hierarchies that you created in the BI system for a characteristic (see  Tab

Page: Attributes and  Tab Page: Hierarchy and  Hierarchy).

You create characteristic relationships for a real-time InfoCube.

 The system applies the characteristic relationships to all planning-relevant InfoProviders that reference the InfoCube.

Each input-ready query and planning function automatically takes the characteristic relationships into account:

●      In an input-ready query, this means that cells of invalid characteristic combinations are not input ready and new data records that have invalid characteristic combinations cannot be created.

●      Planning functions use the characteristic relationships to constantly check whether new characteristic combinations are valid. If there are invalid combinations, the system produces an error message.

Where possible, the system derives characteristics when it determines the delta records in the delta buffer. Possible source characteristics are characteristics in the real-time InfoCube that are filled by characteristics from the relevant aggregation levels. If characteristic relationships are changed, the data records in the InfoCube have to adapted to the new structure. You use the Reposting Characteristic Relationships planning function for this purpose.

PrerequisitesBefore you can define characteristic relationships, the following prerequisites must be met:

●      The InfoProvider must be a real-time InfoCube. The characteristic relationships defined for a real-time InfoCube are also valid in the MultiProviders that contain the real-time InfoCube. See InfoProvider.

●      In characteristic relationships of type attribute, the target characteristic must be defined as an attribute of the basic characteristic and must itself be contained in the InfoCube.

●      In characteristic relationships of type hierarchy, the target characteristic must be contained in a hierarchy and in the InfoCube. The hierarchy is mainly intended for modeling a derivation

relationship; thus the hierarchy cannot contain a leaf or an inner node more than once. Link nodes are also not permitted.

●      With characteristic relationships of type DataStore, only standard DataStore objects are permitted. You can use all the managing and monitoring methods that are available in the Data Warehousing Workbench.

FeaturesDefining Characteristic Relationships

You create characteristic relationships for real-time InfoCubes. A characteristic relationship comprises a set of steps that link characteristics and are numbered sequentially. Each of these relations links a set of characteristics. These relations represent the smallest units of a characteristic relationship.

Behavior of Combination Checks With and Without Derivation

You can only use relations to check characteristic combinations or derive characteristics. You specify this behavior when you define a relation. If the targets of one relation are the sources of another relation, you can link several relations of type Derivation. Redundancy should be avoided here so that the relations actually represent the smallest unit of the characteristic relationships.

At runtime, the system determines which relationships in the planning-relevant InfoProviders are used.

●      Combination check: A relation is only used in an aggregation level if each characteristic of the relation occurs in the aggregation level. With derivations, these are the source and target characteristics. In this case, no characteristics are derived; the system only performs a combination check.

●      Characteristic derivation: Derivation does not take place within one aggregation level. Derivation is only performed for the records of the real-time InfoCube. First the system determines the set S of characteristics that are filled by the relevant aggregation level. If all the source characteristics are included in set S, the system applies the derivation relations in the next step. The target characteristics of these derivations can then serve as sources in the steps that follow. Thus the system performs the maximum possible derivation in the InfoCube. If characteristic values that were already derived are changed again in subsequent steps, the derivation is incorrect. The system produces an error message.

Types of Characteristic Relationships

The following types of characteristic relationships exist:

Type More Information

Attribute You can select an attribute of the basic characteristic as the target characteristic (for example, the characteristiccurrency is an attribute of the characteristic controlling area).

The existing combinations of characteristics and attribute values are always permitted combinations.

Hierarchy Characteristics are available as source or target characteristics if you marked them as External Characteristics in Hierarchy in InfoObject maintenance. In addition to the hierarchy basic characteristic, the hierarchy must include at least one other characteristic.

Only one characteristic is permitted as a source and/or target characteristic (here the higher-level characteristics are not counted in compound characteristics).

The permitted combinations are taken from the hierarchy structure. A hierarchy can be used in multiple relations: in one step, you derive a characteristic that is on the next level up from the hierarchy basic characteristic; in the second step you take the derived characteristic and derive the characteristic on the next level.

Depending on the property of the hierarchy, the hierarchies that you use can be parameterized with the appropriate variables.

DataStore The data records located in the DataStore define the valid characteristic combinations and are used for characteristic derivation.

Only Combination Check: You can select all InfoObjects from the DataStore object (except for key figures).

With Derivation: You have to select the keys of the DataStore object as source characteristics.

Target characteristics can be InfoObjects from the data part of the DataStore object (except for key figures).

The keys for the DataStore objects can be restricted in any case; the restricted part is then used for the combination check or derivation. The restrictions can be parameterized with variables that must be replaceable without the dialog.

We recommend that you use only small DataStore objects (with few characteristics, few records).

Exit The valid characteristic combinations and derivable characteristic values are defined by the customer-specific implementation of the specified exit class.

The exit class must implement the interface 'IF_RSPLS_CR_EXIT'. Only these types of classes are offered for editing in maintenance. We recommend that you derive your own class from the example class 'CL_RSPLS_CR_EXIT_BASE'. You then only have to implement the methods ‘CHECK’, ‘DERIVE’ and ‘CREATE’. The class 'CL_RSPLS_CR_EXIT_BASE' itself can be used directly, but it does not execute an action.

Note also the example source code given in the template class; an infrastructure for buffering is provided there, for example.

As well as the characteristic relationships listed above which you can edit, characteristic relationships for BI time characteristicsare also active in the system (see Characteristic Relationships for Time Characteristics).

Within a relation, note that the initial characteristic value (# not assigned) plays a special role. Characteristics that do not occur in an aggregation level (and cannot be derived) are updated with the initial value.

■       Combination check without derivation:

There is a relation between the characteristics Product and Assortment; usually there is no derivation relationship between the two. In aggregation levels that contain Product but not Assortment, Assortment is updated with the initial value. These types of combinations are always valid; they cannot be forbidden. The same applies to combinations that have the initial value for Product.

■       Combination check with derivation:

There is a relation between the characteristics Cost Center and Profit Center; Profit Center can be derived from Cost Center. In an aggregation level that contains Profit Center but not Cost Center, Cost Center is updated with the initial value. Combinations of this sort cannot be forbidden. However, since Profit Center can be derived from Cost Center, the reverse situation produces an invalid combination.

Activities       1.      You are in the Planning Modeler on the InfoProvider  tab page. Choose the required

InfoProvider (type real-time InfoCube). In the lower screen area, the system displays the tab pages Characteristic Relationships, Data Slices and Settings.

       2.      To create or change characteristic relationships for the selected InfoProvider, choose Change.

       3.      You specify whether you want the system to perform combination checks and proposals only, or whether you also want the system to derive the target characteristic from the basic characteristic. For each step, choose with or without derivation.

       4.      Select the type of characteristic relationship.

       5.      Specify the basis of the relationship. This is different for each type of relationship:

○       Attribute: a master-data bearing characteristic

○       Hierarchy: the hierarchy basic characteristic

○       DataStore: a DataStore object

○       Exit: an exit class

       6.      The system shows further settings options depending on the relationship type selected. Depending on the type of step, you select the check characteristics or source and target characteristics.

○       If you are using attribute or hierarchy relationships or DataStore objects, you can select check characteristics.

○       If you are using an exit class, you can select source and target characteristics.

       7.      On the Characteristic Relationships tab page, the system automatically completes your entries. Before you select another InfoProvider or leave the tab page, save the defined characteristic relationship.

Characteristic Relationships for Time Characteristics The BI system contains various time characteristics. When you create a planning model, you have to select an appropriate time characteristic for the real-time InfoCube.  The choice of time characteristic depends on the planning application. You can use the Fiscal Year Period characteristic 0FISCPER (12.2005 + 1 = 1.2006) for rolling planning, for example. However, if you want to build query views that contain Periods in the rows and theFiscal Year in the data columns, it makes more sense to use the Periods and Fiscal Year time characteristics. You should avoid using redundant time characteristics in a real-time InfoCube. However in some cases, like the example given above, this may be useful.

If a real-time InfoCube contains redundant time characteristics, at runtime, the system uses the characteristic relationships that are required by the input-ready queries or planning functions for the corresponding time characteristics. These characteristic relationships have type “derivation”.

Note that the system only allows unique relationships. You can derive the calendar year (0CALYEAR) from time characteristic quarter (0CALQUARTER), but not the calendar week (0CALWEEK). 

If you want to model a relationship of this type, you require a customer-defined characteristic relationship of type exit that uses its own characteristics. These characteristics must reference the appropriate standard time characteristics.

The system uses the derived characteristic relationships for the time characteristics (as with the other relations) for derivation purposes and combinations checks.

Note that for each time characteristic there is a maximum valid time interval. This can be set in the system. If you are using a time characteristic, the maximum valid time interval has to cover the entire planning timeframe. 

On the General Settings tab page, you specify the value on the F4 Help and Hierarchies for Time Characteristics screen (transaction RSRHIERARCHYVIRT). Since this setting impacts on performance, you should keep the interval as small as possible.

You cannot create derivations that contain a time derivation that is used automatically in the system.

The following table offers an overview of the derivations that are automatically supported by the system:

Overview of characteristic relationships for time characteristics

Source Characteristics Target Characteristics

Comment

0CALDAY 0CALWEEK

0CALDAY 0CALMONTH

0CALDAY 0CALQUARTER

0CALDAY 0CALYEAR

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

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

0CALDAY 0WEEKDAY1

0CALDAY 0CALMONTH2

0CALDAY 0CALQUART1

0CALDAY 0HALFYEAR1

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

0CALMONTH 0CALQUARTER

0CALMONTH 0CALYEAR

0CALMONTH 0CALMONTH2

0CALMONTH 0CALQUART1

0CALMONTH 0HALFYEAR1

0CALQUARTER 0CALYEAR

0CALQUARTER 0CALQUART1

0CALQUARTER 0HALFYEAR1

0CALMONTH2 0CALQUART1

0CALMONTH2 0HALFYEAR1

0CALQUART1 0HALFYEAR1

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

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

0CALWEEK, 0WEEKDAY1 0CALDAY

0CALYEAR, 0CALQUART1 0CALQUARTER

0CALYEAR, 0CALMONTH2 0CALMONTH

0FISCYEAR, 0FISCVARNT, 0FISCPER3

0FISCPER Fiscal year variant required due to compounding

Data Slices 

UseData slices are a concept for protecting the main data of a real-time enabled InfoCube against changes. This protection affects input-ready queries and all planning functions that use this InfoCube.

If you want to ensure that certain plan versions can no longer be changed after a certain point in time, for example, and current data is not overwritten, you can use a data slice that contains these plan versions.

PrerequisitesData slices are created on a real-time enabled InfoCube. They then affect all InfoProviders from planning that include this InfoCube. See InfoProviders.

FeaturesThere are two types of data slice:

●     The data slice is based on a selection. Here you determine the restrictions for the characteristics that you wish to protect against changes.

●     The data slice is based on an exit class. In the exit class, you can implement a customer-specific logic to protect data records.

In general, the following rules apply to data slices:

●     If no data slice is defined for a real-time enabled data slice, any valid characteristic combination can be posted in this InfoCube (also seeCharacteristic Relationships.

●     Every data record that is part of the selection of a data slice is protected against changes. The associated cells in input-ready queries are notchangeable. This type of record cannot be changed and saved using planning functions.  The data slices cumulate in effect.

●     If a real-time enabled InfoProvider contains a data slice that includes no characteristic value restrictions at all, the data slice acts as a lock for postings of all types in the entire real-time enabled InfoProvider.

●     After you have created a data slice it is activated automatically. The settings made in the definition of the data slice have an immediate effect on the ability to update data. You can deactivate an existing data slice at any time (status inactive). Then this data slice is no longer taken into account.

Activities       1.      You are on the InfoProvider  tab page of the Planning Modeler. Choose the required

InfoProvider of type real-time enabled InfoCube. In the lower screen area, the system displays the tab pages Characteristic Relationships, Data Slices and Settings.

       2.      To change data slices, choose Change.

       3.      Change to the Data Slices tab page as needed.

       4.      To create a data slice, choose Create. The system marks the rows for the data slice that is to be created.

       5.      In the Data Slice Description enter a text for the data slice to be created.

       6.      Determine whether the data slice is based on a selection or on an exit class.

       7.      If the data slice is to be based on a selection, set the required characteristic values in the Change Characteristic Selections screen area.

○     Select the characteristic to be restricted.

○     Choose the symbol in the last column of the selected row. The dialog box for determining characteristic restriction appears.

○     Select one or more values from the value list. The selection can also contain variables as long as they do not send variables at runtime.

○     Choose Add and save the affected selection with OK.

       8.      If the data slice is to be based on an exit class, enter the name of the exit class.

○     Under Restricted, choose the characteristics that you need in the exit. You will only get the current values for these characteristics in the exit. If you are also interested in the initial values in the exit, set the indicator also #. This is the default setting. If this indicator is not set for a characteristic, the exit is not called for those aggregation levels that do not contain the characteristic, for example, because the affected characteristic value would be initial in this case.

○     The exit class must implement the interface 'IF_RSPLS_DS_EXIT'. Only these types of classes are offered for editing in maintenance. We recommend that the customer class inherit from the template class 'CL_RSPLS_DS_EXIT_BASE'. The template class itself is can be run directly, but it does not execute an action. Re-implement the method ‘IS_PROTECTED’. Also note the commented example source text in the template class; an infrastructure for buffering is provided there, for example.

       9.      If the data slice should not be active at first, set the associated indicator in the field inactive.

Aggregation Level 

UseAggregation levels are used as InfoProviders for planning: with an aggregation level, you model levels whose data can be changed manually using input-ready queries or automatically using planning functions.

An aggregation level is set using a set of characteristics and key figures from the underlying InfoProvider. The key figures included in the aggregation level are aggregated using the characteristics that are not included in the aggregation level.

In the simplest case, an aggregation level is located on a real-time enabled InfoCube. For more information on the functioning principle of aggregation and saving the changed data records for an aggregation level by means of a simple example, see Simple Aggregation Level.

Aggregation levels can also be created on MultiProviders.

IntegrationYou can create multiple aggregation levels for an InfoProvider. Use the Planning Modeler or the Planning Wizard for this.

In the Modeling functional area of the Data Warehousing Workbench, the system also displays the aggregation levels (symbol   ) and the underlying InfoProviders in the InfoProvider overview. When you double-click on the aggregation level, you can branch to the Planning Modeler and edit the selected aggregation level.

PrerequisitesIn the Planning Modeler or Planning Wizard you have selected (and if necessary edited) an InfoProvider to act as the basis of the aggregation level. This InfoProvider includes at least one real-time-enabled InfoCube. For more information about the corresponding processing step, see InfoProvider.

FeaturesSimple Aggregation Level

A real-time enabled InfoCube is the basis of a simple aggregation level. You can find a simple example under Simple Aggregation Level.

Complex Aggregation Level

A MultiProvider that includes at least one real-time enabled InfoCube, but no simple aggregation level, is the basis of a complex aggregation level.

You want to copy current data from an actual InfoCube to a plan InfoCube with a planning function of type Copy. To do this, you use an aggregation level based on a MultiProvider that includes the plan and actual InfoCubes.

Aggregation levels, like MultiProviders, cannot be nested.

With a complex aggregation level, note how data records from the InfoProviders included in the MultiProviders are embedded in the MultiProviders (and thus also the aggregation levels) and how the system writes changes to data records of the aggregation level back to the InfoProviders included in the MultiProviders. For more information on these MultiProvider-specific features - with simple examples - see Complex Aggregation Levels.

The following conditions apply to both types of aggregation level:

●     At least one key figure and one characteristic have to be included in the aggregation level.

●     The key figures used have to have the database aggregations SUM, MIN or MAX. With MIN or MAX, key figure values can only be displayed. They cannot be changed using manual planning or planning functions.

●     For key figures of type date or time, only the data type ‘DEC’ is supported.

●     Referencing key figures (and thus also non-cumulative key figures or elimination of internal business volume) are not supported in aggregation layers.

●     If a characteristic is compounded and used in an aggregation level, the aggregation level must also contain all compounding "parent" characteristics.

●     If a key figure is used in an aggregation level and does not have a fixed unit of measure or currency, the aggregation level must contain the associated characteristic for the unit.

●     If a key figure with exception aggregation is used in an aggregation level, the aggregation level must also contain the characteristic for exception aggregation if it occurs in the underlying InfoProvider.

●     The aggregation level inherits a navigation attribute from the underlying InfoProvider if it includes the basic characteristic of the navigation attribute. Note that the navigation attribute for an aggregation level is not visible in the Planning Modeler. It is only visible in the Query Designer.

●     An aggregation level cannot be created on MultiProviders if a characteristic of an InfoProvider contained in the MultiProvider supplies two different characteristics in the MultiProvider.

●     If a characteristic on the InfoProvider that serves as the basis for an aggregation level is constant, this characteristic has to be included in the aggregation level.

ActivitiesYou are in the Aggregation Levels tab page of the Planning Modeler. In the Aggregation Level Selection screen area, you can create, copy, delete, change, check, save and activate aggregation levels.

Creating Aggregation Levels

       1.      To create an aggregation level, choose Create. The Create Aggregation Level  dialog box appears.

       2.      Enter a technical name and a description.

       3.      Choose the appropriate InfoProvider. If you do not enter a search term and choose Start, the system shows all the InfoProviders available in your system.

       4.      Choose Transfer. In the lower screen area of the Planning Modeler, the system displays an overview of all InfoObjects of the InfoProvider.

       5.      Choose the InfoObjects that are to be included in the aggregation level. Note the conditions listed above.

       6.      To save the definition of the aggregation level, choose Save.

       7.      To check the definition of the aggregation level in view of consistency, choose Check.

When you choose Check, the system tries to complete necessary objects, such as superordinate characteristics from compounded characteristics.

       8.      If the definition is consistent, choose Activate. Once it has been activated, the aggregation level is ready for use.

Changing Aggregation Levels

       1.      To change an aggregation level, choose Change. In the lower screen area of the Planning Modeler, the system displays an overview of all InfoObjects of the InfoProvider used in the aggregation level. The InfoObjects selection list allows you to display all InfoObjects for the InfoProvider, only those used in the aggregation level, or those not used in the aggregation level.

       2.      Change the definition as required.

       3.      Save, check and activate the changed definition.

Simple Aggregation Level The following example demonstrates how the system works when a key figure value is changed (manually or automatically).

Assuming there is an InfoCube IC with the characteristics product, product group, version and year, along with the key figure revenue. The aggregation level ALVL includes the same objects with the exception of the characteristic, product.

Fact Table of the InfoCube IC

Product Product Group Version Year Revenue

P1 PG1 V1 2005 10

P2 PG1 V1 2005 20

P3 PG2 V1 2005 42

The key figure revenue includes the database aggregation SUM. Accordingly, we get the following result when the transaction data for the aggregation level ALVL is read from the database without restriction:

Aggregation Level ALVL (Key Figure Aggregated on the Database Level)

Product Group Version Year Revenue

PG1 V1 2005 30

PG2 V1 2005 42

If you have changed the revenue from 30 to 40 and is saved as a new value, the system writes a new record with the difference of the key figure value to the fact table of the InfoCube IC:

Delta Record in the Fact Table of the InfoCube IC

Product Product Group Version Year Revenue

# PG1 V1 2005 10

In this type of delta records, all characteristics of the InfoCube that are not included in the aggregation level get the initial value (not assigned: #). (Here we are assuming that no derivations were used. For more information on this concept, see Characteristic Relationships.)

 Complex Aggregation Level The following examples show:

        how the system embeds data records from the InfoProviders contained in a MultiProvider in the MultiProvider.

        how the system writes new or changed data records of the MultiProvider to those included in this InfoProvider

Example: Characteristic Product in MultiProvider MP

Assuming there is a MultiProvider MP, that includes the actual-InfoCube IC_A and the plan InfoCube IC_P. The actual InfoCube IC_A includes the characteristics product, product group, version and year, as well as the key figure profit. The plan InfoCube IC_P includes the same objects with the exception of the characteristic, product. An aggregation level ALVL_MP is defined on the MultiProvider MP, which includes all characteristics of the MultiProvider.

The following two data records for the underlying InfoProvider yields the following data records in the MultiProvider:

Data Record in Actual InfoCube IC_A

Product Product Group Version Year Profit

P1 PG1 V1 2005 10

Data Record in Plan InfoCube IC_P

Product Group Version Year Profit

PG1 V1 2005 30

Data Records in MultiProvider MP (or ALVL_MP)

InfoProviders Product Product Group Version Year Profit

IC_A P1 PG1 V1 2005 10

IC_P # PG1 V1 2005 30

The data records in the MultiProvider MP are - from a technical viewpoint - generated using a UNION operation from the records of the underlying InfoProvider. The InfoProvider is always included so that the "origin" of the respective data record is clear on the level of a data record.

If new data records are generated during manual planning or using the planning functions, the system ensure that every record of the MultiProvider can be assigned back to the InfoProviders contained in the MultiProvider uniquely and without loss of information.

The following table shows an example of a data record that could not be assigned.

Example of a Record in the MultiProvider MP that could not be assigned

InfoProviders Product Product Group Version Year Profit

IC_P P1 PG1 V1 2005 43

The data record is part of the InfoProvider IC_P. However, this InfoProvider does not provide a product in the MultiProvider. This means that P1 is not permitted.

In manual planning, data cells that could lead to this type of record are not input ready. In planning functions, the system ensure that these types of data records cannot be saved.

The same situation can occur for key figures in complex aggregation levels. If K is a key figure in MultiProvider MP that is supplied from the actual InfoCube IC_A, but not by the plan InfoCube IC_P, this key figure is always initial in a data record in the MultiProvider MP with the InfoProvider IC_P. This value also cannot be changed.

Filters 

UseA filter is an object that describes a multidimensional segment of data from a data set. Filters are used in reporting, analysis and planning, for example, to restrict data to a certain business area, certain product groups or certain time periods. You segment data in this way so that users or user groups only

have access to the data that is relevant to them or so that only certain data areas are available within an application scenario.

Within BI Integrated Planning, filters determine the selection of data upon which a planning function is executed. A planning sequence comprises a set of planning functions. A filter is assigned to each of these functions.

You want to revaluate the transaction data in your InfoProviders by a factor of 10%. However, you only want to perform the revaluation for certain groups of customers. To do this, you create a filter that contains the group of customers for which you want to revaluate data.

Filters can be reused in planning functions and in queries.

IntegrationYou can create multiple filters for an InfoProvider. You do this using the Planning Modeler or Planning Wizard or the Query Designer. In the Planning Modeler or Planning Wizard, you can only define filters on aggregation levels.

For more information about filters in the query, see the documentation on the Query Designer under Filter

PrerequisitesTo create a filter and use it in BI Integrated Planning, you need an aggregation level. For more information, see Aggregation Levels.

FeaturesYou choose the characteristics that you want to restrict from the characteristics of an aggregation level and add them to the filter.

A filter has the following components:

Filter Components

Element Description

Characteristic restrictions In the restriction dialog, you further restrict the characteristic using single values, value ranges, hierarchy nodes and variables. These characteristic restrictions determine the selection of data for a filter.

Default values Default values are only relevant in queries. They can be defined in the same way as characteristic restrictions. They define the initial filter status of the query upon execution.

To specify selections of data that are time dependent, for example if you want to determine a time-dependent hierarchy for time-dependent hierarchy node selections, you specify a Filter Key Date.

You use the delivered variable 0PLANDATA with characteristic 0CALDAY to synchronize key dates in queries, filters, characteristic relationships, data slices and planning functions. In this way you ensure that the same key date is used in these objects.

The function of a filter depends on whether you are using it in a planning function or in a query.

Filters in Planning Functions

In planning functions, a filter on the characteristic restrictions describes the data for which a planning function is executed.

Selections in the default values are not consulted when the planning function is executed.

You use a key date for the filter to determine time-dependent selections.

Filters in Queries

The values defined in the characteristic restrictions restrict the data that is available for further filtering at runtime of a query. You cannot apply a filter to a characteristic value that is not included in this value set.

The default values determine the initial filter status of the query.

The settings Changeable upon Execution and Only Single Value generally refer to the use of filters with a query.

Changeable upon Execution determines whether you can change the values selected in the characteristic restrictions when you execute the query. This setting is a prerequisite for the definition of default values for a characteristic.

If you select the Changeable upon Execution option, you can use the Only Single Value option to specify that you want to use a single value only for filtering the query.

For more information about filters in queries, see the documentation on the Query Designer under Filter.

ActivitiesYou are in the Planning Modeler on the Filter tab page. In the Filter Selection screen area, you can create, copy, delete, change, check, save and activate filters.

Creating Filters

       1.      To create a filter, choose Create.

       2.      In the Create Filter screen area, enter a technical name and a description for the filter that you want to create.

       3.      In the Aggregation Level Selection screen area, choose the required aggregation level. If you do not enter a search term and choose Start, the system shows all the aggregation levels available in your system.

Choose Transfer. In the lower screen area of the Planning Modeler, the system displays the Filter and Settings tab pages.

       4.      On the Filter tab page, choose the characteristics that you want to restrict.

You can adapt the display of the characteristics according to your requirements (display with key, text, key/text or text/key).

Add the characteristics that you want to restrict to the list. You can add individual characteristics to the list or all characteristics in the aggregation level (choose Add or Add All).

       5.      Select the characteristic that you want to restrict and choose the symbol for input help in the column after Characteristic Restrictions. The dialog box for determining characteristic restriction appears.

You can choose single values, value ranges and hierarchy nodes or variables as required. You can also transfer values from the history or from favorites.

You can choose one of the following views to select single values, value ranges and hierarchy nodes or variables:

●        All Values to display all characteristic values

●        Search  to search for a specific characteristic value or hierarchy node

●        Value Range to define value ranges (such as intervals)

●        Variables to select or create a variable

●        All Nodes to display and select hierarchy nodes

       6.      In the list of values, select one or more values, value ranges or hierarchy nodes and choose Insert and save the relevant selection by choosingOK. The system transfers the relevant settings to the list of restricted characteristics.

       7.      You can make further restrictions by choosing Show Enhanced Settings:

○       Changeable upon Execution (determines whether the characteristic restrictions can be changed at execution)

If you select the Changeable upon Execution option, you can make further settings:

○       Default Value Choose the symbol in the column after Default Value. The dialog box for determining the default value appears. Proceed as when restricting the characteristic values.

       8.      On the Settings tab page, you set the key date.

       9.      To save the definition of the filter, choose Save.

   10.      To check that the filter definition is consistent, choose Check.

Even when the check for a filter is not successful, you can save the filter in the Planning Modeler or Planning Wizard (like in the Query Designer). This allows you to save filters that have characteristic values that are not yet available and create these filters in the

system later. The system performs a consistency check when it executes the filter, before the filter is used.

Planning Functions  

UsePlanning functions are used in BI Integrated Planning for system-supported editing and generating data.

A planning function specifies how the transaction data for an aggregation level can be changed. This entails making a number of settings:

●      The name of the aggregation level

●      The type of planning function

●      How characteristics are used

●      The parameter values

The planning function type determines how data is changed by a planning function. The BI system offers you a number of standard planning function types:

●      Unit conversion

●      Generate combinations

●      Formula

●      Copy

●      Delete

●      Delete invalid combinations

●      Forecasting

●      Repost

●      Repost by characteristic relationships

●      Revaluation

●      Distribute by reference data

●      Distribute by key

●      Currency translation

You can also implement customer-specific planning function types. More information: Implementing Planning Function Types.

IntegrationIn Planning Modeler or the Planning Wizard, you create your planning functions (as well as the prerequisite objects for the planning model).

In Data Warehousing Workbench, the planning function objects are displayed in the Business Content and Transport Connection functional areas in the Planning folder.

PrerequisitesYou have created the following objects in Planning Modeler or the Planning Wizard:

●      Aggregation levels that planning functions are created on (see Aggregation Levels). Planning functions can be created and executed on eachactive aggregation level.

●      Filters that are required when the planning function is executed. Filters determine the data that the planning function is performed for. The planning function locks the data defined in the filter in the real-time InfoCubes belonging to the aggregation level. The filter has to be defined on the same aggregation level as the planning function.

FeaturesYou determine the planning function type and the aggregation level that you want the planning function to work on. You can also change the characteristic usage, the conditions and the parameter sets. You can define how the changed data will be processed.

The following section explains the functionality using an example of creating a planning function of type Repost.

The table below shows the data for the InfoProvider before the planning function is executed:

Before executing the planning function

Product Product Group Version Year Sales

P1 PG1 V1 2007 10

P2 PG1 V1 2007 20

You want to repost all records in version “V1” to version “V2”. You do this by reposting all key figures. The table below shows the status after the planning function has been executed:

After executing the planning function

Product Product Group Version Year Sales

P1 PG1 V1 2007 0

P2 PG1 V1 2007 0

P1 PG1 V2 2007 10

P2 PG1 V2 2007 20

After reposting, records that contain zeros only (empty records) remain in “V1”; while the required records appear in "V2".

Characteristic Usage

The planning function type defines the options for using characteristics and the parameters of the planning function. Together, the parameters of the planning function type define the parameter set.

With characteristic usage, the characteristics of the aggregation level are divided into Characteristics to Be Changed and Block Characteristics(characteristics that are not used). This allows you to specify the characteristic values that are changed when the planning function processes a data record. Block characteristics remain constant.

When you create a planning function of type Repost for the case described above, you first check which characteristic values should be changed and set the to be changed flag accordingly. Since you want to repost the data from version “V1“ to version “V2“, you set the flag for the Version characteristic as To Be Changed (which in this case means to be reposted).

You can also select block characteristics as condition characteristics.

Parameter Sets and Conditions

You can now change the parameter records. With most planning functions, all transaction data is processed with the same set of parameters. In this case, a block characteristic has not been selected as a condition characteristic, and only one parameter set has to be entered.

The parameter set for the planning function type Repost includes a table for selecting the key figures to be reposted and a table where you can enter the From-To Value Pairs for the characteristics to be reposted. In key figure selection, you set the flag for Select All Key Figures. In the From and To Values for Reposting table, you choose Create Row and enter the value “V1” under From and “V2” underTo. The planning function is ready for reposting.

If you want to use different parameter sets to execute different transaction data records, you have to work with conditions. You have to select at leastone block characteristic as a condition characteristic.

If you want to increase the planned production for products in product group PG1 by 5% and the products of product group PG2 by 10%, choose the product group as the condition characteristic.

In the parameters, you can create multiple pairs of conditions and parameter sets. For each pair, use a filter to select condition characteristics. You can change the associated parameter set for each pair.

From a technical viewpoint, the method that the planning function actually executes is called more than once. The data that was selected with the filter is divided into blocks. Each combination of characteristic values in the block characteristic forms a separate block (which explains the name block characteristics). Planning function types that work with reference data can also have additional blocks (such as Copy). The method is then

called once for each block with a table of records. The table includes data records that correspond to the characteristic combination for the block in the block characteristics.

For each block, the system checks for a condition/parameter set pair so that the block meets the condition. The system tests the block against the conditions along the sequence of pairs. The system uses the first pair where the block meets the condition. The method for the planning function type is executed for the block and the parameter set that meets the condition. Subsequent pairs are ignored. The method is therefore executed just once for each block.

Variables in Planning Functions

The usual BI variable types are available in many planning function types (see Variables).

Working with Empty Records

Almost all planning function types do not read empty records and do not write empty delta records to the buffer. Exceptions to this are Copy andGenerate Combinations. These two function types read empty records and write empty delta records.

Processing Changed Data

The planning function type setting defines whether the planning function processes the data in blocks or all data in one go. A planning function that processes data blocks can be set in such a way that it only processes blocks containing data that the user has changed in the current session. Planning functions of this kind only process very small amounts of data. This shortens the runtime considerably.

Here the user may have changed data in the filter or data that is used as reference data.

An example of this is the copy function that copies data from version V1 to V2. In this example, the data blocks are constructed so that all the data is grouped into blocks that have the same characteristic value in all characteristics (except in the version characteristic). The reference data originates from version V1. The data to be changed is in version V2. The function only processes the blocks in which data from version V1 or version V2 has been changed.

With a planning function, the filter defines the data that is allowed to be changed. You can tell from the parameters which reference data is required. Now the changed data is also read. The characteristic values of the block characteristics are collected for every changed data record in the filter and in the reference data. These values replace the original selection.

The changes made since the data was last saved are processed. The planning function identifies which data has already been processed. If this data is changed again, it is not processed again.

The system usually determines on the aggregation level of the planning function which data has been changed. It is also possible to specify a different aggregation level, for example the aggregation level of the query that was used to change the data.

The behavior can also be configured for a planning sequence.

We recommend that you use the setting, where only blocks with changed data are processed, in the following scenario:

At the start of the session, the user's data is in a consistent state. This is guaranteed by the administrator. During the session, the user changes some of the data. The user then executes planning functions that check whether the data is consistent or perform calculations that convert the data to a consistent state. Planning functions can be used where the data is not changed from the second execution onwards. The filter should be restricted so that it includes data that the user is allowed to edit during the session. The planning function should be able to edit all data. The way that the selection is made ensures that the system always processes the smallest possible quantity of blocks. However, it may be the case with the resulting intersections that a quantity larger than the minimum quantity is processed.

The filter of the planning function should not contain any variables that change during the session. Otherwise, the system might only process changed data with the previous variable assignment in the filter. Therefore there is a danger that not all of the changed data is recorded.

It is advisable to set this type of planning function for the Save pushbutton, as changes are only stored up to the previous save.

You can find out more about using this function for BEx Analyzer under Commands Wizard and for BEx Web Application Designer under Executing a Planning Function (Simple), Executing a Planning Function, Executing a Planning Sequence (Simple).

ActivitiesYou are on the Planning Functions tab page in Planning Modeler. Under Planning Function Selection, you can display, create, copy, delete, change, check, and save Planning Functions.

Creating Planning Functions

       1.      To create a planning function, choose Create. The Create Planning Function dialog box appears.

       2.      Choose the planning function type.

       3.      Enter a technical name and a description for the planning function.

       4.      Select the aggregation level where you want the planning function to work.

       5.      Choose For Characteristic Usage and determine which characteristics to change and (if required) to use in conditions.

       6.      Choose For Parameters. In the Conditions with Parameters screen area, you can create, delete and copy conditions. On the Selected Conditions tab pages, you can use input help to select the conditions values that you want the condition to apply to. On the Associated Parameter Set tab page, you maintain the parameter sets.

Check

During the check, you have to specify values for existing mandatory entry variables if values have not been selected for these variables in the current session. If this is the case, an entry screen appears.

Save

Planning functions can be saved even if they are not consistent.

Execute

Planning functions can be executed directly from a Web application or a BEx workbook. You have to enable this in the relevant design tool first though.

To execute a planning function in Planning Modeler, you have to include it in a planning sequence (see Planning Sequences).

In the Planning Wizard, you create a temporary planning sequence in the last step. This contains exactly one planning function.

Before the planning function is executed, the system checks whether the planning function is consistent.

ExampleProcess Flow of Planning Function: Distribution by Key 

Process Flow of Planning Function: Distribution by Key For year “2007“, version "V1", you want to distribute the planned quantity for each product to the available factories "W1" and "W2". The total quantity of each product stays the same. However, you want to distribute the total evenly between the factories.

The following table shows the data for the InfoProvider before the planning function is executed:

Before executing the planning function

Year Version Product Factory Quantity

2007 V1 P1 W1 10

2007 V1 P1 W2 20

2007 V1 P2 W1 60

2007 V1 P2 W2 40

The following table shows the result after the planning function has been executed:

After executing the planning function

Year Version Product Factory Quantity

2007 V1 P1 W1 15

2007 V1 P1 W2 15

2007 V1 P2 W1 50

2007 V1 P2 W2 50

The planning function actually only writes delta records to the InfoCube. The following table shows the delta records that were actually written:

Delta records in the InfoCube 

Year Version Product Factory Quantity

2007 V1 P1 W1 5

2007 V1 P1 W2 -5

2007 V1 P2 W1 -10

2007 V1 P2 W2 10

Creating the Planning Function

When you create the planning function, you first have to determine the characteristics for which values change. With regard to the characteristicsYear, Version and Product, the total of the values should not change; these characteristics remain constant and become block characteristics. The key figure values are to be distributed using the characteristic value Factory. Therefore, in characteristic usage, you have to select the Factorycharacteristic as to be changed.

The parameters for the distribution function are set as follows (see Distribution by Key).

●     Use the table for key figure selection to determine that the only key figure to be distributed is the Quantity key figure.

●     Since within a block (characteristic combination (year, version, product)) the overall total always has to be distributed each time, the Top Down Distribution distribution type is applied with the Distribute All setting.

●     The factories “W1” and “W2” are entered as To values and receive identical keys (such as 1).

Process Flow of the Planning Function

You want to execute the planning function with a filter that is restricted to year “2007” and version “V1”. The planning function executes the following steps:

       1.      First the system loads the filter and the planning function.

       2.      It replaces the variables.

       3.      It checks the filter and the planning function for consistency.

       4.      Using the filter, the system requests the selected data and loads it into the buffer. In this example, we assume that the records displayed above in the "before executing the planning function" table are selected by the filter and transferred to the planning function. Whether the system reads or ignores the existing empty records depends on the type of planning function (see Standard Planning Function Types). With the distribution function type, the system does not read empty records.

       5.      In accordance with the characteristic usage, the system divides the transaction data into blocks. The tables below the process flow illustrate this. Two blocks result. They are defined by the characteristic combinations shown here.

Block formation in accordance with characteristic usage

Block No. Year Version Product

1 2007 V1 P1

2 2007 V1 P2

       6.      For each block, the system uses the characteristic combinations to look for the correct parameter set from the condition/parameter set pairs. Since no conditions were created in this example, both blocks are executed with the only available parameter set.

       7.      The system runs the actual process (distribution, in this case), for each block. The tables after the process flow show the before-after values and the resulting delta records for each block.

       8.      Depending on the type of planning function, the system either processes any empty records that it finds or ignores them. In this example there are no empty records.

       9.      The system checks

○     Whether the resulting records are consistent with regard to master data and characteristic relationships.

○     Whether they are protected by data slices.

○     Whether they are located within the transferred filter.

Once the system has successfully processed all blocks, it writes the delta records it has collected back to the buffer. Derivation is performed in the buffer, as required (see Characteristic Relationships and Aggregation Levels).

If one of the generated records is inconsistent, the entire planning function writes nothing to the buffer.

Overview: Block 1

Block 1: { 2007, V1, P1} Before

Year Version Product Factory Quantity

2007 V1 P1 W1 10

2007 V1 P1 W2 20

Block 1: { 2007, V1, P1} After

Year Version Product Factory Quantity

2007 V1 P1 W1 15

2007 V1 P1 W2 15

Block 1: { 2007, V1, P1} Delta

Year Version Product Factory Quantity

2007 V1 P1 W1 5

2007 V1 P1 W2 -5

Overview: Block 2

Block 2: { 2007, V1, P2} Before

Year Version Product Factory Quantity

2007 V1 P2 W1 60

2007 V1 P2 W2 40

Block 2: { 2007, V1, P2} After

Year Version Product Factory Quantity

2007 V1 P2 W1 50

2007 V1 P2 W2 50

Block 2: { 2007, V1, P2} Delta

Year Version Product Factory Quantity

2007 V1 P2 W1 -10

2007 V1 P2 W2 10

Standard Planning Function Types 

DefinitionThe standard planning function types are part of the BI system. When you use a standard planning function type for a particular aggregation level, you define a planning function of this type.

UseThe following standard planning function types are delivered as part of the BI system.

Unit conversion

Generate combinations

Formula

Copy

Delete

Delete invalid combinations

Forecasting

Repost

Repost by characteristic relationship

Revaluation

Distribution by key

Distribution by reference data

Currency translation

Unit Conversion 

UseYou use the Unit Conversion function type to convert units of key figures into other key figures using unit relationships.

In the Source/Target Key Figure Conversion Type table, you can specify multiple conversions. For each conversion, you have to select the unit or quantity conversion type. The value in the target key figure is overwritten. This also applies when the source key figure is empty. The value of the source key figure is not changed during unit conversion. In this way the function can be executed more than once without the results changing. There is a special logic to ensure that this is the case when the source key figure and target figure are identical and the source unit of the data record is used: If there is already a value in the target unit, it is ignored if there are values in the source unit that do not have the target unit. Otherwise the value in the target unit is used.

With this function, only the unit fields can be characteristics to be changed.

Generate Combinations 

UseYou use the Generate Combinations function type to generate empty records for an aggregation level. The empty records are generated for all permitted combinations using the master data and characteristic combinations. These are exactly those combinations that are valid when the aggregation level is checked (see Characteristic Relationships).

This function type does not allow any additional settings. Since new data records are continuously generated for the whole aggregation level, all characteristics must have status to be changed. The function type works without block characteristics.

The function type writes empty records (like Copy).

Formula 

UseThe planning function type Formula provides you with a simple programming language for manipulating transaction data.

The same formulas are valid in BI Integrated Planning as were valid in BW-BPS. Note, however, that in BI Integrated Planning the name of the key figure is always part of the operand. For further information about formula calculation in BW-BPS, see the BW-BPS

documentation under  Formula.

FeaturesAs in many macro languages for business applications, the following components are available:

●      Operators and Functions

●      Variable concept including DATA statement for Data Declarations and help variables

●      Conditional Statements

●      Loop Constructs

●      Notification Output

●      Callable Function Modules

●      Comment function

You can use line notes, the starter mark (at the start of the line) is '*'.

Internal Data ObjectsA formula is not normally only executed once, but multiple times, that is, exactly once for each data object: If you execute a planning function, first select a filter, the filter describes the quantity of transaction data. The amount of transaction data is divided into smaller data objects. If a formula needs reference data, then these data objects are also formed directly from this reference data.

Note: If no data objects can be formed, a formula is not executed.

The only difference between the data objects is in the characteristic values of the characteristics to be changed. The values of the other characteristics are the same. If no characteristics to be changed are selected, the formula is executed once for each transaction data record. Each key figure value in the data object can be addressed uniquely by entering the characteristic values of the characteristic to be changed and the key figure name and can be changed using functions.

To better understand how to work with a formula, you can define a query in which all the characteristics to be changed are in the lead columns and the remaining characteristics are in the header. The formula is then processed for all combinations. You possibly have to extend the query by columns with reference data.

We recommend that you limit the values in the filter relating to the characteristics in the formula that are not to be changed as much as possible so that few data objects are created.

Reference DataYou have two possibilities for accessing reference data:

       1.      You make the field because of which the reference data of the data of the active planning filter differ as the field to be changed, for example,Version (0VERSION). You then write the operands as follows:

{ REVENUE, 002 } = { REVENUE, 001 }.

If there is no data available in version 002, then the internal data objects are made from the data from version 002 and also from 001. When executing the formula, data is created in version 002.

This syntax is intended for formulas that are to create new data from reference data.

       2.      You address reference data explicitly. To do so, you enter the name of the characteristic and the value in the operand.

{ REVENUE } = { REVENUE | 0VERSION = 001 }.The formula will only run for records in version 002 as it cannot be determined from the formula how the records from version 001 are to be transformed into records from version 002. If there are no records available, the formula is not run. No records are created.

The syntax is intended for formulas that need reference data to evaluate existing data.

In the following example the data from version 002 is in the active planning filter. The formula is run for each record of the active filter. As there are no fields to be changed, the data objects consist of one record.

Transaction Data is as Follows:

0VERSION 0COSTCENTER REVENUE

001 4711 3

001 0815 2

002 4711 9

Result of: { REVENUE, 002 } = { REVENUE, 001 }.

0VERSION 0COSTCENTER REVENUE

001 4711 3

001 0815 2

002 4711 3

001 0815 2

Two data objects were formed:

0COSTCENTER

4711

0815

Result of: { REVENUE } = { REVENUE | 0VERSION = 001 }.

0VERSION 0COSTCENTER REVENUE

001 4711 3

001 0815 2

002 4711 3

Available data objects:

0VERSION 0COSTCENTER

002 4711

Before executing the parameter group it is decided which reference data is required based on the formula. The original selection is enhanced for selecting reference data. We assume the planning filter contains only data from version 002: Based on the formula rows { REVENUE, 002 } = { REVENUE, 001 }. the selection is enhanced by the value version 001. Unfortunately it is not

always possible to decide which reference data is required before starting a planning function of the type Formula, the selection is then deleted once the results of the functions for addressing reference data are used. Cases where this can occur:

●      Using the TMVL function to change the value of a time characteristic

●      Using the ATRV or ATRVT functions to read attribute values

●      Calling function modules

DATA FISCPER TYPE 0FISCPER.

DATA ACTPER TYPE 0FISCPER.

ACTPER = VARV( CURPERIO ).

FISCPER = ACTPER.

FISCPER = TMVL( FISCPER , -12 ).

{ ERLOES, ACTPER } = { ERLOES, FISCPER }.

In the example, first the formula variable ACTPER is filled from the global variable ACTPERIO. In the second step this value is assigned to the FISCPER variable. In a third step, the value of ACTPER is reduced by 12 using the TMVL function. Finally, the value of the REVENUE key figure in the FISCPER period is assigned to the value of the REVENUE key figure in the ACTPER period.

Formula or Own Planning Function Types?Aside from using the function type Formula, you can also create your own planning function types to manipulate transaction data using a programming language. Weigh up the following points to decide for one function type or the other:

●      Planning functions of type Formula are easy to learn and do not require a high level of effort. Ideally an end-user in controlling who can already use an algorithmic programming language or a macro language and can solve the majority of problems with the formula language.

●      Own planning functions must therefore always be written when you require features that were not previously available. Example: For calculating costs, you must access customer-own tables. Until now there is no feature for accessing formulas in any table.

●      It is possible to call function modules in formulas. This means part of the logic can be is function modules and part in formula logic.

●      Generally, every own planning function type can be implemented to be more high-performance than the formula calculation. The main reason for this is that each operand and every result is read separately by more complex formulas from an internal table. These accesses would of course be optimized in a self-written program. This performance perspective is a major deciding factor for larger amounts of data.

ExpressionsYou can mention the following components in expressions:

●      Constants consist of numbers and a decimal point.

●      Variables you have declared with the DATA statement. (See also Data Declaration).

●      Operands you get using the input help.

○       If characteristic values appear in operands that are not addressed using the key figure name, operands have to be enclosed in curly brackets { and } so as to avoid operands being confused with constants. If no characteristic is to be changed, you can add the key figure name as an operand without parentheses. The system shows the valid syntax and, in particular, the correct order of characteristics above the editor. Using the input help you can easily combine valid operands.

○       If the characteristic values in operands contain blanks or symbols such as +, -, *, the characteristic values have to be enclosed in apostrophes.

○       There is an internal and external format for each characteristic value. For example, date values are shown externally as 3.12.1963 and internally as 19631203. Always use the internal format in formulas. You can also use variables instead of characteristic values in operands.

○       If key figure name is the only characteristic to be changed and you have defined a variable of type KEYFIGURE_NAME to be able to change key figures, then you also have to enclose this in braces. The following statement sets all key figures to the value 1. In this way, the FOREACH construct fills the variable KEYFIG with all the key figure names of the key figures available in the level.

DATA KEYFIG TYPE KEYFIGURE_NAME.

FOREACH KEYFIG.

{ KEYFIG } = 1.

ENDFOR.

●      Operators

●      Functions without, with one, or multiple operands

You can find a detailed list and explanation of the individual operators under Mathematical Operators and Functions.

More Information:

Examples for Formula Applications

Operators and Functions 

UseThere is a series of mathematical functions and operators available to you for calculating key figures.

FeaturesOperators

Mathematical Operator Meaning

+ or - Used as a sign (single-figure operators)

+ Addition

- Subtraction

* Multiplication

/ Division

DIV Whole number division

MOD Modulo operation

** Raise to a power

Relational Operator Meaning

> Greater than

< Lesser than

>= Greater than or equal to

<= Less than or equal to

= Equal to

<> Not equal to

Relational operators are used for Conditional Statements.

Logical Operator Meaning

AND And

OR Or

NOT Not

Functions

Functions can work either without, with one, or with multiple operands If no special operators are specified, you can also specify constants along side the valid operators.

All functions return a simple score, no time series. In the case of a depreciation it would be preferable to get a time series with the depreciations. To achieve this, you must complete a formula for each time period.

Functions with One Operand

Function Meaning

CEIL Smallest whole value that is not smaller than x

FLOOR Greatest whole value that is not greater than x

TRUNC Whole figure part of x

FRAC Decimal part of x

ABS Amount (fixed value) |x| of x

SIGN Sign of x

ACOS Arc cosinus (x) in area [-pi/2, pi/2], x from [-1, 1]

ASIN Arc sinus (x) in area [0, pi], x from [-1, 1]

ATAN Arc tangent (x) in area [-pi/2, pi/2] (pi =  3.1415926535897932)

COS Cosine of an angle specified in radian measure.

SIN Sinus of an angle specified in radian measure.

TAN Tan of an angle specified in radian measure.

COSH Hyperbolic cosine

SINH Hyperbolic sine

TANH Hyperbolic tan

EXP Exponential function for basis e = 2.7182818284590452

LOG Natural logarithm (that is, for basis e)

LOG10 Logarithm from x to basis 10, x > 0

SQRT Square root of a non-negative figure

STRLEN Length of a string

VARV Variable value (argument = variable name)

VARC Number of values of a variable (argument = variable names)

Functions with Two Operands

Function Meaning Operand1; Operand2

MAX Maximum

MIN Minimum

ATRV Read attribute Attribute type; Variable

TMVL Read time characteristic Value; Offset

PERP Perpetual bond Key figure; Interest rate

Unit for Interest Rate operand is percent (10% is represented as 10, no0.1)

C2DATE Determine date Time characteristic: 'S'tart/'E'nd value

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

CONCAT Concatenate operands <Operand1>; <Operand2>

VARI N-th variable value Variable, index

ROUND Rounding Key figure; Decimal places

The PERP function calculates th perpetual bond (from a capital fund) according to the following formula: Result = Key figure value * (Interest rate / 100)

Functions with Three Operands

Function Meaning Operand1; … ; Operand3

DISC Discounting

Formula for discounting an entry: Result = Key Figure Value / ((1 + Interest Rate / 100) ** Years)

Key figure; Interest rate; Years

DECD Declining-Balance Depreciation

This functions calculates according to the following

Start value; Percentage; Years;

algorithm:

       1.      "Execute [years]: Intermediate value = Intermediate value + (start value - intermediate value) * Percentage / 100"

       2.      Result = Start value - Intermediate value

ATRVT Read Time-dependent attribute Attribute type; Variable; Date

SUBSTR Read substring Variable; Offset; Length

REPLACE Replace character Source string; Pattern; Replacement

Functions with Four Operands

Function Meaning Operand1, … , Operand4

DECL Straight-line depreciation

Calculating a straight-line depreciation happens with the formula: Result = Start value - ((start value - net book value) * Percentage / 100 * Years).

Start value; Net book value; Percentage; Years;

Format for operand Percentage: 10% as 10, not0.1

Functions with Five Operands

Function Meaning Operand1, … , Operand5

CURC Currency conversion Amount; Date; Exchange rate; Source currency; Target currency

Nine decimal places are taken into account for the conversion. This means that small rounding differences can occur for floating point-type key figures.

Functions without an Operand

Function Meaning

OBJV Read characteristic value

Data Declaration 

UseA declaration is defined as a determination of aspects of a variable.

In FOX, all data declarations are initiated using DATA followed by the name of the help variable. The name must start with a letter and can contain both letters and numbers, but no special characters. Variable names must be different from key words such as DATA; ELSEIF, and SIN.

DATA HELPVAR TYPE I.

DATA KEYRA TYPE KEYFIGURE_NAME.

If the formula syntax is later enhanced by a new key word, then any pre-existing variables of the same name will become invalid.

To avoid errors, do not name variables like characteristic values and enclose characteristic values in quotation marks.

There are three variable types to choose from:

●      I (Integer Numbers) for index operations (predefined)

●      F (Floating Point Numbers) for calculations (predefined)

●      Variables of the same type as the characteristics to be changed.

The technical name of the characteristic is used here as the type name. If you have selected Key Figure Name, variables of typeKEYFIGURE_NAME can be defined. The valid data types can be displayed using Data Types.

In addition to this you can also create data types for attributes. If the attributes are of the type Key Figure, you have create help variables of types For I. If you want to read attribute values with the ATRV function, you need the technical name of the attribute.

Conditional Statements 

UseYou achieve conditional statements using an IF statement. Further conditional statements can follow an IF statement in an ELSEIF statement. The ELSE statement can be used for dealing with all other cases in a chain of conditional statements. The schema looks roughly as in the following example.

IF <Expression1>.

<Statement1>.

ELSEIF <Expression2>.

<Statement2>.

ELSE.

<Statement3>.

ENDIF.

Expressions in the IF statement consist of operands, plus variables and constants, relational operators and logical operators.

Note that constants may only come to the right of a comparison operator.

To check the special case of whether an operand <oper1> has the initial value, you can write:

IF <oper1> IS INITIAL. or IF <oper1> = '#'.

Example construction with logical operators: IF NOT <oper1> < <oper2> AND <oper3> = <oper4> OR <oper5> > <oper2>.

Working with Character-Type Operands

The following operators are available to you when working with character-type operands.

Working with Character-Type Operands for an Expression c1 <op> c2 Example

Operator Meaning in Expression

CP (Contains Pattern) The whole of string c1 matches the pattern c2.

Wildcards can also be contained in pattern c2 where '*' stands for a string and '+' for a symbol.

CO (Contains Only) c1 only contains characters from those in c2.

If c1 or c2 is of internal type C, then the complete length of the field is included in the comparison, that means blanks at the end are also taken into account.

If c1 is of type STRING and is empty then the output of the comparison is always positive.

If c2 is of type STRING and is empty, then the output of the comparison is always negative except when c1 is also an empty string.

CA (Contains Any) c1 only contains characters from those in c2.

If c1 or c2 is of internal type C then the complete length of the field is included in the comparison, that means blanks at the end are also taken into account.

If c1 or c2 is of type STRING and is empty then the output of the comparison is always negative.

CS (Contains String) c1 contains the string c2. If the respective field is of type C, then the final blanks in c1 and c2 are ignored.

An empty c2 string (therefore only blanks for type C or an empty string for type STRING) is contained in any c1 string and in the string itself. On the other hand there is no 'not-empty' c2 string contained in an empty c1 string.

 Loop Constructs 

UseDO Loop

●      Statements that are between DO and ENDDO can be repeated as often as required.

●      The loop is interrupted by the EXIT statement.

All values of a variable are iterated with the FOREACH <Variable>. statement. The characteristic values concerned are those available in the transaction data of the current data object (therefore not necessarily all the master data values that are defined for this characteristic). This loop construct is completed with the ENDFOR statement.{0>Die Zahl der Schleifendurchläufe kann

durch eine Konstante oder eine Variable vom Typ I gesteuert werden: <}77{>»The number of

loop passes can also be controlled by a constant or a variable of type I: DO <n> TIMES.

FOREACH Loop

●      All values of a variable are iterated with the FOREACH <Variable>. statement. The characteristic values concerned are those available in the transaction data of the current data object (therefore not necessarily all the master data values that are defined for this characteristic). This loop construct is completed with the ENDFOR statement.

●      The characteristic values are processed in ascending order. If you need combinations of characteristic values, you can implement the statement in the form FOREACH <Variable1, Variable2>.. This construct gets the available combinations of characteristic values of the current data object.

Notes on runtime behavior: Before entering the FOREACH loop, all the characteristic values available in the data object are collected and sorted, then these characteristic values in the FOREACH loop are delivered one after the other. Of a new value is created in the loop and written to the transaction data, this is only taken into account in the next FOREACH loop.

The FOREACH construct requires a lot of processing time and should be implemented as little as possible. Consider carefully whether you could use a construct of the type FOREACH <Variable1, Variable2>. instead of two nested loops as this would improve behavior at runtime.

●      Further variants of the FOREACH loop:

○       All the characteristic values that are available in the reference data are iterated with FOREACH <Variable> IN REFDATA.

○       All characteristic values of the active planning filter are iterated with FOREACH <Variable> IN SELECTION.

○       All characteristic values of a global Var variable are iterated with FOREACH <Variable> IN VARIABLE Var.

ExampleThe following example shows a bad program:DATA COUNTRY TYPE 0BPS_CNTRY.

DATA PRODUCT TYPE 0BPS_PRODU.

DATA FISCPER TYPE 0FISCPER.

FOREACH COUNTRY.

FOREACH PRODUCT.

FOREACH FISCPER.

{COUNTRY, PRODUCT, FISCPER} = {COUNTRY, PRODUCT, FISCPER} * 2.

ENDFOR.

ENDFOR.

ENDFOR.

The following example shows a better program: Here it is ensure that new values are only created when they are different from null. A lot of processing time is saved because the number of values that could appear in the PRODUCT and FISCPER variables does not need to be refreshed. Such a refresh occurs only when both of the loops FOREACH PRODUCT. and FOREACH FISCPER. are executed again. If null values are produced by a formula, the system does not write this to the internal buffer. These null values are therefore not visible to subsequent planning functions or manual planning. On the other hand, data not available is also assigned the value 0. Null values therefore do not need to be created explicitly.DATA COUNTRY TYPE 0BPS_CNTRY.

DATA PRODUCT TYPE 0BPS_PRODU.

DATA FISCPER TYPE 0FISCPER.

FOREACH COUNTRY.

FOREACH PRODUCT.

FOREACH FISCPER.

IF {COUNTRY, PRODUCT, FISCPER} <> 0.

{COUNTRY, PRODUCT, FISCPER} = {COUNTRY, PRODUCT, FISCPER} * 2.

ENDIF.

ENDFOR.

ENDFOR.

ENDFOR.

Finally, the following example shows the recommended way of programming:DATA COUNTRY TYPE 0BPS_CNTRY.

DATA PRODUCT TYPE 0BPS_PRODU.

DATA FISCPER TYPE 0FISCPER.

FOREACH COUNTRY, PRODUCT, FISCPER.

IF NOT {COUNTRY, PRODUCT, FISCPER} IS INITIAL.

{COUNTRY, PRODUCT, FISCPER} = {COUNTRY, PRODUCT, FISCPER} * 2.

ENDIF.

ENDFOR.

Notification Output 

UseYou can output notifications using the MESSAGE Tnnn(<Class>). or MESSAGE Tnnn(<Class>) WITH <Operand1> ... <Operand4>.statement.

●      T is the type of notification ('E' = Error, 'I' = Information). If an error of type 'E' was triggered, the results of the planning function are not copied to the internal transaction data buffer.

●      nnn is a three-figure number.

●      Class is a message class.

●      A maximum of 4 operands can also optionally be given. Operands can either be variables or strings enclosed in apostrophes.

The notifications are collected and displayed after the function has been executed.

We recommend that you create a message class of your own for error messages instead of using the notifications delivered by SAP. Note that you have to transport your own message class from the test system to the productive system.

  Function Modules 

UseYou can use the CALL FUNCTION statement to call function modules. To do so, enter the name of the function module in transaction SM30 in the table RSPLF_FDIR.

EXPORTING, IMPORTING, and CHANGING parameters can be transferred to the function modules. The parameters must be simple types (F, I, D, STRING, and characteristic and attribute types). Class references, structures, and table parameters are not permitted.

All compulsory IMPORTING parameters of a function module have to be supplied.

If the function module triggers an exception, you have to work with the MESSAGE ... RAISING construct. Class-based exceptions are also allowed. The notifications of the function module are copied to the log.

ExampleThe function module UPF_DISTR_RATE_GET is called in the following example.DATA FISCPER TYPE 0FISCPER.

DATA FISCYEAR TYPE 0FISCYEAR.

DATA RATE TYPE F.

DATA KYF TYPE KEYFIGURE_NAME.

FOREACH FISCYEAR, KYF.

FISCPER = OBJV( ).

CALL FUNCTION UPF_DISTR_RATE_GET

EXPORTING

I_FISCPER = FISCPER

I_VERSION = 'OPTIMISTIC'

IMPORTING

E_RATE = RATE.

{KYF,FISCYEAR} = { KYF, FISCYEAR } * RATE.

ENDFOR.

The following example shows how the use of the MESSAGE … RAISING statement when an exception is triggered.FUNCTION UPF_DISTR_RATE_GET.

*"--------------------------------------------------------------------

*"*"Local interface:

*" IMPORTING

*"     REFERENCE(I_FISCPER) TYPE  /BI0/OIFISCPER

*"     REFERENCE(I_VERSION) TYPE  STRING DEFAULT 'OPTIMISTIC'

*" EXPORTING

*"     REFERENCE(E_RATE) TYPE  F

*"     REFERENCE(E_FISCYEAR) TYPE  /BI0/OIFISCYEAR

*" EXCEPTIONS

*"     ERROR

*"--------------------------------------------------------------------

DATA: L_FISCPER_3 TYPE N LENGTH 3.

L_FISCPER_3 = I_FISCPER+4(3).

IF I_VERSION = 'OPTIMISTIC'.

E_RATE = l_FISCPER_3 / 5.

ELSE.

E_RATE = l_FISCPER_3 / 7.

ENDIF.

E_FISCYEAR = I_FISCPER(4).

IF L_FISCPER_3 IS INITIAL OR E_FISCYEAR IS INITIAL.

MESSAGE E001(UPF) WITH 'Initial Values'(TIV) RAISING ERROR.

ENDIF.

ENDFUNCTION.

 Examples for Formula Applications        1.      Price planning

       2.      Price Planning with Prices in the Master Data

       3.      Proportional Planning

       4.      Copying with Condition on the Value of a Key Figure

       5.      Copying with Condition and Iteration over Key Figure Name

       6.      Plausibility Check of Data

       7.      Rolling Planning

       8.      Depreciation

       9.      Calculating with Data Type 'D'

   10.      Working with Character Strings

1. Price PlanningIn version 1 it is planned, in version 2 the prices are stored in the transaction data. The characteristics to be changed are:

●      Version (0VERSION)

●      Fiscal Year (0FYEAR)

●      Customer (0CUSTOMER)

The records have the special feature that the characteristics Customerand Fiscal Year have the value Not Assigned and must therefore be included in the group of characteristics to be changed. For every object to be planned in version 1, there must also be an object in version 2 from which the price can be determined. If no price is planned for an article, a notification is issued. The calculation is only executed when the combination {QUANTITY,1,FYEAR,CUSTOMER} is scheduled, therefore > 0.DATA CUSTOMER TYPE 0CUSTOMER.

DATA FYEAR    TYPE 0FYEAR.

DATA ARTICLE TYPE 0ARTICLE.

IF {PRICE,2,#,#} = 0.

ARTICLE = OBJV().

MESSAGE I001(/SEM/003) WITH ARTICLE.

ELSE.

FOREACH FYEAR, CUSTOMER.

IF {QUANTITY,1,FYEAR,CUSTOMER} > 0.

{REVENUE,1,FYEAR,CUSTOMER} = {QUANTITY,1,FYEAR,CUSTOMER} * {PRICE,2,#,#}.

ENDIF.

ENDFOR.

ENDIF.

It seems surprising that the Article (0ARTICLE) is missing from the list of characteristics to be changed as the prices that are used for calculating refer to the 0ARTICLE. If specifically including the 0ARTICLE characteristic, the example would look as follows:DATA CUSTOMER TYPE 0CUSTOMER.

DATA FYEAR    TYPE 0FYEAR.

DATA ARTICLE TYPE 0ARTICLE.

FOREACH ARTICLE, FYEAR, CUSTOMER.

IF {PRICE,2,#,#,ARTICLE} = 0.

MESSAGE I001(/SEM/003) WITH ARTICLE.

ELSE.

IF {QUANTITY,1,FYEAR,CUSTOMER,ARTICLE} > 0.

{REVENUE,1,FYEAR,CUSTOMER,ARTICLE} = {QUANTITY,1,FYEAR,CUSTOMER,ARTICLE} * {PRICE,2,#,#,ARTICLE}.

ENDIF.

ENDIF.

ENDFOR.

The 0ARTICLE characteristic is not actually necessary for the formula as the values of the characteristic are not changed. When calculating the planned revenue it is shown that the same article is referenced on both sides of the assignment operator.

In a case such as this, SAP recommends that you do not include the characteristic in the quantity of characteristics to be changed as it is not required for the calculation, but costs in performance when accessing the values. Another way of accelerating the formula is to save the value of the {PRICE,2,#,#} element in a help variable and then to work with this. If the value of a characteristic is needed to output an error message or to determine attribute values, the value can be read with the OBJV() function.

The formula can be made even shorter if the reference data is accessed explicitly. Apart from the key figure name there are no characteristics to be changed. The formula is executed for each data record. A FOREACH loop through characteristics to be changed is therefore not required.DATA ARTICLE TYPE 0ARTICLE.

IF {PRICE | 0VERSION = 2,0FYEAR = #,0CUSTOMER = #} = 0.

ARTICLE = OBJV().

MESSAGE I001(/SEM/003) WITH ARTICLE.

ELSE.

REVENUE = QUANTITY * { PRICE | 0VERSION = 2,0FYEAR = #,0CUSTOMER = #}.

ENDIF.

2. Price Planning with Prices in the Master DataWhat does price planning look like when the price is stored in the master data? We access the value of the article using the OBJV function. The value of the OPRICEattribute is read using the ATRV function. In a simple case the ATRVfunction has two arguments. The first argument must be the name of a master data attribute and the second a variable. The value of the attribute is read from the master data table using the variable value. Compound characteristics differ in the following ways:

●      If the parent characteristics are for fields to be changed, the values of these function characteristics must be specified in the form of variables. The number of arguments of the function is determined in this case by how many fields have to be specified.

●      If the parent characteristics are not included in the quantity of fields to be changes, the values are automatically removed from the values of the current package. The following example shows only the key figure name of a characteristic to be changed.DATA ARTICLE TYPE 0ARTICLE.

ARTICLE = OBJV().

REVENUE = ATRV( '0PRICE', ARTICLE ) * QUANTITY.

3. Proportional PlanningCharacteristics to be changed are key figure name, version (0VERSION), fiscal

year (0FYEAR), and customer (0CUSTOMER).DATA TOTREVENUE TYPE F.

DATA TOTQUANTITY TYPE F.

DATA CUSTOMER TYPE 0CUSTOMER.

FOREACH CUSTOMER.

TOTREVENUE = TOTREVENUE + {REVENUE,2,CUSTOMER}.

TOTQUANTITY = TOTQUANTITY + {QUANTITY,2,CUSTOMER}.

ENDFOR.

FOREACH CUSTOMER.

{REVENUE,1,CUSTOMER} = {QUANTITY,1,CUSTOMER} * TOTREVENUE / TOTQUANTITY.

ENDFOR.

4. Copying with Condition on the Value of a Key FigureThe characteristic to be changed is Version. The key figure name is selected as the characteristic for conditions. REVENUE was selected as the value for the key figure name. The following formula copies the revenue from version 1 to version 2 if the revenue in version 1 is greater than 500. We cannot implement the planning function of type Copy in this example as it is not possible to formulate conditions for key figure values here. It is generally an advantage to use the special planning functions rather than formulas as these are implemented more efficiently.IF {1} > 500.

{2} = {1}.

ENDIF.

5. Copying with Condition and Iteration over Key Figure NameCharacteristics to be changed are key figure name and version. In contrast to the example above, all key figures are now copied to version 2 if the revenue is greater than 500. To avoid having to assign all key figures, we define a RATIO variable of type KEYFIGURE_NAME and iterate across all key figures of the planning level using the FOREACH construct.DATA RATIO TYPE KEYFIGURE_NAME.

IF { REVENUE, 1 } > 500.

FOREACH RATIO.

{ RATIO, 2 } = { RATIO, 1 }.

ENDFOR.

ENDIF.

6. Plausibility Check of DataCharacteristics to be changed are key figure name, version, and article. We check whether the planned revenue has reached at least 90 percent of the revenue of version 1. If the boundary is exceeded, the system gives a warning message.DATA ARTICLE TYPE 0ARTICLE.

DATA MINREVENUE TYPE F.

FOREACH ARTICLE.

MINREVENUE = { REVENUE, 1, ARTICLE } * 0.9.

IF { REVENUE, 2, ARTICLE } < MINREVENUE.

* The planned revenue for article &1 exceeds the predefined minimum revenue

MESSAGE I034(ZSEM) WITH ARTICLE.

ENDIF.

ENDFOR.

7. Rolling PlanningCharacteristics to be changed are version and fiscal year/period. The actual data of the current period is copied to the plan version. The difference is spread across the remaining periods. The current period is determined from a variable.DATA ACTPER TYPE FISCPER.

DATA FISCPER TYPE FISCPER.

DATA SUM TYPE F.

DATA DELTA TYPE F.

* Periods read from the variables with the technical name PERIOD

ACTPER = VARV( 'PERIOD' ).

* Get sum for weight

FOREACH FISCPER.

IF FISCPER > ACTPER.

SUM = SUM + { 1, FISCPER }.

ENDIF.

ENDFOR.

* Delta between planned value and actual value

DELTA = {1, ACTPER} - {0,ACTPER}.

* Set planned value to actual value

{1,ACTPER} = {0, ACTPER}.

* Weighted delta distribution

FOREACH FISCPER.

IF FISCPER > ACTPER.

{1,FISCPER} = {1,FISCPER} + DELTA * {1,FISCPER} / SUM.

ENDIF.

ENDFOR.

8. DepreciationCharacteristics to be changed are key figure name and fiscal year. Determines the value of the 0AMOUNT key figure for five years. Cost price is 1000. Net book value is 100. Depreciation percentage rate is 20 percent. It is straight-line depreciation. In this example the DECL (straight-line depreciation) function is not of importance, but the TMVL function. This function has the value of a time characteristic as its first argument and an offset as its second. The offset specifies which next-largest value the function should deliver. You can also transfer negative offsets. Then the corresponding smaller values are delivered. It is not possible to set the same effect with a FOREACH loop because not all years have to be included in the transaction data.DATA YEARS TYPE I.

DATA FYEAR TYPE 0FISCYEAR.

FYEAR = VARV('ACTYEAR').

DO.

YEARS = YEARS + 1.

FYEAR = TMVL(FYEAR, 1).

{0AMOUNT, FYEAR} =  DECL( 1000, 100, 20, YEARS).

IF YEARS = 5.

EXIT.

ENDIF.

ENDDO.

9. Calculating with Data Type 'D'It is also possible to execute calculations using data type 'D'. A small example is shown below. In the FOREACH loop, the date of the first day is specified in D1 in FISPCER and the last day in D2 in FISCPER. In addition to this, the difference between D2 and D1 is shown in I1 and two days are subtracted. I1 is of type I. If the date format in D1 and D2 is invalid, the result 0 is returned. When calculating with fields of type D, the constant operands are also checked for valid date formats. Therefore we could not write I1 = D2 - D1 - 2. but have to use a help variable I2.DATA D1 TYPE D.

DATA D2 TYPE D.

DATA I1 TYPE I.

DATA I2 TYPE I.

DATA FISCPER TYPE 0FISCPER.

FOREACH FISCPER.

* Calculate 1st day of FISCPER

D1 = C2DATE( FISCPER, S ).

* Calculate last day of FISCPER

D2 = C2DATE( FISCPER, E ).

* Calculate the difference between last and 1st day minus two days

I2 = 2.

I1 = D2 - D1 - I2.

MESSAGE I001(UPF) WITH 'DIFFERENCE' I1.

ENDFOR.

10. Working with Character StringsIn the following example it is checked if the characteristics fiscal year/period (0FISCPER), fiscal year (0FISCYEAR) and three-figure posting period (0FISCPER3) are completed consistently. Fiscal year/period is seven characters long, the first four represent the fiscal year and the characters five to seven represent the posting period. Using the SUBSTR function(characteristic, offset, length)the corresponding values are read from the value fiscal year/period. If the characteristic value of Fiscal year/period is initial, it is filled with the concatenated value of fiscal year and posting period. The CONCAT function is used for this.DATA FISCPER TYPE 0FISCPER.

DATA FISCPER_CMP TYPE 0FISCPER.

DATA YEAR TYPE 0FISCYEAR.

DATA PER TYPE 0FISCPER3.

DATA PER_CMP TYPE 0FISCPER3.

DATA YEAR_CMP TYPE 0FISCYEAR.

DATA KYFNM TYPE KEYFIGURE_NAME.

YEAR = OBJV( ).

PER = OBJV( ).

FISCPER_CMP = CONCAT( YEAR, PER3 ).

FOREACH KYFNM, FISCPER.

IF FISCPER IS INITIAL.

{KYFNM,FISCPER_CMP} = {KYFNM,FISCPER}.

ELSE.

PER_CMP = SUBSTR( FISCPER, 4, 3 ).

YEAR_CMP = SUBSTR( FISCPER, 0, 4 ).

IF YEAR <> YEAR_CMP OR PER <> PER_CMP.

* Error message

MESSAGE E021(/SEM/003) WITH YEAR YEAR_CMP PER PER_CMP.

ENDIF.

ENDIF.

ENDFOR.

Copy 

UseYou use the Copy function type to copy the key figure values from existing characteristic combinations to other characteristic combinations.

For example, if you want to copy the values from year 2005 to 2007 without changing another characteristic, set the Will Be Changedindicator for characteristic Year only.

You use the table for key figure selection to specify the key figures that are to be copied.

In the From and To Values for Copying table, you can either create a simple copying process or multiple copying processes within a planning function.

The function type allows complicated copying processes as well; both the From and To values can be characteristic restrictions on the characteristics that are to be changed. The system continually totals the values of the From key figures using all the records in the block that correspond to the characteristic restriction; it continually writes the To totals for each individual characteristic combination.

You can also copy values from one From value to multipleTo values.

You copy data from the year “2005“ in version “ACTUAL” to the combinations {“2006“, “PLAN01“} and {2007, „PLAN02“}.

The function type reads and writes empty records.

The following rules apply:

●     The From values are read as reference data and do not need to be part of the filter that is transferred to the planning function.

●     The To values are changed; they have to be included in the transferred filter.

●     The key figure values for the To values are always overwritten during copying. This is also valid when the From values are empty.

●     If there are no values to form a block for a characteristic restriction on the From side, the subprocess is not executed.

●     Combinations are generated on the To side for the specified characteristic restrictions. This is consistent with the master data and the characteristic relationships defined for the InfoProviders. If the system cannot find a target for a block and a subprocess, the system terminates the function and produces an error message.

●     If a target has been specified in one or more subprocesses, the function is executed and as a result, the target contains the appropriate totals.

The copying function also forms blocks of reference data.

Delete 

UseYou use the Delete function type to delete the key figure values for the selected data records.

No characteristic values are changed. In characteristic value usage, you can only select characteristics as condition characteristics.

You select the key figures that are to be deleted in a table.

 Deleting Invalid Combinations 

UseYou use the Delete Invalid Combinations function type to delete all key figure values for all records whose combination of characteristic values does not correspond to the characteristic combinations that are defined for the underlying real-time InfoCube.

Note the following condition: A planning function of this type can only be created on an aggregation level that itself has been created directly on a real-time InfoCube (a simple

aggregation level, see Aggregation Level). The aggregation level has to include all the InfoObjects of the InfoCube that are valid in aggregation levels.

Since normal use of an InfoCube does not allow you to completely delete combinations of characteristics (records), the planning function only resets all the key figures to zero. To fully remove combinations of characteristics from the InfoCube, you must compress the InfoCube in the InfoCube management (transaction code RSA1). The indicator With Zero Elimination must be selected.

Forecasting 

UseYou can use a forecast procedure to predict the future development of key figure values. The default planning function type Forecasting in BI Integrated Planning offers a number of strategies and statistical methods for calculating forecasting future values on the basis of historical data.

IntegrationThe strategies and methods of this planning function type are based on the same statistical methods used in demand planning.

For more information about forecasting in demand planning, see http://help.sap.com → SAP Business Suite → SAP Supply Chain Management → SAP APO 3.1 → Application Help → Demand Planning → Demand Planning Process → Definition/Redefinition of Forecast Models → Creating a Forecast Profile → Univariate Forecasting

Prerequisites●      Historic data is available for the forecast calculation.

●      The aggregation levels where you are creating a forecast planning function have to contain at least one time characteristic (for example, Fiscal Year/Periods). The forecast only works with one time characteristic. Only values for this characteristic can be changed. The other characteristics, especially redundant time characteristics, are not adapted by the forecast function. Time characteristics always need to assume consistent values to one another, however. Value 2005 for time characteristic Calendar Year (0CALYEAR) therefore matches the values 01.2005 to 12.2005 for characteristic Calendar Year/Month (0CALMONTH). If you want to forecast values beyond a single year, however, the calendar year must assume different values in the records to be forecast. The planning function does not do this. It is done by the derivation instead, which automatically fills the redundant time characteristics.

Note that you cannot add any redundant time characteristics such as Calendar Year/Month (InfoObject 0CALMONTH) and Calendar Year (InfoObject 0CALYEAR) or Fiscal Year/Period (InfoObject 0FISCPER) and Fiscal Year (InfoObject 0FISCYEAR) to the aggregation level,. Only add time characteristics with the finest level of granularity to the aggregation level.

In the examples specified, you should therefore use 0CALMONTH or 0FISCPER. The values for the “parent” time characteristic 0CALYEAR or 0FISCYEAR can then be derived automatically.

FeaturesPlanning function type  Forecast covers various univariate forecast procedures. In a forecast procedure, only the time series of the selected forecast key figure is taken into account. No further information is entered in the forecast calculation to interpret the development of the key figure.

Time Series Patterns

You can create forecasts for the following time series patterns:

Constant

The historic data is essentially constant and varies very little from a stable mean value. In the graphic below, this base value is represented by a red line:

Trend

The time series rises or falls continuously. In the graphic below, this trend is represented by a red line:

Seasonal

The values show periodically recurring peaks and troughs (on an annual basis). There is a stable mean value. In the graphic below, this base value is represented by a red line:

Seasonal Trend

This time series is a combination of the trend and seasonal patterns. The seasonal variation increases for an upward trend.

Intermittent

The value is zero at most points in the time series. The values that are not zero fluctuate around a mean value.

Forecast Strategies

The forecast strategy determines which forecast procedure is used. To choose a suitable forecast strategy, base your decision on the time series pattern. The various forecast procedures are based on the different forecast models (time series models). They therefore produce different results.

The following forecast strategies are available:

●      Average

●      Moving average

●      Weighted moving average

●      Linear regression

●      Seasonal linear regression

●      Simple exponential smoothing (constant model)

●      Simple exponential smoothing with alpha optimization (constant model)

●      Linear exponential smoothing (trend model)

●      Seasonal exponential smoothing (seasonal model)

●      Seasonal trend exponential smoothing (seasonal trend model)

●      Croston model

●      Automatic model selection

The automatic model selection forecast strategy allows you to let the system select the forecast model that best fits the time series of the historic data (see Automatic Model Selection).

If you already know that a particular forecast model is well suited to the time series pattern, or if you explicitly want to use a particular forecast model for other reasons, you can select a particular forecast model (see Forecast Strategies).

Additional Functions for Forecast Strategies

The forecast strategies offer the following additional functions and options:

●      Outlier Correction

●      Logging Statistical Key Figures

●      Ignoring Initial Zero Values

For exponential smoothing:

●      Optimization of smoothing factors for exponential smoothing

For forecast models with trend components:

●      Trend Damping

Gaps in the Forecast or in the Historic Time Frame

Gaps can occur in both the forecast and the historic time frame. Unlike forecasts in BW-BPS, these gaps are not ignored. This means that the selected times will have gaps when placed in a row. Gaps in the forecasting period are handled so that the values of this period are not changed.  Gaps in the historic time frame are included in the forecast calculation with value 0.

Note that the times before the first forecast time belong in the past.

You want to generate forecast data for the months 1-3 and 5-7 (month 4 is handled separately). The system calculates forecast values for all months 1-7, but does not change month 4. In the BW-BPS forecast, however, only 6 forecast values are calculated

and are assigned to the months 1-3 and 5-7 one after the other. For a linear trend in the forecast result with values 1010, 1020, etc., this implies the following difference between BI Integrated Planning and BW-BPS:

Handling of Gaps in BI Integrated Planning and BW-BPS

Month BI Integrated Planning BW-BPS

1 1010 1010

2 1020 1020

3 1030 1030

5 1050 1040

6 1060 1050

7 1070 1060

ActivitiesTo create a planning function of type Forecast, you have to perform the following steps:

       1.      Select the Time Characteristic for the Forecast.

Choose For Characteristic Usage. You choose the time characteristic that represents the time dimension of the forecast.

Note that there is a maximum valid time interval for each time characteristic. This can be set in the system. If you are using a time characteristic, the maximum valid time interval has to cover the entire planning timeframe.

On the General Settings tab page, you specify the value on the F4 Help and Hierarchies for Time Characteristicsscreen (transaction RSRHIERARCHYVIRT). Since this setting impacts on performance, you should keep the interval as small as possible.

You cannot include the selected time characteristic in the set of characteristics for conditions. For more information about using characteristics and condition characteristics, see Planning Functions.

       2.      Specify the forecast data.

Choose For Parameters and perform the following steps:

1.                             a.      Select the Forecast Key Figures

Specify the key figures that you want to calculate the forecast for.

2.                             b.      Specify the Forecast Time Frame

Specify the time frame for the forecast by restricting the time characteristic for the forecast. This is usually a time interval that represents the length of time for the required forecast.If the time characteristic for the forecast is Fiscal Year/Periods (0FISCPER), the system proposes the higher-level characteristic Fiscal Year Variant. You only have to restrict this characteristic if you are using variables with processing type Customer and SAP Exitin the restrictions for Fiscal Year/Periods(for example, Current Periods).The system ignores exceptional periods of the time characteristic Fiscal Year/Periods (0FISCPER) when it performs the calculations; values for periods of this type are not generated or changed.

       3.      Enter the historic data.

You specify the Historic Time Frame in the same way as the forecast time frame. The longer the time frame, the better the quality of the forecast results.

You use the Filter for Historic Data if your historic data differs from the forecast data for particular characteristics. You have to specify a single value for each of these characteristics.

This may be the case, for example, with the Version characteristic if the forecast data is in a plan version and the historic data is based on an actual version.

       4.      Select the forecast method and define more parameters.

Choose the required value for the Forecast Strategy parameter. Depending on the selected forecast strategy, the system proposes additional parameters. In certain cases, entering a value for individual parameters is mandatory.

The system proposes Automatic Model Selection as the default forecast strategy and offers the largest number of parameters after comparison with other forecast strategies. The greater the number of parameters, the more time-consuming the forecast calculation will be.

       5.      Save the planning function.

Forecast Strategies 

UseThe forecast strategy determines how forecast values are calculated.

All forecast strategies are based on statistical forecast procedures and forecast models that represent the time series mathematically.

The exponential smoothing methods are currently the most widely used time series patterns (see Exponential Smoothing).

If you expect historic values to continue to develop as they have in the past, choose a forecast model that fits the time series pattern.

The Automatic Model Selection strategy allows you to let the system select the forecast model that best fits the trend of historic data (see Automatic Model Selection).

FeaturesThe following forecast strategies are available:

Average

The forecast value is calculated from the arithmetic mean of the historic values.

●      Optional forecast parameters: outlier correction, logging statistical key figures, ignoring initial zero values.

Moving Average

The forecast value is calculated according to the order.

●      Obligatory forecast parameter: Order of MovingAverage

The order of the moving average is a number N that determines the length of the time interval for calculating the average. This is the number of chronologically sequential historic values. The forecast value is calculated as the average of the last N historic values.

Do not enter a negative number for the order.

●      Optional forecast parameters: outlier correction, logging statistical key figures, ignoring initial zero values.

Weighted Moving Average

When the system calculates the moving average, each historic value is given a particular weight.

●      Obligatory forecast parameter: Order of MovingAverage

The order of the moving average is a number N that determines the length of the time interval for calculating the average. This is the number of chronologically sequential historic values.

Do not enter a negative number for the order.

●      Mandatory forecast parameter: Weighting Factors.

The weighting factors specify the relationship between the individual historic values and the average calculation. The sequence is important: Weighting factor 1 refers to the previous periods; weighting factor 2 refers to the periods before that, and so on.

You want to create a forecast based on monthly values and choose a weighted moving average with an order that has the value 6. In this case, you want to place more weight on the most recent monthly values than on the less recent monthly values. The historic data

is taken from months 5 to 10. The 6 weighting factors and the relevant months are as follows:

No. Weighting Factor Month

1 3,00 10

2 2,00 9

3 2,00 8

4 1,00 7

5 1,00 6

6 1,00 5

●      Optional forecast parameters: outlier correction, logging statistical key figures, ignoring initial zero values.

Linear Regression

Simple linear regression (ordinary least squares).

●      Optional forecast parameters: trend damping, outlier correction, logging statistical key figures, ignoring initial zero values.

Seasonal Linear Regression

Seasonal linear regression is based on the same statistical procedures as used in demand planning.

For more information, see http://help.sap.com/ → SAP Business Suite → SAP Supply Chain Management → SAP APO 3.1 →Application Help → Demand Planning → Demand Planning Process → Definition/Redefinition of Forecast Models → Creating a Master Forecast Profile→ Univariate Forecasting → Forecast Strategies → Seasonal Linear Regression

●      Mandatory forecast parameter: Periods per Season

●      Optional forecast parameters: trend damping, outlier correction, logging statistical key figures, ignoring initial zero values.

Simple Exponential Smoothing (Constant Model)

Simple exponential smoothing is suitable if the historic data shows a constant trend.

●      Smoothing factor settings: Alpha (base value)

●      Optional forecast parameters: outlier correction, logging statistical key figures, ignoring initial zero values.

Simple Exponential Smoothing with Alpha Optimization (Constant Model)

This procedure corresponds to the “simple exponential smoothing“ described above, with one modification; in addition, the system calculates the Alphasmoothing factor. The Alpha value is variegated in the interval using the defined step size and a forecast calculation (for the historic time frame) is performed in each case. The optimum value for Alpha is the value that produces the smallest error in the forecast results.

●      Smoothing factor settings: Optimization Variable, Alpha From, Alpha To, Alpha Step Size.

Linear Exponential Smoothing (Trend Model)

The forecast is calculated according to Holt’s method and is suitable if historic values display an upward or downward trend.

●      Smoothing factor settings: Alpha (Base Value), Beta (Trend Value).

●      Optional forecast parameters: trend damping, outlier correction, logging statistical key figures, ignoring initial zero values.

Seasonal Exponential Smoothing (Seasonal Model)

Choose this strategy if your historic values show seasonal fluctuations (for example, annual fluctuations) from a constant base value.

●      Mandatory forecast parameter: Periods per Season

●      Smoothing factor settings: Alpha (Base Value), Gamma (seasonal components).

●      Optional forecast parameters: outlier correction, logging statistical key figures, ignoring initial zero values.

Seasonal Trend Exponential Smoothing

The forecast is calculated according to Winter/Holt’s multiplicative method and is suitable if historic values display seasonal fluctuations from an upward or downward trend. The fluctuation increases with an upward trend.

Ice cream sales in summer: Assume that ice cream sales rise by a trend of 10% annually. A seasonal increase of 30% each summer then leads to ever greater absolute fluctuations.

●      Mandatory forecast parameter: Periods per Season

●      Smoothing factor settings: Alpha (Base Value), Beta (Trend Value), Gamma (seasonal components).

●      Optional forecast parameters: trend damping, outlier correction, logging statistical key figures, ignoring initial zero values.

Croston Method

The Croston method was developed specifically for sporadic trends. This procedure uses exponential smoothing to calculate a mean time interval between the values in the time series that are not equal to zero.

For more information, see http://help.sap.com/ → SAP Business Suite → SAP Supply Chain Management → SAP APO 3.1 →Application Help → Demand Planning → Demand Planning Process → Definition/Redefinition of Forecast Models → Creating a Master Forecast Profile→ Univariate Forecasting → Forecast Strategies → Croston Method

Check whether you want to aggregate the data in order to remove the gaps in the time series so that you can use procedures that consider trend or seasonal time series patterns. You can aggregate data in this way by choosing a rough time characteristic (month instead of day) or by forecasting values for product groups instead of individual products.

Automatic Model Selection 

UseAutomatic model selection allows you to let the system determine which forecast model best fits your historic data.

We recommend that you use automatic model selection if you do not know the trend of your historic data, if you cannot estimate how your data will develop, or if you do not want to specify a model.

FeaturesThe system performs a number of tests and uses the results to determine the model to be used (see Forecast Strategies). If the model chosen is exponential smoothing, the system optimizes the relevant smoothing factors (Alpha, Beta, Gamma).

Note that automatic model selection requires a high calculation effort. This is particularly true of the seasonal trend model. The calculation effort also depends on the scope of the search space and the precision of the step sizes that you have set.

Activities       1.      First the system tests for sporadic historic data by determining the number of periods that do not

contain any data for the history key figure. If this number accounts for more than 66% of the total number of periods, the system automatically uses the Croston method.

       2.      Then the system tests for white noise. If there is white noise, the system automatically uses the constant method.

       3.      If both tests are negative, the system tests for seasonal and trend effects.

3.                             a.      First the system deletes existing trends. To test for seasonal effects, the system determines the auto-correlation coefficients. If the auto-correlation coefficient is greater than 0.3, the test is positive.

4.                             b.      To test for trend effects, the system determines the trend significance parameters. If the seasonal test is positive, the system removes possible seasonal effects. If no seasonal tests are determined, the system runs the test using the number of past periods minus 2. If seasonal effects are determined, it runs the test using the number of periods in a season plus 1.

Since the results of these tests determine the model that the system checks in the next step, the Periods per Season parameter is particularly significant. If your historic data contains, for example, a season with seven periods and you enter the value “3“ for Periods per Season, the seasonal test will probably be negative. In this case, the system does not check the seasonal model but checks the trend and constant models only.  

       4.      The system uses the selected model (see the table below) and performs the forecast. It calculates all error measures. In models that use forecast parameters (Alpha, Beta, Gamma), these parameters vary to reflect the areas and step sizes specified in the forecast profile.  

Test results and model selection

Test for White Noise

Test for Sporadic Data

Seasonal Test Trend Test

Croston model X

Trend model X

Seasonal model X

Trend season A A

Linear regression o X

Seasonal linear regression

A A

Legend for the characters in the table:

X – model is used if the test is positive.

A – model is used if all tests are positive.

o – model is used if the test is negative.

The constant model always runs, unless the test for sporadic data is positive. In this case, the Croston model is used exclusively (as a special variant of the constant model).

The system chooses the model with the parameters that produce the lowest error measure. The error measure is specified by the selection made in the Error Measure field in the forecast profile.

Outlier Correction 

Use Outliers are atypical values that cannot be explained by the forecast model. The results of the forecast can be heavily influenced by outliers.

The system is able to identify and replace outliers in the historic data. To do this, the forecast procedure calculates forecast values in the past period and compares them to the historic values. If the difference (the residual) exceeds a specific threshold value, the historical value is replaced by the ex-post-forecast value for the corresponding point in time. After this correction, the forecast calculation is performed again with the amended historic data.

You determine a Sigma factor in order to define the threshold value.

IntegrationOutlier detection depends on the forecast model because the forecast value is calculated using a model and its related algorithm.

FeaturesIn the context of the forecast function, outliers in the historic values are defined by the Sigma factor. The greater the Sigma factor the more tolerant the system of atypical values, and the fewer outliers are determined.

The Sigma factor fac controls outlier detection in the following way: An observed value y is declared to be an outlier if the difference to the forecast value e is greater than fac *s. s denotes the standard deviation of the residuals.

ActivitiesActivate outlier correction if you think that outliers are having an unfavorable effect on the forecast result in accordance with the forecast function definition.

Do not select outlier correction if atypical values are always to be taken into consideration by the forecast.

 Trend Damping 

UseFor forecast models with a trend component (linear regression, the trend models for exponential smoothing with or without seasonality, and, in some cases, automatic model selection), you can damp the trend for future forecast values by specifying a trend damping factor.

Use the trend damping factor if you expect that the past growth rate will either slow down or intensify in the future.

FeaturesThe trend damping factor is a number that is multiplied by the trend value (growth rate) for the calculation of each forecast value at the respective time. In this way, growth in a long-term trend is further slowed or intensified:

●      With a trend damping factor that is less than 1, a type of saturation effect is produced. The trend value will exponentially converge to 0.

A trend damping factor of 0.9 decreases the growth rate for each period by 10% recursively.

If, for example, the number of cars sold is currently growing by 1000 per period, the growth in the number of cars sold in the next period would be 0.9 * 1000 = 900, and would be 0.9 * 900 = 810 in the period after that, and so on.

●      To achieve the reverse effect, you can enter a trend damping factor that is greater than one.

ActivitiesYou use this option to perform trend damping. Specify a trend damping factor that corresponds to your expectations.

Logging Statistical Key Figures 

UseThis function logs statistical information about the forecast calculation.

After the forecast function has been executed, the system displays the corresponding statistical information and the error messages for the forecast calculation in the log.

FeaturesThe following statistical information is logged:

●     Error totals

●     Mean absolute deviation (MAD)

●     Mean absolute percent error (MAPE)

●     Mean percentage error (MPE)

●     Mean square error (MSE)

●     Root of the mean square error (RMSE)

●     Number of outliers (where outlier correction is active)

●     Selected forecast model (with automatic model selection)

●     Smoothing factors (with optimization of smoothing factors)

ActivitiesYou choose this option in order to log statistical information about the forecast result.

 Ignoring Initial Zero Values 

UseYou use this function to determine whether a string of zero values at the beginning of a selected period in the past are to be taken into consideration in the forecast.

You want to calculate forecast values for your product. The last 24 months define the historic time frame. Therefore the time series of products that have only existed for a few months begins with a lengthy sequence of zero values. You do not want the forecast values to be influenced by these values, so you select the option Ignore Initial Zero Values.

ActivitiesChoose this option if initial zero values are to be excluded from the forecast calculation.

 Repost 

UseYou use the Repost function type, like the Copy function type, to post the key figure values for existing characteristic combinations to other combinations. In contrast to copying, the key figure values for the From values are deleted. For an introductory example, see Planning Functions.

You use the table for key figure selection to determine which key figures you want to repost.

In the From and To Values for Reposting table, you can either create a simple reposting process or multiple reposting processes within a planning function.

The following rules apply:

●     Both the From and To values for reposting have to be single values.

●     Both the From and To values are changed and have to be included in the filter that is transferred to the planning function.

●     When you repost, the key figure values are always added to the To values.

 Repost (Characteristic Relationships) 

UseYou use the Repost by Characteristic Relationship function to repost transaction data so that it is consistent with the characteristic relationships. The original records are deleted and reposted to the correct characteristic combinations.

In characteristic usage, you can specify which characteristics are to be corrected. This only makes sense for characteristics that can be derived in accordance with the characteristic relationships.

Note the following condition: A planning function of this type can only be created on an aggregation level that itself has been created directly on a real-time InfoCube (a simple aggregation level, see Aggregation Level). The aggregation level has to include all the InfoObjects of the InfoCube that are valid in aggregation levels.

Since normal use of an InfoCube does not allow you to completely delete combinations of characteristics, that is records, the planning function only resets all the key figures to zero. To fully remove combinations of characteristics from the InfoCube, you must compress the InfoCube in the InfoCube administration (transaction RSA1). You must select the indicator With Zero Elimination.

 Revaluation 

UseYou use the Revaluation function type to increase or decrease key figures by a percentage figure.

No characteristic values are changed. In characteristic value usage, you can only select characteristics as condition characteristics.

You can choose whether you want to enter a common percentage for all key figures or revaluate key figures with individual percentages.

In both cases you can either enter the percentage directly or use variables. The percentage is interpreted as delta; the system does not expect you to enter a percentage sign.

If you enter 15.4, the system performs the following calculation:

new value = old value + 15.4% * old value.

 Distribution by Key 

UseYou use the Distribution by Key function type to generate the characteristic combinations to which data is distributed in accordance with the master data and characteristic relationships. The key figure values are distributed according to the expressly specified distribution keys. These are distribution functions that determine the weighting of the distribution.

For an introduction to how a planning function of type Distribution by Key works, see Process Flow of Planning Function: Distribution by Key.

You use the table for key figure selection to select the key figures that you want to distribute.

You can control the distribution process in different ways:

●     Distribution with a top-down variant

○     Distribute All: The entire block is totaled.

○     Only Distribute Not Assigned: Values are only distributed if they have the characteristic value Not Assigned [#]  in the current block for all of the characteristics to be changed.

●     Distribution using manually created entries in the From and To Values for Distribution table.

You can create one or more distribute operations by manually entering the characteristic restrictions for the characteristics that are to be changed.

The system continually totals the values of the key figures on the From side over all the records in the block that correspond to the characteristic restriction, and distributes this total to the To values.

With the From and To Values for Distribution table you can either enter a specific value in the Factor column or select a formula variable from the input help for the To values. The system displays them in the Factor Variable Text column.

If the characteristic restriction of a To value is not a single value, this key is valid for every characteristic combination that corresponds to the characteristic restriction.

The keys are normalized during processing; they are converted into percentages. The system first totals the distribution factors that are assigned to the individual characteristic values and then distributes the values relatively. This results in percentages that always add up to 100 %.

The same key applies to all the key figures to be distributed for each planning function. 

Combinations are generated on the To side for the specified characteristic restrictions. This is consistent with the master data and the characteristic relationships defined for the InfoProviders. If the system cannot find a target for a block and a subprocess, the system terminates the function and produces an error message.

The system performs the following steps to execute a planning function of type Distribution.

1.                                                   i.       The total amount to be distributed is determined.2.                                                 ii.       For the data records that are affected by the From values, the key

figure values are deleted.

3.                                                iii.       In accordance with the distribution keys, the totals are added together with the key figure values of the data records selected by the To values.

The following rules apply:

●     Both the From and To values are changed and have to be included in the filter that is transferred to the planning function.

If the From value is created so that it can select data records that are not in the filter, the system does not produce an error message. The data records are not part of the distribution.

If the To value is created so that it can select data records that are not in the filter, the system terminates the entire planning function and produces an error message.

If a target has been specified in one or more subprocesses, the function is executed and as a result, the target contains the appropriate totals.

●     Rounding differences are distributed evenly to those target data records that are not equal to zero.

  Distribution by Reference Data 

UseYou use the Distribution by Reference Data function type to generate combinations of characteristics that correspond to the reference data. The system distributes data in accordance with these combinations. The key figure values are distributed by percentage in accordance with the reference data.

You use the table for key figure selection to select the key figures that you want to distribute.

The system provides two parameters for the Selection of Reference Data.

Parameter  Description

Reference Key Figure (optional)

You determine a key figure that is to be used in the reference data to calculate the distribution key.

●     When you have chosen this key figure, the system distributes all of the key figures to be distributed according to this key, that is, according to this reference key figure.

●     If no reference key figure is selected, the system calculates a key individually for each of the key figures to be distributed. The same key figure is used in the reference data that is distributed.

Reference Values on Any Block Characteristics

You set a reference value for one or more block characteristics. While reading the reference data for each block, the system overwrites the characteristic value of the block in the characteristic with this reference value.

An InfoProvider provides data for the years 2005 and 2006. You want to change transaction data for the year 2006. Thus the data from the year 2006 is selected in the filter that is transferred to the planning function. Therefore all the blocks have year 2006. However, if the reference value is 2005, you can ensure that the keys are calculated according to the data from 2005.

The distribution process can be controlled in different ways:

●     Distribution with a top-down variant

○     Distribute All: The entire block is totaled.

○     Only Distribute Not Assigned: Values are only distributed if they have the characteristic value Not Assigned [#]  in the current block for all of the characteristics to be changed.

●     Distribution using manually created entries in the From and To Values for Distribution table.

You can create one or more distribute operations by manually entering the characteristic restrictions for the characteristics that are to be changed.

The system continually totals the values of the key figures on the From side over all the records in the block that correspond to the characteristic restriction, and distributes this total to the To values.

The system distributes data to precisely those characteristic combinations that exist in the reference data and fit the characteristic restrictions in the To values.

The percentage distribution corresponds to the percentage distribution in the reference data.

In top-down distribution, the system distributes to all characteristic combinations that exist in the reference data. Data records are excluded that have the value Not Assigned [#] for all characteristic values.

If there is no reference data for a subprocess, the key figure values for this subprocess are not distributed; the system produces a warning.

The order in which the system executes the distribute function is the same as the order in which the Distribution by Key function is executed. The same rules apply. For more information, see Distribution by Key.

 Currency Translation 

UseYou use the Currency Translation function type to convert currencies of key figures into other key figures.

In the Key Figures and Currency Translation Types table, you can specify multiple translations. For each translation, you have to select a currency translation type as well as a source and target key figure. The value in the target key figure is overwritten. This also applies when the source key figure is empty. The value of the source key figure is not changed during currency translation. In this way the function can be executed more than once without the results changing. There is a special logic to ensure that this is the case when the source key figure and target figure are identical and the source unit of the data record is used: If there is already a value in the target unit, it is ignored if there are values in the source unit that do not have the target unit. Otherwise the value in the target unit is used.

The currency translation converts the key figure Amount with the source currency in the data record into the fixed target currency EURO. The key date 01.01.2001 was selected as time reference. There are two data records for different companies. Company 4711 is planned in CHF. Company 0815 is already planned in EUR.

Values before the conversion

Amount Currency Key Company

10 CHF 4711

4 EUR 0815

Values after the conversion

Amount Currency Key Company

10 CHF 4711

6.3 EUR 4711

4 EUR 0815

A new data record is created.

Manual change of the value in Euro

Amount Currency Key Company

10 CHF 4711

6 EUR 4711

9 EUR 0815

Repeated execution of the planning function

Amount Currency Key Company

10 CHF 4711

6.3 EUR 4711

9 EUR 0815

The value for company 4711 is overwritten by the currency translation.

Within the planning functions, some of the time references of the currency translation types are not supported. Selection upon Translation and Query Key Date are not supported. You can use variables in place of these time references. You can use the variable 0PLANDAT for the query key date. If you want to enter the date when you execute the planning function, use the input variable.

The changed characteristics can be those characteristics that contain the currency key. By default, all the characteristics that contain the currency key are selected. You can usually use this setting.

Note of the following remarks about modeling:

If you want to enter plan data in different currencies, you can use key figures with their own fields for the currency key for each purpose. Examples for such purposes are Entry of Original Amounts in Company Currency and Consolidation of Amounts in Group Currency.With characteristic relationships you can make sure that only one suitable currency key can be entered for a company. The aggregation levels can be easily modeled so that you work with different sets of data for each purpose. 

Only those key figures that are used are included in the aggregation level. If you use a key figure for different purposes, you must define the data with selections in filters.

Standard Key Date in Planning Functions 

DefinitionThe standard key date is a key date that is used in the entire planning model. It can be set for every real-time enabled InfoCube in the characteristic relationships.

UseThe following options are available to set a key date.

●     Unspecified (default value is the system date if all of the participating InfoCubes have the key date = unspecified).

●     Fixed Date

●     From Variable

All objects that depend on the key date, such as the filter or hierarchies that are used in the filter or in the from and to values of the copy and distribution functions can be set to the standard key date.

If a planning function is executed, the system calculates the standard key date as follows.

●     If the aggregation level was created directly on a real-time enabled InfoCube, the standard key date is the same key date that is set in the characteristic relationships on this InfoCube.

●     If the aggregation level was created on a MultiProvider, all participating real-time enabled InfoCubes below the MultiProvider are checked. If all of these have the setting unspecified, the standard key date is the current system date. If one of the real-time enabled InfoCubes has another setting for its key date, the first one that returns a certain value wins. Variables are analyzed upon return.

All time-dependent objects continue to provide the option of using your own key date in your concrete application.

This can be useful in the following case: you want to use a specific hierarchy that is to be read with another key date than the master data attributes.

IntegrationYou make the key date setting for planning in the Planning Modeler in the InfoProvider area on the Settings tab page.

 Planning Sequences 

UsePlanning sequences are used within BI Integrated Planning to group planning functions. They allow you to save groups of planning functions in a sorted sequence and execute groups of planning functions sequentially.

IntegrationPlanning sequences can be edited, saved and tested in the planning modeler.

They can be included in a process chain as a step. They can also be linked to a variant of variable values.

FeaturesA planning sequence can be made up of one or more steps. The following types of step are available:

Step Types for a Planning Sequence

Type Description

Planning function Based on an aggregation level, the system saves a planning function and a filter with which the planning function is executed.

Input template You can embed input templates into the sequence especially for testing planning functions. Input templates are defined by an aggregation level and a filter.

If a planning sequence is executed as a whole, the embedded input templates are not taken into account.

ActivitiesTesting a Planning Sequence in the Planning Modeler

In the planning modeler, choose Execute to test entire planning sequences or execute planning sequences step by step. In the latter case, the input templates appear at the bottom of the application.

When you execute the steps, the system keeps the data in the buffer. The system only writes the transaction data from the buffer to the database when you choose Save.

If the planning sequence includes input-ready variables, you can set them manually before executing the steps and save the value combinations of the variables as a variant.

Execution of a Planning Sequence Within a Process Chain

You can embed a planning sequence in a process chain using the process type Execute Planning Sequence. The planning sequence can be linked with a stored variant for variable values. More information: Scheduling Planning Sequences in Process Chains; an example is also available underPlanning Sequence for Bottom-Up Planning.

Scheduling Planning Sequences in Process Chains 

UseBy integrating planning sequences into process chains, you can execute planning sequences in the background.

You can include a planning sequence in a process chain by including a process of process type Execute planning sequence in an existing process chain. In the detailed maintenance of the process, select the required planning sequence and possibly a suitable variable variant.

For planning sequences that are executed in the background, you can specify whether and how the planning sequences are to be divided into smaller packages. These packages can be executed in parallel as separate subjobs in multiple work processes.

You can monitor and analyze the parallel execution using the BI background management (transaction

RSBATCH). More information:  Setting Parallel Processing of BI Processes

Prerequisites●      To schedule a planning sequence within a process chain, you must first create the planning

sequence in the planning modeler. For more information, see Planning Sequences.

●      You created the required process chain in the process chain maintenance transaction (transaction RSPC) and defined the behavior of the process chain during execution, if

necessary. More information:  Process Chain Maintenance and  Display/Maintenance of Process Chain Attributes.

●      If your planning sequence contains variables that can only be filled with user entries or if you want to overwrite variables with user entries, you can store a variable variant in the planning modeler. You can refer to this variable variant in the maintenance of the process with which you schedule the planning sequence.

You can store variable variants either locally for one user or as global variable variants. If you want to use a local variable variant, you must also use the user for which the variable variant was created for the definition of the process and as the user for background

execution. More information: Variables and  Display/Maintenance of Process Chain Attributes.

Note that changes that were made shortly before execution on an application server are not necessarily active immediately on all application servers. This depends on the settings for database buffering in your system and is true for many BI objects as well as for changes to the customer exits used. In production systems, you must make sure that at least the time that you selected for updating database buffering has elapsed between the last change to any objects and scheduling the process chain.

Procedure       1.      In the process chain maintenance, create an application process of type Execute a planning

sequence.

Note that some BI objects use the table buffer for read accesses. If you therefore want to schedule planning sequences distributed on more than one server, you must make sure that the default time that you defined for the table buffer has elapsed between the scheduled start and the last change (delivery default is 120s).

       2.      Select the required planning sequence and, if necessary, a variable variant.

       3.      Choose Apply.

       4.      In the screen area Activate or deactivate packaging, define whether the planning sequence should be executed in its entirety or if it should be processed by package.

Selection for Packaging

Option Description

Process Without Packaging The entire planning sequence is executed. The system only saves all the data on the database when all the contained functions have been executed without errors.

No further settings are required for this option.

Process in Packages The planning sequence is executed step by step. The system writes the modified data to the database after each step and deletes it from the buffer.

For each step you can set whether and how it should be packaged. When a step is packaged, the system writes each individual package that was processed without errors to the database.

If you want to process the planning sequence by package, the system reads the steps of the planning sequence from the database and fills a table. Only those steps of the planning sequence that execute a planning function are displayed.

The step numbers are copied from the database. Since the steps for input masks are missing, the numbering is not sequential.

       5.      If you selected the option Process in packages, you can select which of the following packaging types should be used for each step.

Type of Packaging

Option Description

No packaging Exactly one subjob is scheduled with BI background management for such a step.  It executes the planning function for the entire filter of the step.

Automatic packaging The characteristic with which the step is packaged is determined automatically when it is executed. You can define the number of packages into which the filter should be broken down in the last column of the table.

You can also define if the values should be determined from the master data table or from the dimension table. (More information is available in section Determining Values for a Characteristic.)

Configured packaging The characteristic with which the step is packaged must be selected. You can use two kinds of help in selecting the characteristic.

1. There is a value help for the InfoObject field that permits you to estimate the number of values for all the characteristics that are possible for the packaging.

2. You can select some steps and display a proposed characteristic for them.  You can first define how many packages should be created in the last column.

You can also define if the values should be determined from the master data table or from the dimension table. (More information is available in section Determining Values for a Characteristic.)

You can define how many individual values of the characteristic should be included in a package for the selected InfoObject.

The system computes the number of packages from the number of all values divided by the number of values for each package. It rounds this number up in accordance with the formula: Number of packages = ceil (number of all values / number of values per package).

Determining Values for Characteristics

There are two ways to determine the values that are relevant for a characteristic. In both cases the characteristic restriction from the filter is used for the characteristic to be examined.

With this characteristic restriction, either the master data table or the dimension table is read. The master data table contains all the values for this characteristic. The dimension table contains all the values that are already stored in the relevant InfoProviders.

In both cases you can change the values in the tables by running a planning function.

Values can be written to dimension tables for all characteristics that were not yet contained in the InfoProvider.

The system accesses the SID table for the read type master data for characteristics that do not have a master data table. In this case new values can occur during execution of a planning function.

Function of the Master Lock

To prevent parts of a planning sequence from not being executed because other users are locking data, the master process passes a master lock ID to the subjobs.

At the beginning of execution, the master process locks all filters for the BI lock server. It sets a privilege lock, releases the normal locks again, and returns an ID for the master lock. From now on, only those work processes that can certificate themselves using this master lock ID may change the data within the filter. The subjobs certificate themselves using the master lock, and

save the data using a normal lock. When the planning sequence has been completely processed, the master process releases the master lock.

You can monitor the master locks in the BI lock management (transaction RSPLSE). More information: Lock Concept and Lock Management

In rare cases (for example, if the administrator cancels the master process on purpose), the system might not release the master lock.In this case you can delete the master lock manually in the BI lock management transaction. This assumes, however, that you have authorization to execute the planning sequence. If subjobs are still open, the system cannot execute them any longer.

Determining the Characteristics in Question for Packaging

Some of the characteristics of an aggregation level on which a planning function is created cannot be packaged.

○       You can only package those characteristics that cannot be changed.

As described above in the section about how the master lock works, the subjobs for the filter packages request real locks from BI lock management. In BI lock management you can configure the characteristics that should be relevant for locking for each realtime-enabled InfoCube. To prevent subjobs from mutually locking one another because their filter packages cannot be separated with regard to lock management, only selected characteristics can be used for packaging.

○       Only certain characteristics can be packaged with respect to lock management. The table below shows how they are defined.

Type of Aggregation Level Definition of Characteristics Permitted for Packaging at this Aggregation Level

Simple Aggregation Level (created directly on a realtime-enabled InfoCube)

Exactly the characteristics of the realtime-enabled InfoCubes that are relevant for locking are permitted.

Complex Aggregation Level (created on a MultiProvider)

A characteristic is permitted if the following rule is satisfied for all relevant realtime-enabled InfoCubes: If the characteristic gets its data from a realtime-enabled InfoCube, it must be relevant here for locking.

The figure below shows a complex aggregation level:

Planning function F1 is created on aggregation level A1.

Aggregation level A1 is created on MultiProvider MP1.

Its parameters are defined from InfoCubes C1, RC1 and RC2.

InfoCube C1 is not a realtime-enabled InfoCube. It provides the parameters for characteristics A, B, C, D and E in MultiProvider MP1.  However, it does not manage any locks. It is therefore not relevant for further discussion.

InfoCube RC1 is a realtime-enabled InfoCube. It defines the parameters for characteristics A, B, C, D and F in MultiProvider MP1. Characteristics A, B, D and F are entered as relevant for locking in the lock management.

InfoCube RC2 is a realtime-enabled InfoCube. It defines the parameters for characteristics A, D, E and F in MultiProvider MP1.  Characteristics A, E and F are entered as relevant for locking in the lock management.

According to the above rule, the characteristics of the MultiProvider result in characteristics A, B, E and F being permitted for packaging:

○       A and F get their values from RC1 and RC2 and are relevant for locking in both of these. A and F are therefore permitted.

○       B only gets its data from RC1 and is relevant there for locking. B is therefore permitted.

○       C only gets its data from RC1 and is not relevant there for locking. C is therefore not allowed.

○       D gets its data from RC1 and RC2, but is not relevant for locking in RC2. D is therefore not allowed.

○       E only gets its data from RC2 and is relevant there for locking. E is therefore permitted.

Since the aggregation level does not contain F, the characteristics A, B and E are not used.

In the planning function, E is used as the characteristic to be changed. Therefore only A and B are available for packaging.

Automatic Selection of Characteristics

If you want to select a characteristic automatically, the required number of packages and how the values should be determined must be defined.

The system then defines the characteristics permitted for packaging. The number of characteristic values contained in the relevant characteristic restriction is determined one after the other for these characteristics. When a characteristic is detected for which the system found more characteristic values than packages were requested, it is proposed or used for packaging.

Segmenting Filters in Packages

If you want to segment a filter for a step in a package, you must first define which characteristic is used for packaging and how the value is to be determined. Either the number of packages or the number of values per package is also defined for each package.

The values are distributed randomly (but can be reproduced) amongst the set of packages so that each package contains at least one value but does not contain more than the number of values for each package.

Settings for Physical Parallelism

With Parallel Processing in the maintenance for the process of type Execute a planning sequence, you can overwrite the default values for process type PLSEQ for this process.

The default values for a process type can be stored in BI background management. More

information:  Setting Parallel Processing of BI Processes

With these settings you can define    

○       the number of parallel work processes in which the subjobs should be executed

○       the servers on which these work processes should be executed

○       the priority with which the subjobs should be executed

Step-by-Step Processing of the Planning Sequence

If you selected the option Process in packages, the planning sequence is processed step by step.

Each step is segmented into the required number of subjobs. All the subjobs of the step are then scheduled by BI background management.The master process checks if all the subjobs of the last step were executed. The next step begins when this check has been completed and if all subjobs were successful. If a subjob terminates with an error, the planning sequence is not executed. In this case the master process schedules an additional subjob that informs the BI background management that the reserved physical work processes can be released. The master process then releases the master lock.

The example Planning Sequence for Bottom-Up Planning demonstrates the step-by-step processing of a planning sequence.

 Planning Sequence for Bottom-Up Planning  Defining the Planning Sequence

We will investigate an example of a planning sequence that prepares a bottom-up planning process. It consists of 3 steps (see the figure).

       1.      A linear regression is computed for all existing products and regions based on the actual data for a number of sales items; this results in the data Forecast for the months of the following year. This version of the data is stored under the version PLAN_LIN.

       2.      The sales figures are derived for two new products from similar products. This is done with a copy function.

       3.      In bottom-up planning, the planners responsible for the individual regions should adjust the forecasted numbers to their estimates. However, since you want to get the forecast data for comparison purposes, an additional version of the data is provided for this planning session. This is also done with a copy function.

All three functions in this example work on the same aggregation level.

Characteristics: Version, Calendar Month, Region and Product.

Key figure: Number of items sold

All characteristics in all the realtime-enabled InfoProviders are relevant for locking and therefore can be used as packaging characteristic.

Overview of the Functions Contained in the Planning Sequence

Step 1. 2. 3.

Function Type Forecast Copy Copy

Comments Writes the data for forecast period to version PLAN_LIN. Reference data is read from version ACTUALS.

Copies data in version PLAN_LIN to two new products based on similar products that were already sold.

Copies the forecast data from version PLAN_LIN to an additional working version PLAN_BOTTOM for the BOTTOM-UP planning.

Filter Version = PLAN_LIN, Month = Jan 2007–Dec 2007

Version = PLAN_LIN Version = PLAN_BOTTOM

Characteristics of Function to be Changed

Month Product Version

Parameters of Function

Past: Jan 2005 – Dec 2006,

Past filter: Version = ACTUALS,

Forecast period: Jan 2007 – Dec 2007,

 Forecast parameter: Linear Regression

Activity 1:

From product 77

To product 105

Activity 2:

From product 93

To product 106

Activity 1:

From version PLAN_LIN

To version PLAN_BOTTOM

Scheduling the Planning Sequence

The planning sequence should be scheduled within a process chain.

The planning sequence is selected in the detailed maintenance of the process, but no variable variant is selected because all the contained variables can be replaced without user interaction.

Since the data volume is of medium size, the setting Process in packages is selected. For reasons of clarity, the steps in the example are divided into few packages, but very different packaging types are selected for these packages.

Dividing the Planning Sequence into Packages and Packaging Types

Step 1. 2. 3.

Type of packaging Configured No packaging Automatically

InfoObject Region

Method for dividing into packages

Dimension Dimension

Estimated number of values

10

Package size 4

Number of packages 3 1 3

Processing

The following figure gives an overview of a master process that links the planning sequence into the process chain. It manages the execution of the planning sequence, schedules the subjobs, and collects the results of the subjobs. The filters of the steps are divided into packages according to the settings and executed in parallel background processes using the BI background management.

Master process step 1:

●      The master collects all the filters and sets a write lock for the BI lock server. The BI lock server grants it a master lock. The real lock is then released.

●      The first filter is divided into three packages with a maximum of four values with the predefined characteristic Region.

●      Three subjobs are scheduled with the BI background management.

Master process step 2:

●      The master waits until the BI background management has executed all three subjobs. The system only performs the next step when all the subjobs have been executed.

●      No packaging is configured for step 2 of the planning sequence. For this reason, only one subjob is scheduled with the entire filter.

Master process step 3:

●      The master waits until the BI background management has executed the subjob. The system only performs the next step when this subjob has been executed.

●      Automatic packaging with three packages is defined for step 3. The master looks for a characteristic that has at least three characteristic values and accordingly breaks the filter down into three packages.

●      Three subjobs are scheduled with the BI background management.

End of Master Process:

●      The overall status of the planning sequence is recorded and the logs are written for the last time.

●      The system removes the master lock.

 Variables 

UseVariables are used to parameterize a query, a planning function, a filter, a characteristic relationship or a data slice. When a query, planning function or Web application is executed, they are filled with values.

Variables act as placeholders for characteristic values, hierarchies, hierarchy nodes, texts, and formula elements, and can be processed in many different ways.

●      Depending on the objects for which you want to define variables, there are different variable

types. For more information, see the documentation on the Query Designer under  Variable Types.

●      The processing type determines how a variable is filled with a value for the runtime of the query, planning function or Web application. For more information, see the documentation on the

Query Designer under  Processing Types for Variables.

When you use variables, one planning function definition, for example, can be used as a basis for many different planning functions: you want to create a planning function of type Copy that copies your current data from the current version to another version. You use a variable for the Version characteristic in the To parameters of the planning function. Before you execute the planning function, you decide to which version the current data is to be copied.

For formula variables that are used in planning functions, for example for conversion functions, the processing type Replacement Pathis not available. Only the Number dimension is supported here.

You cannot create text variables in the Planning Modeler. In input-ready queries, however, you can use text variables without any restrictions.

IntegrationVariables as Reusable Objects

Variables do not depend on an InfoProvider, but on the respective InfoObject only. A variable that you define for an InfoObject is available in all InfoProviders that use this InfoObject.

Variables can be defined in the Query Designer or in the Planning Modeler or Planning Wizard.

For example, when you define a variable for a planning function in the planning modeler, it is available for reuse for all queries or planning functions.

Validity Area of Variables

The same variable can have different values in different locations. A separate instance of the variable is created whenever a variable is filled with a value. In some cases different instances (and therefore the values) of variables are merged into a single instance. This means that the variable has the same value in all the objects involved. This happens, for example, when a variable is used in two different queries. However, this is only the exception.

FeaturesVariables help you to flexibly set or parameterize your objects. The following objects support the use of variables:

Using variables

Object Using Variables

Queries (especially input-ready queries)

●      For example, to parameterize characteristic restrictions in the query

●      In formulas, conditions, exceptions and as a placeholder for text

When a query is started, variables can be assigned values in three different ways:

●      With a predefined value

●      With a variant

●      With a user entry

Filters To parameterize characteristic restrictions that describe the filter.

Planning functions Depending on the respective planning function type, to parameterize conditions and parameters, for example, to parameterize the conversion factor in planning functions of type conversion.

Variables can be assigned values in the following ways:

●      With a predefined value

●      With a command in the application

Characteristic relationships ●      To parameterize the hierarchy used

●      To parameterize selection from a DataStore object

Data slices To parameterize characteristic restrictions that describe the data slice.

Variables that are used in characteristic relationships and data slices cannot call a dialog for the manual entry of values. These variables must have a value at the time of execution.

Times of Variable Calls

The different ways in which variables are used result in different times at which variables are executed and at which they are assigned new values.

Use Time of Variable Call

Query        1.      The variable is processed each time the application is restarted.

       2.      When you call the dialog box Change Values for Variables (also known as: Variables Screen). This forces the query to be restarted.

If you end the Variables Screen with OK, the value of the variable does not change if you did not actively make any changes. This means that the Exit is not executed for input-ready variables of type Exit in order to redefine the default value in the dialog box (since it could overwrite the value that is already defined). Variables in the area of the default values and variables for defining the presentation hierarchy take on the value of the current filter state of the characteristic or the currently defined presentation hierarchy. (You can override this behavior with an indicator in the Query Designer). In general, explicitly setting variable values (for example with URL parameters) has priority over implicitly setting these values (for example default value of a variable).

For more information about the dialog box Change Values for

Variables, refer to  Changing Variable Values.

Planning function Only when executing the planning function. Here, too, explicitly set variable values have priority over implicitly set variable values. This results in the following conditions for defining the priority when filling a variable:

       1.      Is the variable set explicitly in the command with data binding?

       2.      Is a variant of the variable specified in the command?

       3.      Is the variable personalized?

       4.      Is there a default value?

       5.      Are none of these conditions satisfied? In this case the Variable Editor opens in the BEx Web while the system merges the variables merge in the BEx Analyzer.

Planning sequence See Planning function.

Filter in planning sequence Each time the planning sequence is executed.

Data slice The first time it is called. You cannot change data slices by changing variables. If no variables are set, the dialog box Change Variables for Variables does not appear.

It must be possible to replace the type of the variable used in data slices automatically. Variables that are entered manually are not allowed.

Characteristic relationship See Data slice.

Merging Variables

If there are two variables with the same name in two different objects, the system creates instances of these variables. From then on there are physically two variables. In certain constellations the system automatically merges these instances so that all variable instances have the same value.

Constellation Merge

Variables with same name in two queries

Yes.

Variables with same name in planning function and query

Only in BEx Analyzer and if the variable value was not replaced by a command there.

To ensure the same value in a Web application, the executing command must perform data binding.

Variables with same name in planning sequence and query

See Planning function

Filter and planning function within a planning sequence

Yes.

Data slice or characteristic relationship with any other object

No.

In the Planning Modeler or Planning Wizard, as well as in the Query Designer, the following tools are available for creating and changing variable definitions according to context.

Tools for Creating, Changing and Displaying Variables

Tool Description

Variables Wizard The wizard takes you through the process of creating a variable step-by-step. Each individual step is context-sensitive and is modified according to the combination of variable and processing types used. This means that the Variables Wizard only offers the selection options that are permitted for that combination of variable and processing types.

For more information, see the documentation on the Query

Designer under  Defining Variables.

Note the following when you use the Variables Wizard in the context of the Planning Modeler or Planning Wizard:

●      The first step is General Information.

●      The system shows further dialog steps according to context:

○        Details

○        Default Values

○        Replacement Path

○        Currencies and Units

(There is no Characteristic dialog step).

Variables Editor The Variables Editor dialog box offers all the options for changing an existing variable. The individual tab pages of the dialog box show the previous settings for the variable.

Not all settings for variables can be changed in the Variables Editor. For example, the variable type and processing type cannot be changed once the variable is created.

Note the following when you use the Variables Editor in the context of the Planning Modeler or Planning Wizard: in addition to the change mode, the Variables Editor also has a display mode.

ActivitiesThe tools for creating and changing variables are available wherever you enter constant values and can use variables.

In the Planning Modeler or Planning Wizard, you can also display and delete variables. In the restriction dialog for a characteristic in the filter, you see the list of the variables available for the selected characteristic in the Variables view for single values. The functions Create, Edit, Display and Deleteare available here.

●      If you choose Create, the Variables Wizard appears.

The Variables Wizard opens with the settings made for the current context: For example, if the Variables Wizard opens in the dialog for characteristic restriction, it has the settings that are appropriate for the type of variable (characteristic variable), the appropriate characteristic and the basic characteristic, as required.

●      If you choose Edit, the Variables Editor opens and you can change certain properties.

●      If you choose Display, the Variables Editor opens in display mode.

●      If you choose Delete, the system deletes the selected variables.

For more information about using these two tools in the Query Designer, see  Variables.

 Changing Variable Values in the Planning Modeler 

UseIn the planning modeler, you want to check a planning function that can be parameterized using variables or execute a planning sequence that contains objects that can be parameterized using variables. In both cases, you want to change the values of the variables in the planning modeler:

●     In order to check a planning function, you have to assign variable values to all the variables that are set as mandatory; a dialog box appears in which you enter values for the variable.

●     When you execute a planning sequence, you can change the values of the mandatory and optional variables in the appropriate input area at any time; the planning sequence is processed using the values that you enter.

You can also personalize individual values by assigning a particular value to it. This value is valid until you reset the personalized setting. Personalization means that you do not have to manually configure your personal variable settings each time. In this instance, BI Integrated Planning uses BEx

personalization for variable values (see  Personalization in BEx).

In the planning modeler, the variable values entered in the current session are noted and set automatically, if they are required. This ensures that you do not have to manually maintain the same variables several times.  

FeaturesIn the planning modeler, you can change variable values to check a planning function or execute a planning sequence, if the variables are being used in the following objects:

●     Variables in filters (see Filter)

●     Variables in planning functions (see Planning Functions)

Depending on how the variable is defined and used, the variable values can come from different sources. Generally the following options are available:

●     Default value for the variable

●     Personalization for the variable

●     Variants saved previously

●     Variable values entered previously (automatic)

●     Values maintained manually

ActivitiesYou are on the Planning Functions tab page and have chosen the check function for a planning function with required entry variables, or you are on thePlanning Sequences tab page in display mode for a planning sequence that contains variables. In the first case, the system shows a dialog box for entering variables; in the second, an input area. It lists all the variables that are available in the current application context. The following activities are possible:

Manual Maintenance of Variable Values

If you have chosen one of the layouts that contains the Key, you can enter variable values manually in the lead column of the variable value.

To display the lead column of the variable value, select the appropriate layout or change the table settings accordingly.

In addition, input help is available for selecting values for some variable types.

Personalizing Variables

       1.      To personalize values for variables or reset personalized values, choose Personalized Variables. A dialog box appears in which you can choose personalized variables.

       2.      To personalize variables, select one or more variables from the table of available variables and insert these values.  To reset personalized values, choose one or more variables from the table of personalized variables and choose Remove.

       3.      You can also change the values in the personalized variables table at a later time.

       4.      Personalized variables are not displayed in the dialog box or input area by default. If you want to display personalized values, choose the Display Personalized Variables option.

       5.      Choose OK. The dialog box for entering variables or the corresponding input area appears.

In the table settings, you can display a column for personalized values and a column for resetting the personalized values. The column for personalized values indicates a personalized variable; the column for resetting the personalized value allows you to reset the current variable value to the personalized value.

Selection and Maintenance of Variants

In the Available Variants selection box, you can select an existing variant. The values determined for the variables in the variants are automatically set as the current values.

●     To save the current values as a new variant, choose Save. The Save Variant dialog box appears. Enter a description for the variant and selectOK.

●     To change an existing variant, select an existing variant from the Available Variants selection box. As a result, the current variables contain the variable values from the variant. Change the values manually and choose Save.

●     To save an existing variant as a new variant, select an existing variant from the Available Variants selection box. Choose Save As. The Save Variant As dialog box appears. Change the description of the variant and select OK.

●     To delete an existing variant, select an existing variant from the Available Variants selection box. Choose Delete.

●     To delete the properties of an existing variant, select an existing variant from the Available Variants selection box. Choose Properties. TheChange Variant Properties dialog box appears. Change the properties of the variant and choose OK.

An existing variant can be marked as an initial variant. This variant is set automatically each time variable input is called. To do this, you select an existing variant from the Available Variants selection box. Choose Properties. The Change Variant Properties dialog box appears. Choose Use as Initial Variantand choose OK.

Check Current Variable Values

To check the current values, choose Check.

 Personalizing Variables 

UseTo avoid having to enter your personal variable settings manually each time, you can personalize individual variables. By personalizing the variables, you assign values to them that are used until you reset the personalization. Personalized variables do not appear on the variable screen.

PrerequisitesMake sure that personalization was activated in your system. For more information, see Personalization in BEx.

ProcedureYou have a planning function or a planning sequence with input-ready variables and would like to personalize values for the variables.

You are on the tab page Planning Function of the Planning Modeler and select Check for the required planning function. Alternatively, you are on the tab page Planning Sequence and execute the required planning sequence. If there are input-ready variables available, the variable screen appears.

Personalizing Values for Variables

       1.      Choose Personalized Variables …

       2.      Select the variables you would like to personalize from the table Available Variables.

       3.      Choose Add.

       4.      If necessary, change the values of the variables using the input help for the variables in the table Personalized Variables.

       5.      Confirm your entries with OK.

Removing the Personalization of Variables

       1.      Choose Personalized Variables …

       2.      Select the variables whose personalization you would like to remove from the table Personalized Variables.

       3.      Choose Remove.

       4.      Confirm your entries with OK.

Displaying Personalized Variables in the Variable Screen

       1.      Choose Personalized Variables …

       2.      Select Display Personalized Variables.

       3.      Confirm your entries with OK.

 Saving Variants in Planning Functions and Planning Sequences 

UseAnalogously to using variants in BEx queries, you can save variants for planning functions and planning sequences in BI Integrated Planning. A variant already contains predefined variable values for the associated planning function or planning sequence. After selecting a variant on the variable screen, the variable values that were stored in the variant for the corresponding variable are copied to the planning function or planning sequence.

There are two types of variant:

●      User-specific variants (local variants)

Local variants are user-specific; that is, they are created exclusively for the particular user and can only be viewed and edited by this user. These variants are not subject to the general authorization check.

●      User-independent variants (global variants)

Global variants are not user-specific; that is, they are not bound to a specific user and can be viewed and edited by all users.

Global variants require the proper authorization. Also note that global variants are not locked. They therefore can be used simultaneously be multiple users.

Prerequisites●      The planning function or planning sequence must contain at least one input-ready variable.

●      When using user-independent variants, authorization object S_RS_PARAM must be maintained correctly so that users can save a variant.

●      You can only assign a variant as the initial variant if personalization was activated in the BEx in

the system. More information:  Personalization in BEx.

ProcedureYou are on the tab page Planning Function of the Planning Modeler and select Check for the required planning function. Alternatively, you are on the tab page Planning Sequence and execute the required planning sequence. If there are input-ready variables available, the variable screen appears.

You can now select values for variables on the variable screen and save them in a variant. When you select a variant, the variable values stored in it are copied for the selected planning function or planning sequence. You can also change the variable values for a variant, add variable values, or remove variable values. You can create multiple variants so that you can choose different variable values. Note that only one variant can be active at any one time. You can also denote one variant as the initial variant. The system automatically uses this variant the next time the planning function or planning sequence is opened.

Saving Variants

       1.      In the variable screen, select the values for the variables you want to store in the variant.

       2.      Choose Save.

       3.      Enter a description.

       4.      If you want to save a global variant, select the option Cross-User Variant and enter a technical name for the variant.

       5.      If you want to load the variant automatically the next time the planning function or planning sequence is opened, select the option Use as Initial Variant.

       6.      Confirm your entries with OK.

Selecting Variants

Select an existing variant. The system copies the variable values stored in the variant to the planning function or planning sequence.

Changing Variants

       1.      Select an existing variant. The system copies the variable values stored in the variant to the planning function or planning sequence.

       2.      Change the values of the variables displayed for the variant.

       3.      Choose Save. 

Save Variant as

       1.      Select an existing variant. The system copies the variable values stored in the variant to the planning function or planning sequence.

       2.      Change the values of the variables displayed for the variant, if needed.

       3.      Choose Save As …. 

       4.      Enter a description.

       5.      If you want to save a global variant, select the option Cross-User Variant and enter a technical name for the variant.

       6.      If you want to load the variant automatically the next time the planning function or planning sequence is opened, select the option Use as Initial Variant.

       7.      Confirm your entries with OK.

Deleting Variants

       1.      Select an existing variant. The system copies the variable values stored in the variant to the planning function or planning sequence.

       2.      Choose Delete.

Input-Ready Query 

UseYou can use input-ready queries to create applications for manual planning. These can range from simple data entry scenarios to complex planning applications.

IntegrationYou define queries for manual planning in BEx Query Designer (see  Defining New Queries).

In Web Application Designer or BEx Analyzer, you can combine input-ready queries with other queries and planning functions to create complex planning applications.

PrerequisitesYou can define an input-ready query on any of the following InfoProviders:

●      Aggregation levels (see Aggregation Level)

●      MultiProviders that include at least one simple aggregation level

The aggregation levels are created in the Planning Modeler. MultiProviders are defined in the modeling functional area in Data Warehousing Workbench.

FeaturesInput-Ready Query Definition

Once you have defined a query on one of the InfoProvider types listed above, you see the Planning tab page under the Properties of structural components (in key figures or restricted key figures, for example). You can use the options here to set which structural components of an input-ready query you

want to be input ready at runtime. For structural components that are not input ready, you can also set whether they are viewed as data not relevant for locking or are just protected against manual entry.

For the structural components, you also have the following options:

Input Readiness of Structural Components of a Query

Option Description

Not input ready (not relevant for locking) The structural components are not locked for exclusive access by a single user because a large number of users use this data as a reference (for actual data, for example).

This is the default setting.

Not input ready (relevant for locking) If you want to protect structural components against manual entries, but allow changes by planning functions, you can use locks to protect this data for one particular user. This allows you to ensure that the planning function works with the displayed data only and not with data that has been changed by other users.

Input ready (relevant for locking) The data is locked for a user and is input-ready for manual planning.

These default settings can be overridden by the system state, for example if no disaggregation takes place (see below).

You can also set whether to start an input-ready query in change mode or in display mode. This property is in the Query Properties on the Planningtab page. If there is at least one input-ready query component, the query is started in display mode provided that no setting has been made to the contrary.

The Start Query in Display Mode setting overrides the default settings about whether data can be changed. If you set the structural component so that the data is input-ready and relevant for locking, but the Start Query in Display Mode setting is activated in the query properties, the query will not be input-ready when it is started. The user can activate input-readiness at runtime, and the settings specified here take effect for the structural component.

In BI applications that use input-ready queries as data providers, you can enter data manually at runtime. More information: Performing Manual Planning and Creating Planning Applications.

Disaggregation (Also Called Top-Down Distribution)

In input-ready queries, only cells on the detail level for the aggregation level can normally be changed. Any cells that contain aggregated values, such as in results rows or inner hierarchy nodes, are not input ready. To be able to change an aggregated value, the value must be disaggregated in all data records that are related to this aggregated value.

Disaggregation cannot be performed with the Unit characteristic for a key figure or with characteristic 0INFOPROV. The Unit characteristic for the key figure and 0INFOPROV are therefore also required characteristics for structural components with disaggregation. They therefore always have to be set for the input-readiness of a cell.

Disaggregation Settings

Setting Description

No Disaggregation The values for the structural component are not disaggregated. Cells that contain values aggregated at the aggregation level cannot be changed.

Disaggregate Value Entered You can change cells that contain values aggregated at the aggregation level. The newly entered value is distributed to all data records that contribute to the changed cell. The type of distribution depends on your specifications, as described below.

Disaggregate Difference You can change cells that contain values aggregated at the aggregation level. The difference between the old and the newly entered value is distributed to all data records that contribute to the changed cell. The type of distribution depends on your specifications, as described below.

Distribution Types for Disaggregation

Distribution Type Description

Equal Distribution The distribution is made evenly across all data records that contribute to the changed cell (including data records with zero values).

Analog Distribution (Self-Reference) Distribution is the same as all data records that contribute to the changed cell.

Analog Distribution (With Reference to Following Structure Element)

You can define a structure element as a reference. Distribution is the same as all data records that contribute to the corresponding cell of this referenced structure element. You can only select a structural component from the same structure as the reference for analog distribution.

More information: Performing Manual Planning and Disaggregation (Top-Down Distribution).

Input-Ready Formulas

To be able to change values for formulas (like Average Price as a quotient of Amount and Quantity), you can make formulas input ready. To do this, go to the Data part of the Planning tab page and select Input-Ready (lock-relevant) for the formula in question.

The input-ready formula becomes the carrier of a formula group. In our example, the group is made up of quotient Average Price and the two operandsAmount and Quantity. A rule needs to be defined in the form of an inverse formula for every input-ready formula operand. This rule defines how the system calculates back to this operand whenever the value for the Average Price is changed. To do this, choose Create Inverse Formulas from the context menu. By double-clicking on an inverse formula, you can call the Change Formula screen. Define the rules for the recalculation.

More information: Examples: Inverse Formula and Defining Inverse Formulas.

For more information about input-ready and inverse formulas at runtime, see Performing Manual Planning and Inverse Formulas andExamples: Inverse Formulas at Runtime.

ExampleInput-Ready Query Definition

You want to create an input-ready query for manual planning for a plan-actual comparison of revenues for a set of products. You want the plan data in a real-time InfoCube and the actual data in a standard InfoCube.

       1.      Create a MultiProvider that includes the InfoCubes for the plan and actual data.

       2.      Define an aggregation level on the MultiProvider that contains characteristic Product and key figure Revenue.

       3.      On the aggregation level, create two restricted key figures Plan Revenue and Actual Revenue. Choose characteristic 0INFOPROV and restrict it to the plan or actual InfoCube.

       4.      Add the restricted key figures to the key figure structure. Insert Product into the rows. For Plan Revenue, choose Input Ready (Relevant for Locking) for the input-readiness option. For Actual Revenue, choose Not Input Ready (Not Relevant for Locking).

       5.      In the query properties, set the flag to define whether the queries are started in display or change mode as required.

Example of an Input-Ready Query

Product Plan Revenue Actual Revenue

P01 20

P02 30

If you want to keep actual and plan data in a real-time InfoCube, you do not require a MultiProvider for the task described above. Create an aggregation level on the InfoCube and define the input-ready query for the aggregation level. In the example above, a version characteristic acts as the InfoProvider. Create restricted key figures with the plan or actual version and proceed as in the previous example.

More Information

You can find examples of how disaggregation is used in Disaggregation (Top-Down Distribution).

For examples of how to use inverse formulas, see Examples: Inverse Formulas.

 Defining Inverse Formulas Input-Ready Formula, Inverse Formula and Formula GroupThis section provides a more precise description of the definition of inverse formulas using mathematical notation.

You can find a description of how to create input-ready and inverse formulas in BEx Query Designer, see Input-Ready Query.

You can find examples of inverse formulas under Examples: Inverse Formula and in SAP Note 1236347.

To describe an inverse formula precisely, we start by defining a notation. Let.

F = F(op1, …, opn)

is a formula with the operands op1 to opn. If formula F is input ready, we call it the carrier of a formula group. By definition, the formula group consists of the operands op1 to opn and the formula F.

For input-ready formulas, inverse formulas and formula groups, the following rules apply and are checked in Query Designer or when the query is generated by the system:

FG1: The following objects can be used as operands opi, i = 1, …, n for an input-ready formula F :

       1.      Basic or restricted key figures

       2.      Constants or ‘reporting’ formulas. These are formulas that do not change if a manual change is made during a server roundtrip

       3.      Carrier of other formula group G, where F ≠ G and G are not %GT (percentage of total).

FG 2 If the operand opi is input ready, you have to define an inverse formula in Query Designer that calculates opi from the following operands: F, op1, …, op(i-1), op(i+1), …, opn.

FG 3 All elements in the formula group must be either in the key figure structure or in exception cells. The latter only applies for queries with two structures.

Exception: %GT (“Percentage of Grand Total”)

If you want to calculate the percentage of the grand total, choose formula F= %GT. Only one operand is allowed in this case. This operand must be a basic key figure or a restricted key figure with disaggregation activated. You do not need to define an inverse formula.

Comments

●      If you choose Create Inverse Formulas in the context menu of an input-ready formula in Query Designer, the system checks which operands inverse formulas need to be created for and creates a list of them. By double-clicking on an inverse formula, you can call the Change Formulascreen. Under Available Operands, the system displays a list of all operands allowed for converting the formula.

●      The inverse formula for an input-ready operand of an input-ready formula is created by resolving the formula to the input-ready operand.

●      It is also possible to define input-ready formulas in a reusable structure.   All elements from the formula group then have to be in the structure.

●      In a query with input-ready formulas, the key figures must not be only in the query filter.

●      The system supports concatenation of formulas. Formulas can also have intersections and be contained in other formulas. Nesting must not have a cycle.

An input-ready or inverse formula cannot be nested if it contains a formula variable of type Replacement Path. This ensures that the system can always replace the variable with the master data attributes of a characteristic.

●      Inverse formulas are technical objects that are needed for inversion of input-ready formulas. On the Display tab, inverse formulas therefore have the settings Always Hide as the default setting. For debugging purposes, it can be useful to show these technical formulas.

Queries with Two StructuresTo provide a precise description of how to use formulas in queries with two structures, we start by defining a notation.

Let a query contain two structures, X and Y:

X contains the element X1, …, Xm and is displayed in the columns.

y contains the element Y1, …, Yn and is displayed in the rows. Y contains the key figures.

The intersection of two structural components Yi and Xk are cells, denoted by Yi/Xk = cik. However, the system ignores these values. In the cell editor in Query Designer, you can define these cells explicitly as exceptional cells. Exceptional cells can be of type Cell Reference, Selection or Formula.

The table below shows cells that are created when the two structures X and Y are used:

Y/X X1 … Xi … Xm

Y1 C11 C1j C1m

…

Yi Ci1 Cij Cim

…

Yn Cn1 Cni Cnm

Let Yn = F = F(Y1, …, Yk) is the carrier of the formula group, meaning that k < n and Yn is and input-ready formula. Operands Y1, …, Yk have one of the types names just mentioned under rule FG1. As the notation shows, the input-ready operands all have to be contained in row structure Y. This gives us the first rule:

C1: If a query contains two structures and no exceptional cells, input-ready formulas and inverse formulas can only be defined in one structure, meaning that all input-ready formulas and inverse formulas have to be contained in the key figure structure.

Rule C1 is a paraphrase of rule FG3.

The actual formulas to be calculated in the cells in row Yn for column Xj in the table above can be obtained by replacing the operands Y1 … Yk  with the corresponding cells c1j …ckj. The same applies for inverse formulas.

Example

Let n = 3 and Y3 = Y2 / Y1, where Y3 is Average Price, Y2 is Sales and Y1 is Quantity.. Let m = 3 and X1, X2 be of type Selection, containing restrictions by characteristic Process Type  such as Sales Order and Billing Data in a Profitability Analysis scenario. X3 contains the formula X3 = X1 + X2.

Y/X X1 X2 X3 = X1 + X2

Y1 C11 C12 C13 = C11 + C12

Y2 C21 C22 C23 = C21 + C22

Yn C31 = C21 / C11 C32 = C21 / C12 1.  C33 = C13 / C23

2.  C33 = C31 + C32

As this example shows, we have to define whether intersections between input-ready formulas and reporting formulas can be input ready, and whether inverse formulas can be calculated there.

Using a more general notation, let Xm be a formula. A rule of precedence needs to be defined here for the intersections Yn = F and Xm. If a rule is not defined, the system takes the structure element that was saved most recently. On the Advanced tab for the structure element Yn or Xm, you can define whether the system takes this formula or the formula from the other structure for the calculation.

Yn is an input-ready formula however, and inverse formulas exist for the input-ready operands Y1…Yk.  As shown in the example, it makes no difference whether the system calculates the formula from Yn or from Xm at the intersection of Yn and Xm. As Xm is a reporting formula, however, and has no inversion, inversion is not possible here. This gives us the second rule:

C2: The intersection of an input-ready formula and a non-input ready formula results in a non-input ready cell. This does not depend on the formula precedence settings for the input-ready formula or the formula from the other structure. The system therefore does not use any inverse formulas for these intersections.

No exception cells were used in the cases shown above. We now want to describe what happens if exception cells cij are used in F = F(c1j… ckj) are used, with the meaning of the variables as follows:

i = 1, …, k are the indexes of the operands for input-ready formula F that is in row structure Y.

j is the index of a structure element in column structure X.

C3: If F is an input-ready formula in key figure structure Y, and Yi is an operand of formula F in structure Y, exception cells can be defined for the intersections Yi/Xj of Yi and Xj according to the following rules, so that the input-ready formulas cannot be reset:

       1.      If Yi is not input ready, exception cell cij can be either a non-input ready selection or a non-input ready formula

       2.      If Yi is an input-ready formula (or nested input ready formulas), rule 1 (above) is applied to the operands of Yi. This is possible because the operands of Yi are also contained in key figure structure Y (see rule FG3).

With regard to rule FG3 there is another case:

C 4 If there is no input-ready formula in the key figure structure, an input-ready formula F can only be defined in an exception call. All operands of this formula then also have to be exception cells. Rules FG 1, FG 2, and FG 3 then also apply for formula F if the following replacements are made:

       1.      Basic or restricted key figure is to be replaced by an exception cell or cell reference of type Selection

       2.      Non-input ready formula is to be replaced by exception cell or cell reference of type (non-input ready) formula

Comments

●      The settings made for input-ready calculated key figures in Query Designer can be overwritten by other settings at runtime. At runtime, input readiness for calculated key figures is inherited from the operands in the carrier of the formula group. If all operands in an input ready formula arenot input ready for example, this means that the formula cannot be input ready either.

●      A formula as carrier of a formula group does not have its own disaggregation setting. If values for input ready formulas are changed, the system always calculates back the underlying basic or restricted key figures. Note that the latter might actually have disaggregation settings.. The disaggregation behavior of input-ready key figures is therefore implicitly defined by the basic key figures in the formula definition.

You are advised to avoid using nested formula groups if possible, as the end user will probably find it difficult to understand the calculation order.

Note that that system rounds up values at runtime when calculating input-ready and inverse formulas. The display settings do not affect this. This is always performed in accordance with the maximum precision specified by the relevant fields on the database.

Special Formula Group for the %GT Percent FunctionThe %GT percentage function (percentage of grand total) is a special formula group that no inverse formulas have to be defined for. If formula %GT(op) is used, operand op must be input ready, and either a basic or restricted key figure with disaggregation activated. Input-ready formulas containing the %GT percentage function must not be nested with one another.

Calculation Mode and Formula PriorityThe calculation mode defines how the system should start calculating inverse formulas. You can set the calculation mode in BEx Query Designer in the query properties on the Planning tab page. The following options are available:

Asymmetrical and Symmetrical Calculation Mode

Calculate Inverse Formulas Description

The flag is not set Initial calculation mode: This is the default setting. At query runtime, the system calculates inverse formulas if at least one value in an input-ready formula has been fixed or changed manually.

The flag is set Symmetrical calculation mode: At query runtime, the system calculates inverse formulas if at least one element in an input-ready formula has been fixed or changed manually.

Depending on the calculation mode chosen, you can set the formula priority for all inverse formulas in an input-ready formula as follows:

Formula Priority

Calculation Mode Description

Initial Calculation Mode Under the input-ready formula, you can find all inverse formulas that have been created for the input-ready operands of the carrier formula. The order in which the inverse formulas in this list are processed is determined by the formula priority. The highest element has the highest priority.

Symmetrical Calculation Mode Under the input-ready formula, you can find all inverse formulas that have been created for the input-ready operands of the carrier formula, together with the carrier formula. The order in which the inverse formulas in this list are processed is determined by the formula priority. The highest element has the highest priority. Unlike in initial calculation mode, where the carrier formula always has the highest priority, this means that the carrier formula can have any priority, even the lowest.

If the system calculates a formula group at runtime, and neither manual entries nor fixed cells nor previous calculations clearly indicate the order in which the inverse formulas should be calculated, the system first calculates the inverse formula with the highest priority.

Note for CalculationThe Note for Calculation is a property of the formula group. If you use the same operands in various input-ready formulas, the order in which the formula groups are supposed to be processed might not be obvious. You can avoid this problem by setting the priority for the formula group by entering integers in the Note for Calculation field. The lower the value entered here, the higher the formula group's priority. The same value can be entered for multiple formula groups. The values entered for various priorities do not necessarily have to be consecutive numbers.

The Note for Calculation should be understood as a relative setting rather than an absolute one. How this setting defines the order in which the formula groups are processed also depends on the context, for example on the changed, fixed or calculated cell values. Normally, it is not necessary to set the priority of the formula group in Note for Calculation.

  Example: Inverse Formula  This document contains a few simple examples to show how the system calculates values in accordance with the inverse formulas defines for an input-ready formula in BEx Query Designer 

You can find the procedure for creating input-ready and inverse formulas in BEx Query Designer under Input-Ready Query. For a description including mathematical notation and detailed rules, see Defining Inverse Formulas. More information: SAP Note 1236347.

Example 1: Average Price

The first scenario is as follows: You want to plan with the following key figures: Quantity, Sales and Average Price. Key figure Average Price is calculated as follows:

‘Average price’ = NDIV0( ‘Sales’ / ‘Quantity’ )

Data function NDIV0 is used here to avoid division by 0 errors.

As key figure Average Price is a calculated key figure and should be input-ready, the system needs rules that describe how a change to the value of the average price is calculated back to either quantity or sales. These rules are defined using inverse formulas. The system needs an inverse formula for every operand in input-ready formula Average Price.

Let both operands, Quantity and Sales, be input-ready key figures. If this is the case, you need to define the following inverse formulas:

‘Sales’ = ‘Average price’ * ‘Sales Quantity’

and

‘Sales Quantity’’ = NDIV0( ‘Sales’ / ‘Average Price’ )

If only the value for the average price is changed, it is not clear at first whether the system should calculate back to Quantity or Sales. The system will then take the inverse formula with the highest priority. The priority of the formula is determined by the order of the inverse formulas in the formula group. The formula with the highest priority is at the top of the list of inverse formulas.

Example 2 - Percentage 

The second scenario is as follows: You want to plan with the following key figures: Amount and Percentage of the grand total. The percentage should also be input ready.

As with example one, this case can also be modeled with an input-ready formula and the definition of an inverse formula. You can also use the ‘%GT’ function (percentage of grand total) with a number of additional functions:

If you use the %GT function, you do not need to create an inverse formula, as it is already defined in the system.

The total for the operand of %GT is fixed automatically during calculation of the inverse formula. This ensures that the changed % value is still the same after the server roundtrip.

The %GT function is useful if the underlying basic key figure uses one of the supported disaggregation

settings. For more information about disaggregation settings, see Input-Ready Query.

In Query Designer, define the following formula:

‘% Percentage’ = %GT ‘Amount’

Choose Input-Ready. You do not need to create an inverse formula. 

Example 3: Symmetrical Calculation Mode and Average Price  

Formulas are always calculated when the OLAP Processor calculates a new result.

If the value of an input-ready formula is changed, the value of the calculated key figure Average Price for example, the system has to calculate the inverse formula. In this case, the system calculates either the formula for Sales or the formula for Quantity.

If the value of an operand in an input-ready formula is changed however, key figure Sales for example, the system does not calculate inverse formulas. The system calculates a new average price when the result is updated by the OLAP Processor.

There are certain scenarios where a different system reaction is required. If the value of an operand such as key figure Sales is changed, the value forAverage Price should be retained, and an inverse calculation performed on key figure Quantity. You can achieve this using symmetrical calculation mode.

To activate symmetrical calculation mode, select Calculation of Inverse Formulas in the Query properties on the Planning tab page in BEx Query Designer.

This mode is particularly useful for depicting the required business logic in complex scenarios that work with a large number of nested input-ready formulas. In this kind of scenario, it can be useful to be able to explicitly set the order that the formula groups will be calculated in. The Note for Calculation is used for this purpose.

Once you have activated symmetrical calculation mode, you can set the formula priority for every input-ready operand, including the input-ready formulas that use them. You do this in the query component properties on the Planning tab page. In the Note for Calculation field, you can also define the formula group’s priority in relation to other formula groups.

 Form-Based Planning  

UseWith characteristic relationships for real-time InfoCubes, you can model valid combinations of characteristic values. The system uses this information to suggest combinations of characteristics in input-ready queries for which values have not yet been saved. To ensure that the generated combinations of characteristics are valid, the system uses the values that are currently being used in the filter of the query and the relations from the characteristic relationships.

PrerequisitesYou have modeled characteristics relationships (see Characteristic Relationships).

You have defined an input-ready query (see Input-Ready Query).

FeaturesIn the BEx Query Designer, in the Properties of a characteristic, you can set the Access Type for Result Values. You have the following options:

●     Posted values

●     Characteristic relationships

●     Master data

The first option is the default setting. If you want the system to suggest combinations for planning, choose the Characteristic Relationships option.

For more information, see  Characteristic Properties.

ActivitiesTo generate proposed combinations, choose Characteristic Relationships. If a characteristic should not be included in a relation, the system refers back to the master data to generate the valid combinations. This is also the case if you choose the Characteristic Relationships option.

However, if you choose the Master Data option for an input-ready query, the system first generates all the possible combinations that are restricted by time characteristics and navigation attributes only. For each cell, the system checks whether the relevant characteristic relationships produce a valid combination for the cell; if this is the case, the cell is input ready.

Note that if you choose the Characteristic Relationships or Master Data option, a considerable number of combinations can easily be generated. For this reason, the filter restrictions for these characteristics should be accordingly restrictive. You can specify a maximum number of combinations for characteristic relationships for each real-time InfoCube.

ExampleIn sales planning you are planning (rolling) quantities for the periods of a predefined time interval (one year, for example). The products are arranged in aProduct Hierarchy that you have modeled using the characteristic relationships. Product belongs to a Product Group which in turn belongs to a Product Line. You use these characteristics in the rows of an input-ready query. In the columns, you use the key figure Sales Quantity and the time characteristic Fiscal Year/Period in the drilldown. Under Access Type for Result Values, you choose the Characteristic Relationships option for these four characteristics. The system generates the valid combinations in the rows; for the characteristic Period/Year, the system determines all the valid periods from the master data that is contained in the filter. It generates the corresponding number of combinations in the key figure structure with the values for the periods.

The following figure provides an example of this form-based planning:

Note that with fiscal year variants, the special periods are valid master data. If you use the fiscal year variant Q4, the system suggests the special periods 13.2006, … 16.2006 and period 0.2007 for the selection 1.2006 - 12.2007. If you do not want to use these values in planning, you have to remove them from the selection.

  Implementing Planning Function Types 

UsePlanning function types are procedures that can be parametrized and that change transaction data within BI Integrated Planning. The system offers you a number of default planning function types (such as copy, delete, repost, revaluate, distribute by reference data or by key, unit and currency translation or FOX formula).

You can also implement customer-specific planning function types in order to implement specific procedures and apply them to transaction data. Each planning function type comprises

●      a definition part (metadata) that is created and changed in a transaction (RSPLF1),

●      an ABAP-OO class in which the actual procedure is programmed. The class name is part of the definition part.

IntegrationWith regard to transport, Business Content and activation, planning function types behave like other metadata objects of the BI system.

The active planning function types are visible in the Planning Modeler and can be used to create and execute planning functions.

FeaturesIn the maintenance transaction for planning function types, you can display, change and create customer-specific planning function types.

ActivitiesCreating Planning Function Types

       1.      To get to the maintenance transaction for planning function types, on the BI Integrated Planning screen in the Administration and Developmentscreen area, choose   Maintain Function Types. The Edit Planning Function Type screen appears.

       2.      Enter a technical name for the planning function type.

       3.      Choose   Create. The screen for creating a planning function type appears.

       4.      Enter a description for the planning function type and make the required settings on the Properties and Parameters tab pages.

Tab Page: Properties

Screen Area Description

Implementation Enter the name of the ABAP class that implements the procedure. The ABAP class has to implement one of the two interfaces:

●      IF_RSPLFA_SRVTYPE_IMP_EXEC

●      IF_RSPLFA_SRVTYPE_IMP_EXEC_REF

The latter interface is relevant when you need reference data for your procedure. The implementation of methods of the specified interfaces is optional with the exception of the method EXECUTE.

In addition, the class can implement specific check methods that are executed at runtime. The interface IF_RSPLFA_SRVTYPE_IMP_CHECK serves this purpose.

You can select the following indicators:

●      Reference Data: If the indicator is selected, reference data is required when you execute the planning function.

●      Without Blocks: If the indicator is selected, the transaction data is processed without creating blocks; that is, all characteristic values in the transaction data can be changed.

In this case you cannot create conditions since the selection table for each condition may only contain characteristics that can also be used to create blocks.

●      Process Empty Records: If the indicator is not selected, all the empty records are ignored during processing.

Characteristic Usage Interface Display

Using Web Dynpro and development components, you can create your own user interface instead of the standard user interface for characteristic usage. You can also select the following indicators:

●      Hide Column of Characteristics to be Changed: This indicator is meaningful if you want to perform processing without blocks or if the characteristics to be changed are the result of other settings.

●      Display First When Creating: If this indicator is selected, the user interface of the characteristic usage is first displayed when a planning function is created; otherwise the user interface with the parameter values is displayed.

Parameter Interface By using Web Dynpro and development components, you can create your own user interface instead of the standard user interface for parameters.

Tab Page: Parameters

Create the required parameters using Create Parameters or Create Components in the context menu of an object in the parameter hierarchy. You can change the details of existing parameters by

choosing Properties in the context menu. With   and  , you can change the sequence of the parameters. The sequence of the parameters is taken into account when you create a planning function for this planning function type.

With the Parameter is Tabular indicator you can mark a parameter as a table; it will then behave like an internal table. In this table, each row of the tabular parameter has the properties that correspond to the selected parameter type. The indicator is valid for all parameter types (in the context menu with Properties) with the exception of Key Figure Selection or if parameters are used as components of a structure parameter.

Parameter Type Description

Elementary

(Elementary Parameter)

The value of an elementary parameter is the value of a specific InfoObject. This means that every elementary parameter is based on an InfoObject and thus inherits its technical properties. If the InfoObject is a characteristic, the system automatically checks the validity of a value entered by the user based on the master data.

InfoObject of the InfoProvider The parameter can include the name of an InfoObject from the current InfoProvider (aggregation level). You can define the valid InfoObjects with the selection Restrict. InfoObject:

●      Key Figures Only are valid.

●      All Characteristics

Only characteristics are valid, but these have no restrictions.

●      Block Characteristics Only

Block characteristics are used to group the transaction data (see Without Blocks above)

●      To-Be-Changed Characteristics Only

Only characteristics that are changed by a planning function are valid. Block characteristics are therefore not valid.

●      Condition Characteristics Only

Only characteristics that are used in the planning function to define the condition are valid.

Data Selection The selection criteria for multiple characteristics can be included in data selection parameters as they are needed to define the filters. This is a specific selection table. You define the characteristics that are valid for the data selection  with Chars. Restriction:

●      All Characteristics

All characteristics of the InfoProvider are valid.

●      Block Characteristics Only

Block characteristics are used to group the transaction data (see Without Blocks above)

●      To-Be-Changed Characteristics Only

Only characteristics that are changed by a planning function are valid. Block characteristics are therefore not valid.

●      Condition Characteristics Only

Only characteristics that are used in the planning function to define the condition are valid.

Structure

(Structure Parameter)

With a structure parameter you can declare other parameters as components of the structure parameter and thus combine them into a structure. Parameters of type Elementary, InfoObject of the InfoProvider and Data Selection are valid as components.

To declare a parameter as a component, choose either Create Component in the context menu of a structure parameter or its components, or Properties  →  Structure Parameter in the context menu of another parameter.

Key Figure Selection This parameter type selects the key figures to be processed. It is therefore a special case of the type InfoObject of the InfoProvider.

ExampleThe planning function types delivered by SAP are based on the same technical concept as the customer's own planning function types and can thus be viewed in the maintenance of the planning function types.

The function type Delete (0RSPL_DELETE) is a simple example. There is only one parameter (KYFSEL) for selection of the key figures to be deleted. In the associated ABAP class, the interfaces IF_RSPLFA_SRVTYPE_IMP_CHECK and IF_RSPLFA_SRVTYPE_IMP_EXEC are implemented.

 Creation of Planning Applications 

PurposePlanning applications are BI applications that are based on a planning model. Power users combine the objects of the planning model into an interactive planning application which allows data to be entered and changed automatically or manually by users.

Planning model objects include:

●     InfoProviders that contain data (see InfoProviders)

●     Aggregation levels as InfoProviders which provide a set of data with a particular level of granularity for data entry and change (see Aggregation Levels)

●     Input-ready queries which allow you to make manual entries for the aggregation level (see Input-Ready Queries)

●     Planning functions which allow automated changes to be made to data in the aggregation level and therefore model a part of the data flow (seePlanning Functions).

In addition, planning sequences can belong to the planning model (see Planning Sequences).

Tools are available for creating planning scenarios. These tools are also used in reporting scenarios.

●     For Excel-based planning applications: BEx Analyzer

●     For Web-based planning applications: BEx Web Application Designer

PrerequisitesYou have created the necessary planning model objects.

You have installed the frontend.

ExampleIn order to illustrate the basic procedure, the following example will show you how to create an Excel-based planning application and a Web-based planning application on the basis of a simple planning model.

The underlying planning model consists of the following objects:

●     A real-time-enabled InfoCube Plan_IC containing the planned sales data for next year

●     A standard InfoCube Actual_IC containing the sales data for the previous year

●     A MultiProvider Plan_Actual_MP containing the two InfoCubes

●     An aggregation level Plan_Actual_Aggr for MultiProvider Plan_Actual_MP

●     An input-ready query Plan_Query01 which displays the actual and plan data and allows plan data to be entered manually.

The two InfoCubes contain the same characteristics and have at least one common key figure; the only difference is the key figure Year. One of the characteristics is Country. This has to be included in the query.

The following graphic shows how the objects in the planning model are related: 

The planning application contains at least one of the following elements:

●     A planning function for copying the data from the InfoCube containing actual data into the InfoCube containing plan data PF_Copy

●     A selection list (dropdown box) that allows you to navigate in the query

●     A planning function for revaluating plan data PF_Revaluate01 (revaluate by %) or PF_Revaluate02 (with a fixed percentage), where the selections in the selection list determine which data is to be revaluated

●     A planning function for saving plan data

●      

See also:

Creating Planning Applications in BEx Analyzer

Creating Planning Applications in the BEx Web Application Designer

  Creating Planning Applications in the BEx Analyzer 

ProcedureThe following example shows how you create a workbook with a title, table, selection list, and special pushbuttons (for functions such as copy, revaluate by %, delete, and save).

       1.      Open the BEx Analyzer.

       2.      Check that you have the necessary security settings. Choose Tools → Macro → Security. Switch to the Trusted Publishers tab page and set the indicator for Trust access to Visual Basic Project.

You only have to set this indicator when you are creating the planning function. You can deselect the Trust access to Visual Basic Project indicator afterwards.

       3.      Choose   New to create a new workbook.

       4.      To enter the title, navigate to the relevant cell in the workbook, enter the text, and assign a suitable font size.

In this example, the text Sales Planning is entered in cell B2 and given font size 18.

       5.      To start designing the workbook, choose   to switch to design mode. The SAP Logon dialog box appears.

       6.      Log on to the BI server that you want to use.

       7.      To display the results of the query with the actual and plan data and enter plan data manually,

navigate to the appropriate cell in the workbook and choose   to insert an analysis grid.

In this example, we navigate to cell B6 and insert the analysis grid here. For more

information about this design item, see  Analysis Grid.

       8.      In the context menu of the analysis grid, choose Properties. The Analysis Grid Properties dialog box appears.

       9.      On the General tab page, create a new data provider. The Create Data Provider dialog box appears. In the Data Provider field, the system displays the name that is currently assigned to the data provider.

In this example, we create data provider DP_01. For more information, see  Configuring Data Provider.

   10.      To specify the start view of the data provider, choose   Query/Query View. The Open dialog box appears.

   11.      Select the required query or query view and choose Open. The system inserts the name of the InfoProvider on which the query or query view is based into the InfoCube field.

In this example, we assign query Plan_Query01 to data provider DP_01. The underlying aggregation level is Plan_Actual_Aggr.

   12.      Since you want to save the navigational state after navigation steps have been performed in the BEx Analyzer and plan data has been entered, deselect the Restore Initial Query View on Refresh indicator.

   13.      When you have configured your data provider in this way, choose OK. The Analysis Grid Properties dialog box appears again.

   14.      Make sure that the Apply Formatting and Allow Navigation indicators are set and choose OK.

   15.      To select the values of a dimension in the query as a filter, navigate to the appropriate cell in the

workbook and choose   to insert a dropdown box.

In this example, we navigate to cell B4 and insert the dropdown box here. For more

information about this design item, see  Dropdown Box.

   16.      In the context menu of the dropdown box, choose Properties. The Dropdown Box Properties dialog box appears.

   17.      On the General tab page, select the configured data provider (DP_01 in this example), and set the Display Label indicator.

   18.      On the Dimensions tab page, select the dimensions for which you want to be able to select values in the dropdown box. Make sure that thePosted Values (Q) entry is selected in the Read Mode field so that only posted values are displayed.

In this example, we select the dimension Country.

   19.      For each special function that you want to include, choose   to insert a design item of type Button.

In this example, we add pushbuttons in cells B18, B20; B22 and D22. For more

information about this design item, see  Button.

   20.      In the context menu of the button, choose Properties. The first dialog box for the command wizard appears.

5.                             a.      Select Planning-Specific Command, and choose Next ->.6.                             b.      Choose the required planning-specific command:

4.                                                   i.       Select Execute Planning Function.5.                                                 ii.       Select the required planning function and data provider DP_01 as the

filter.

■       Planning function: PF_Copy ■       Planning function: PF_Revaluate01. Since this planning function contains the

variable OF_REVALUATION_FACTOR, the system displays this in the lower area of the dialog box. Input help is available for selecting the values.

■       Planning function: PF_Delete

6.                                                iii.       Choose Finish. The Button Properties dialog box appears.

7.                             c.      Select the Save option, and then choose Finish. The Button Properties dialog box appears.

For more information, see Command Wizard.

If you do not use the Command Wizard, the Button Propertiesdialog box appears. You can then enter a pushbutton text and static parameters for each function button; the options are outlined in the following example:

Special Function Buttons

Button Text/ Command Range

Static Parameters: Name Static Parameters: Value

Copy CMD EXECUTE_PLANNING_FUNCTION

PLANNING_FUNCTION_NAME PF_Copy

DATA_PROVIDER_FILTER DP_01

Revaluate by %

Command range: $A$30:$C$30

VAR_NAME OF_REVALUATION_FACTOR

DATA_PROVIDER_FILTER DP_01

PLANNING_FUNCTION_NAME PF_Revaluate01

CMD EXECUTE_PLANNING_FUNCTION

Delete PLANNING_FUNCTION_NAME PF_Delete

DATA_PROVIDER_FILTER DP_01

CMD EXECUTE_PLANNING_FUNCTION

Save CMD SAVE_AREA

   21.      Since the workbook contains all the necessary elements, you can exit design mode. You do this

by choosing  .

   22.      Create the command range for the function Revaluate by %.

In this example, we navigate to cell A30 and insert the text VAR_VALUE. Then we navigate to cell B30 and enter "0". In cell C30 we enter "=C20".

   23.      If you want to see a plain background instead of the table layout, select all rows and columns

and choose   Fill Color.

In this example, we choose White.

If you only want to hide the gridlines, you can change this setting. Choose Tools → Options → View; under the Window options group header, deselect the Gridlines indicator.

   24.      Choose   to save your workbook. More information:  Saving.

ResultYou have an input-ready query in the analysis grid in which you can enter plan data manually. You can use the planning functions you have created to calculate plan data. The data set is determined by the navigational state of data provider DP_01. Restrictions on structure elements (restricted key figures, for example) are not taken into consideration.

Test your workbook by entering, for example, values in cell C20 as revaluation factors.

For more information about the context menu of the cells in the analysis grid, see Functions for Manual Planning.

 Command Wizard 

UseThe Command Wizard provides helps when using the Button design item to create pushbuttons in BEx Analyzer. You can use the wizard for the following command options:

Workbook-Specific Command

Wizard Option  Static Parameters: Name  Static Parameters: Value

Process Variables CMD SHOW_VARIABLE_SCREEN

Display Personalized Variables PERSONALIZED X

Toggle Drag and Drop CMD TOGGLE_DRAGDROP

Disable Drag and Drop CMD DISABLE_DRAGDROP

Allow Drag and Drop CMD ALLOW_DRAGDROP

●      With the Process Variables command you can call the dialog box for selecting variable values and change them. You can also display personalized variables.

●      With the drag & drop commands you can activate or deactivate this function, or toggle between the active and non-active status.

Planning-Specific Command

Wizard Option  Static Parameters: Name  Static Parameters: Value

Save CMD SAVE_AREA

Transfer Values CMD VALUE_CHECK

Execute Planning Function CMD EXECUTE_PLANNING_FUNCTION

Planning: Execute Sequence CMD EXEC_PLANNING_SEQUENCE

Reset Area CMD RESET_AREA

Refresh CMD REFRESH_AREA

●      Using the Save command, you can persistently store changes to transaction data. If the check is successful, the changed data is written to the InfoCube or InfoCubes.

●      Using the Transfer Values command, you can copy changed data from an input-ready query to the planning buffer. The entries are checked when this is done. If the check is successful, the data is copied across.

●      Using the Execute Planning Function command, you can trigger the execution of a planning function. A dialog box appears where you can select the planning function and data provider. You can either select a planning function, or create or edit one by branching to the planning modeler.

If the planning function contains variables, the system displays these in the lower area of the dialog box. Input help is available for selecting the values.

By selecting a data provider, you specify which data provider (with type filter or query view) the selection for all characteristics is to be made from.

By selecting Process Changed Data (Parameter PROCESS_CHANGED_DATA) you can define that only data changed by the user in the current session since the last save will be processed (see Processing Changed Data in Planning Functions). If you choose this option, you can specify which aggregation level to analyze as a filter to define the changed records.

When you choose Finish, the system copies the values for PLANNING_FUNCTION_NAME and DATA_PROVIDER_FILTER to the button properties.

●      Using the Execute Planning Sequence command, you can trigger the execution of a planning sequence. A dialog box for selecting the planning sequence appears. You can either select a planning sequence or create or edit one by calling Planning Modeler.

If the planning sequence contains variables, the system displays these in the lower area of the dialog box. Input help is available for selecting the values.

As with the Execute Planning Function command, selecting Process Changed Data (parameter PROCESS_CHANGED_DATA) allows you to define that only data changed by the user in the current session since the last save will be processed (see Processing Changed Data inPlanning Functions). If you choose this option, you can specify which aggregation level to analyze as a filter to define the changed records. After the planning sequence has been executed, all subsequently changed data counts as having been completed by all participating planning functions (the steps in this sequence). This means for example that the data created by the last step of a sequence does not count as changed if the first step is executed again. If a button that just starts a planning sequence, “Check the Changed Data" for example, is executed several times in quick succession, the system does not process any data for the repeat executions.

When you choose Finish, the system copies the values for PLANNING_SEQUENCE_NAME to the button properties.

●      With the Reset Area command you can reset all entered planning data that you have not yet saved.

●      With the Refresh command you can request current data from the BI system and thus refresh the data in the workbook. You can also use this command to refresh data in workbooks that are not specific to planning.

You can also specify variables for the variable values contained in the function or sequence for the commands Execute a Planning Function andExecute a Planning Sequence. More information: Transferring Variable Values.

By choosing OK in the Button Properties dialog box, you complete the editing process for the pushbutton. If required, you can add additional functions to the button properties by choosing Create. This allows you to specify that the execution of a planning function is to be followed by the execution of a planning sequence.

Data-Provider-Specific Command

Select the required data provider. You can then make the following settings:

Wizard Option Static Parameters: Name Static Parameters: Value

Edit CMD SET_INPUT_MODE

Display CMD SET_INPUT_MODE

Filter Command CMD

Assign Query/Query View CMD RESET_DATA_PROVIDER

●      Using the Edit and Display commands, you can specify the mode for data entry. 

○       If you select the Edit option, you can use this pushbutton to switch to change mode for an input-ready data provider.

○       If you select the Display option, you can use this pushbutton to switch to display mode for an input-ready data provider.

●      If you select the Filter Command option, a dialog box for selecting the dimension appears, assuming this is supported by the selected data provider.

●      If you choose the Assign Query/Query View option and select the required query, the system copies the values for INFOCUBE and QUERY to the button properties.

Transferring Variable Values 

UseYou need not only use the static parameters CMD, DATA_PROVIDER_FILTER, PLANNING_FUNCTION_NAME and PLANNING_SEQUENCE_NAME for the Execute Planning Function or Execute Planning Sequence commands, but also transfer variable values for the variables contained in the planning function or planning sequence to the command.

FeaturesThe variables available are listed below.

Characteristic Value Variables

Characteristic Value Variables: Parameter Variables or Variables for Multiple Single Values

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_VALUE_EXT_x Characteristic values in external format

Key for characteristic value in external display

Characteristic Value Variables: Interval Variables

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_VALUE_LOW_EXT_x “From” characteristic value in external display

Key for characteristic value in external display

VAR_VALUE_HIGH_EXT_x “To” characteristic value in external display

Key for characteristic value in external display

Characteristic Value Variables: Selection Option Variables

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_OPERATOR_x Operator

'EQ' = Individual value

'BT' = Interval

'LT' = Less than

'LE' = Less than or equal to

'GT' = Greater than

'GE' = Greater than or equal to

VAR_VALUE_LOW_EXT_x “From” characteristic value in external display

Key for characteristic value in external display

VAR_VALUE_HIGH_EXT_x “To” characteristic value in external display

Key for characteristic value in external display

This value must only be specified with VAR_OPERATOR='BT'.

VAR_SIGN_x Row properties

●      'I' found values are added,

●      'E' found values are removed.

Characteristic Value Variables: Variables for Precalculated Value Sets

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_VALUE_EXT_x Name of value set

Variables for Single or Multiple Hierarchy Nodes

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_VALUE_EXT_x Node key in external display

Key for hierarchy node

VAR_NODE_IOBJNM_x Node characteristic name

With characteristic nodes and text nodes, you have to specify the characteristic name0HIER_NODE.

Hierarchy, Formula, and Text Variables

Parameter Description

VAR_NAME_x Technical name of the variable

VAR_VALUE_EXT_x Hierarchy name, formula value, text

The following is valid for the above entries in the tables:

●        Placeholder for the parameter index is 'x'. All single values (value rows) are numbered sequentially using the parameter index, irrespective of whether they represent multiple single values for a variables or two single values for two different variables.

●        You can also enter the internal value as parameter value rather than "EXT".

ExampleThe following variables are used in the subsequent examples, all are defined by the 0CALMONTH characteristic:

●      MY_VAR_MULT_SINGLE (Type: Variable for multiple single values)

●      MY_VAR_SO_FROM (Type: Selection option variable)

●      MY_VAR_SO_TO (Type: Selection option variable)

●      MY_VAR_NODE (Type: Variable for multiple hierarchy nodes)

The command configuration occurs as usual using one or multiple sequences of the type Name – Index – Value.

Note that the index element in the configuration sequence does not correspond to the parameter index stated above. There can be multiple commands on a design item Button, for example, two planning functions with variables. The index element determines the execution sequence of commands.

For more information, see  Button.

Example: Transferring a Single Value to MY_VAR_MULT_SINGLE

Name Index Value

VAR_NAME_1 1 MY_VAR_MULT_SINGLE

VAR_VALUE_LOW_EXT_1 1 03.2003

The following example shows the transfer of a single value to the selection option variable MY_VAR_SO_FROM as well as the transfer of single values and an interval to the selection option variable MY_VAR_SO_TO:

Example: Transfer to MY_VAR_SO_FROM and MY_VAR_SO_TO

Name Index Value

VAR_NAME_1 1 MY_VAR_SO_FROM

VAR_VALUE_LOW_EXT_1 1 01.2003

VAR_SIGN_1 1 I

VAR_OPERATOR_1 1 EQ

VAR_NAME_2 1 MY_VAR_SO_TO

VAR_VALUE_LOW_EXT_2 1 02.2003

VAR_SIGN_2 1 I

VAR_OPERATOR_2 1 EQ

VAR_NAME_3 1 MY_VAR_SO_TO

VAR_VALUE_LOW_EXT_3 1 04.2003

VAR_SIGN_3 1 I

VAR_OPERATOR_3 1 BT

VAR_VALUE_HIGH_EXT_3 1 06.2003

The following example shows the transfer of the scroll 02.2003 (February 2003) and the node 3.2003 (3rd quarter 2003) from a hierarchy on0CALMONTH to MY_VAR_NODE. The node is defined on the

external characteristic 0CALQUARTER.

Example: Transfer to MY_VAR_NODE

Name Index Value

VAR_NAME_1 1 MY_VAR_NODE

VAR_VALUE_EXT_1 1 02.2003

VAR_NODE_IOBJNM_1 1

VAR_NAME_2 1 MY_VAR_NODE

VAR_VALUE_EXT_2 1 3.2003

VAR_NODE_IOBJNM_2 1 0CALQUARTER

Creating Planning Applications in the BEx Web Application Designer 

UseThe following simple example shows how to create a Web application with a selection list (button group), table, and special pushbuttons for functions such as copy, revaluate (with a fixed percentage), and save.

PrerequisitesYou have a planning model that contains aggregation level Plan_Actual_Aggr (defined on the basis of MultiProvider Plan_Actual_MP), queryPlan_Query02 (which is not input ready), a filter, and planning functions for copying PF_Copy and revaluating PF_Revaluate02.

You are familiar with the functions of the BEx Web Application Designer (see  Creating a Web

Application and  Creating Web Applications with the BEx Web Application Designer).

Procedure       1.      Open the BEx Web Application Designer.

       2.      Choose Create New Web Template.

For more information about the Web template concept, see  Web Templates.

       3.      Choose   New Data Provider to create a new data provider of type Query View Data Provider. The Maintain Data Provider dialog box appears.

For more information about the data provider concept, see  Data Providers in BI Applications.

       4.      In the Name field, the system displays the name it generated for the data provider. This is currently assigned to the data provider. You can retain this name.

       5.      In the Define Data Provider Type area, choose the Query option. Choose   Select Query. The Open dialog box appears.

       6.      Select the query you require and choose Open. In the Query field, the system inserts the name of the query.

       7.      When you have defined your data provider in this way, choose OK.

       8.      Drag and drop the required Web items onto the Layout tab page of your Web template.

In this example, we insert the following Web items:

■         Dropdown box

■         Analysis

■         Button group

More information:  Web Items

       9.      If you click a Web item or choose Properties in the context menu of a Web item, the system displays the Properties screen area.

   10.      On the Web Item Parameters tab page of the respective Web item, enter the required data in the highlighted fields.

For the Web items in this example, the following data is required:

For the dropdown box (see  Dropdown Box) under parameter Data Binding → Data Binding Type → Selection of Characteristic:

■       Data provider: DP_01 ■       Characteristic: Country

Set the indicator for the special Label parameter for the dropdown box so that the label is displayed for Country.

The system uses the data provider you create first for all additional Web items. If you have performed the activities in the order described here, the system inserts data

provider DP_01 under the Data Bindingparameter for the Analysis Web item (see Analysis).

For the button group (see  Button Group), under parameter Internal Display → List of Buttons → Caption in the Text Editing dialog box (with option Language-Independent Text), we enter a text for the required pushbuttons. We use the Command field to assign a

suitable command to each button (see  Commands). The Edit Command dialog box appears. On the All Commands tab page, selectCommands for Planning Applications and choose the required functions in accordance with the following examples:

Special Function Buttons

Button Text Command Parameter

Copy Execute planning function (simple binding) (EXEC_PLANNING_FUNCTION_SIMPLE)

Data Binding → Reference to Data Provider of Type Filter: DP_01

Command-Specific

Parameters → Planning Function: Select your copy planning function (PF_Copy in our example).

Revaluate Execute planning function (simple binding) (EXEC_PLANNING_FUNCTION_SIMPLE)

Data Binding → Reference to Data Provider of Type Filter: DP_01

Command-Specific Parameters → Planning Function: Select your revaluate planning function (PF_Revaluate02 in our example).

Save [SAVE_DATA] Data Binding: No entry necessary.

More information: Commands for Planning Applications

   11.      Choose   to save your Web template (menu path Web Template →   Save).

   12.      Choose   to execute your Web template.

ResultYou can use the planning functions you have created to copy and calculate plan data. The data set is determined by the navigational state of data provider DP_01. You can save the entire Web application by choosing the Save pushbutton.

Further InformationFor additional examples of the creation of planning applications in the BEx Web Application Designer, see:

Copying Planning Functions (with Dropdown Box Web Item)

Revaluating Planning Functions (with Analysis Web Item)

Documentation (with Analysis Web Item)

 Commands for Planning Applications 

UseUnder the commands for planning applications, you can find a summary of all commands you can use to create planning applications.

FeaturesThe following commands are available:

●     Refresh Data (REFRESH_DATA)

●     Save Changed Data (SAVE_DATA)

●     Reset Changed Data (RESET_DATA)

●     Set Data Entry Mode (SET_DATA_ENTRY_MODE)

●     Execute a Planning Function (Simple) (EXEC_PLANNING_FUNCTION_SIMPLE)

●     Execute a Planning Function (EXEC_PLANNING_FUNCTION)

●     Execute a Planning Sequence (Simple) (EXEC_PLANNING_SEQUENCE_SIMPLE)

Refresh Data 

UseUsing the Refresh Data command (REFRESH_DATA), you can copy changed data from an input-ready query to the planning buffer. The entries are checked when this is done. If the check is successful, the data is copied across.

You can undo the changes using the Reset Changed Data command.

You can save the changed data persistently using the Save Changed Data command.

Command ParametersThis command has no parameters.

Application ContextThis command is particularly useful if you see the data entered manually into an input-ready query and want to know what impact these changes have on other parts of your Web application. 

Save Changed Data 

UseUsing the Save Changed Data command (SAVE_DATA), you can save your data changes within a Web application persistently. If the check is successful, the changed data is written to the InfoProvider.

Command ParametersThis command has no parameters.

Application ContextThis command is particularly useful, for example, if you have changed data manually using an input-ready query or automatically using a planning function, and you want to save these changes. Using this command, you save all data within the entire Web application.

  Reset Changed Data 

UseUsing the Reset Changed Data command (RESET_DATA), you can undo your data changes within a Web application. This reverses unsaved data changes made manually or by planning functions or planning sequences. You cannot undo changes that you have saved persistently by choosingSave Changed Data (SAVE_DATA).

Command ParametersThis command has no parameters.

Application ContextThis command is particularly useful, for example, if you have changed data manually using an input-ready query or automatically using a planning function or planning sequence, and you want to undo these changes.

 Set Data Entry Mode 

UseUsing the Set Data Entry Mode command (SET_DATA_ENTRY_MODE), for an input-ready query, you can switch between display and change mode for a data provider.

Display mode: If a query is started in display mode, the data requested by the query is not locked for the current user.

Change mode: As soon as change mode is chosen, the system attempts to lock the data for the aggregation level for the current user. This lock attempt is rejected if the data is already locked by another user, and the data provider remains in display mode.

Command ParametersThe following information outlines the command parameters in the same sequence that they appear in the command wizard when you insert the command:

Parameter Description

Data Provided Affected (TARGET_DATA_PROVIDER_REF)

You use this parameter to specify which data provider the command is to relate to.

Active You can choose from:

On: input mode is activated

Off: input mode is deactivated

 Executing a Planning Function (Simple) 

UseUsing the Execute a Planning Function (Simple) command (EXEC_PLANNING_FUNCTION_SIMPLE), you can trigger execution of a planning function.

All characteristic selections are determined by specifying one single data provider. The type for the data provider can be Filter or Query View. If the data provider is of type Query View, only the fixed filter of the query is used to restrict the selection. Additional restrictions, such as restricted key figures, are not used. When you use this command, you should note which restrictions were defined in the filter for the query so that the planning function does not change more data than required.

If you want to individually specify for each characteristic how the selection is to be determined, use the Execute a Planning Function command.

Command ParametersThe table below lists the command parameters as they appear in the Command Wizard when you insert the command:

Parameter Description

Variables Screen You use this parameter to specify whether to display a Variables screen.

If you do not select this option, the variable screen is displayed only if no entry has been made for required variables.

Process Changed Data You use this parameter to define whether the planning function will process just the data changed by the user in the current session since the last save or process all data (see Planning Functions, Processing Changed Data). If you choose this option, you can specify which aggregation level to analyze as a filter to define the changed records.

Data Binding: Reference to Data Provider of Type Filter

You use this parameter to specify the data that the planning function is executed on. (See Sources for Characteristic Selection and Variables.)

Data Binding: Variant If the planning function uses variables, you can use this parameter to specify how they are to be filled. Using a variable variant, you therefore specify the parameterization of the planning function. (See Sources for Characteristic Selection and Variables.)

Data Binding: Variables You use this parameter to specify the values for individual variables of the planning function. If a variant is also selected, a value assigned using this parameter is given precedence. (See Sources for Characteristic Selection and Variables.)

Planning Function (PLANNING_FUNCTION) Technical name of the planning function. You use this parameter to specify which planning function will be executed.

The graphic below shows how the options in the table above can be used to parameterize a simple planning function.

Examples of using simple planning functions:

Copying Planning Functions (with Dropdown Box Web Item)

Revaluating Planning Functions (with Analysis Web Item)

 Executing a Planning Function 

UseUsing the Execute a Planning Function command (EXEC_PLANNING_FUNCTION), you can trigger the execution of a planning function. For each characteristic, you can specify how the selection will be determined.

Command ParametersThe table below lists the command parameters as they appear in the Command Wizard when you insert the command:

Parameter  Description

Variables Screen You use this parameter to specify whether to display a Variables screen. If you do not select this option, the variable screen is displayed only if no entry has been made for required variables.

Process Changed Data You use this parameter to define whether the planning function will process just the data changed by the user in the current session since the last save or process all data (see Planning Functions, Processing Changed Data). If you choose this option, you can specify which aggregation level to analyze as a filter to define the changed records.

Data Binding: Selection Bindings You use this parameter to specify the data that the planning function is executed on. (See Sources for Characteristic Selection and Variables.)

Data Binding: Variant If the planning function uses variables, you can use this parameter to specify how they are to be filled. Using a variable variant, you therefore specify the parameterization of the planning function. (See Sources for Characteristic Selection and Variables.)

Data Binding: Variables You use this parameter to specify the values for individual variables of the planning function. If a variant is also selected, a value assigned using this parameter is given precedence. (See Sources for Characteristic Selection and Variables.)

Planning Function (PLANNING_FUNCTION) Technical name of the planning function. You use this parameter to specify which planning function will be executed.

Application ContextThis command is particularly useful if you want to change data using a planning function, and the Execute a Planning Function (Simple) command is not sufficient. 

The graphic below illustrates a query as an example of this kind of modeling:

You have a query in the drilldown with characteristic Product and key figures Sales Plan and Actual

Sales. These key figures are restricted to the relevant version. Using characteristic Business Year, you filter the results for the year 2006. Using a planning function to revaluate, you want to change the sales plan data.

If you were to use the Execute a Planning Function (Simple) command in this example, you could only specify the query as a whole (or your fixed filter) for the Reference to Data Provider of Type Filter parameter. Since the selection of the restricted key figures is ignored, Version would not be restricted, and the planning function would be applied to both the plan data and the actual data.

However, if you were to use the Execute a Planning Function command in this example, you could specify a data provider for each characteristic. Using a variable Plan for characteristic Version, you can therefore specify that the planning function is only to be applied to the characteristic values specified in variable Plan.

 Execute a Planning Sequence (Simple) 

UseUsing the Execute a Planning Sequence (Simple) command (EXEC_PLANNING_SEQUENCE_SIMPLE), you can trigger execution of a planning sequence.

Command ParametersThe table below lists the command parameters as they appear in the Command Wizard when you insert the command:

Parameter Description

Variables Screen You use this parameter to specify whether to display a Variables screen. If you do not select this option, the variable screen is displayed only if no entry has been made for required variables.

Process Changed Data You use this parameter to define whether the planning functions in this planning sequence will process just the data changed by the user in the current session since the last save or process all data (see Planning Functions, Processing Changed Data). If you choose this option, you can specify which aggregation level to analyze as a filter to define the changed records.

After the planning sequence has been executed, all subsequently changed data counts as having been completed by all participating planning functions (the steps in this sequence). This means for example that the data created by the last step of a sequence does not count as changed if the first step is executed again. If a button that just starts a planning sequence, “Check the Changed Data" for example, is executed several times in quick succession, the system does not process any data for the repeat executions.

Data Binding: Variant If the planning function uses variables, you can use this parameter to specify how they will be filled. Using a variable variant, you therefore specify the parameterization of the planning function. (See Sources for Characteristic Selection and Variables.)

Data Binding: Variables You use this parameter to specify the values for individual variables of the planning function. If a variant is also selected, a value assigned using this parameter is given precedence. (See Sources for Characteristic Selection and Variables.)

Planning Sequence (PLANNING_SEQUENCE) Technical name of the planning sequence. You use this parameter to specify which planning sequence is to be executed.

Application ContextThis command is particularly useful if you want to change data using various planning functions summarized as processing steps in a planning sequence. 

 Sources for Characteristic Selection and Variables The following overview illustrates the extent to which you can select which source is to fill characteristics and variables when you use the following commands: Execute a Planning Function (Simple), Execute a Planning Function, and Execute a Planning Sequence (Simple)

Execute a Planning Function (Simple)

Execute a Planning Function Execute a Planning Sequence (Simple)

Characteristic selection

For all characteristics, the selection is

For each characteristic, you can specify the source from which values are to be taken. You use the Selection Binding Type parameter

---

determined from the specified data provider (of type filter or query view).

(SELECTION_BINDING_TYPE) to select from the following options:

●      Web Item Selection (ITEM_CHARACTERISTIC):

The  AnalysisWeb item is suitable for the analysis.

●      Variable (VARIABLE)

●      Web Item with Manual Input (  Input Field Web item) (ITEM_INPUT)

●      Selections (SELECTIONS)

●      Data Provider Selection (DATA_PROVIDER_SELECTION)

Depending on the source you select, you must set additional

parameters. More information: Set Filter Values Using Different Sources.

Variable selection

Variables associated with types:

●      Characteristic Value Variable (INFO_OBJECT_MEMBER_VARIABLE)

●      Hierarchy Variable (HIERARCHY_VARIABLE)

●      Value Set Variable (VALUE_SET_VARIABLE)

●      Text Variable (TEXT_VARIABLE)

●      Formula Variable (FORMULAR_VARIABLE)

●      Input String for Variable (VARIABLE_INPUT_STRING)

Variable types that are filled dynamically can be filled by other sources at the runtime of the Web application:

●      Selection Binding Type (SELECTION_BINDING_TYPE)

The Selection Binding Type variable type provides the same sources that are available for characteristic selection for theExecute a Planning Function command.

●      Web Item Input Field (ITEM_INPUT)

Depending on the variable type you select, you must set additional

parameters. For more information, see  Set Variable Values.

Additional Examples of Planning Applications in the BEx WAD The following sections provide examples of certain fundamental design aspects that frequently occur when creating planning applications in the BEx Web Application Designer:

●      Copying Planning Functions (with Dropdown Box Web Item)

●      Revaluating Planning Functions (with Analysis Web Item)

●      Documentation (with Analysis Web Item)

Copying Planning Functions (with Dropdown Box Web Item) 

UseYou want to build a planning application with which you can copy the values from the source version to the target version. It must be possible to set the source and target versions using dropdown boxes. On execution, the planning application is to look as follows:

This example serves in particular to clarify the interaction between a planning function and two Dropdown Box Web items. Selections can also be restricted without using variables.

PrerequisitesIn the planning modeler, you have created an aggregation level that contains the following InfoObjects: unit Currency Key, time characteristicsQuarter and Calendar Year, key figure Amount, characteristics Version, Account Number, Cost Center. This aggregation level is also used in the examples below (Revaluating Planning Functions (with Analysis Web Item) and Documentation (with Analysis Web Item)).

The only thing that is important in this example is that the aggregation level contains the Version characteristic. This characteristic must have a master data-supported filter selection; you can specify this setting in the InfoObject maintenance: tab page Business Explorer, setting Filter Value Selection Query Execution, value Values in Master Data Table. In this example, the Version characteristic should display the values B01, B02, B03, and B04 in the dropdown boxes.

ProcedurePlanning Modeler: Creating Planning Functions, Variables, and Filters

1.        1.      Choose the Planning Functions tab page and create a planning function of the type Copy with technical name VERSION_COPY and description Version Copy for your aggregation level.

2.        2.      Choose To Characteristic Use and specify that it should be possible to change the Version characteristic.

3.        3.      Choose To the Parameters and specify that the Amount key figure is to be copied.4.        4.      The source and target versions should each be restricted using

a variable (VERSION_FROM and VERSION_TO). You can navigate to the creation dialog using the Before and After Values of the Copy Process table, for example. Both variables are to be specified in detail as follows: The variables should be individual values, required variables, and input ready, but should not have a standard default value.

5.        5.      Choose the Filter tab page and create a filter with technical name VERSION_FILT and the Version Selection description for your aggregation level.

Select the Version characteristic and choose the icon for input help in the column after Characteristic Restrictions. The dialog box for specifying the characteristic restriction appears. In the list of values, select all values (B01 to B04 in our example), choose Insert, and save the relevant selection by choosing OK.

Choose Show Extended Settings and set the indicator for the Changeable During Execution option; do not enter a default value.

More information about creating planning functions, variables, and filters: Modeling Planning Scenarios

BEx Web Application Designer: Creating Web Templates

6.        1.      In the BEx Web Application Designer, create a Web template with technical name VERSION_COPY.

7.        2.      Create the following data providers of the type Filter:

○       DP_FILT_FROM ○       DP_FILT_TO

For both filters, the data binding should come from the VERSION_FILT filter.

8.        3.      Create the following Web items:

○       DROPDOWN_ITEM_FROM: Choose the data binding type Characteristic/Structure Member. Specify the characteristic selection: data provider DP_FILT_FROM, characteristic VERSION.

○       DROPDOWN_ITEM_TO: Choose the data binding type Characteristic/Structure Member. Specify the characteristic selection: data provider DP_FILT_TO, characteristic VERSION, affected data provider DP_FILT_COPY_FUNCTION.

○       TEXT_ITEM_SOURCE for the source version (data binding: text connection, simple text, text source version)

○       TEXT_ITEM_TARGET for the target version (data binding: text connection, simple text, text target version)

○       BUTTON_GROUP_COPY_FUNCTION: Using Internal Display, create pushbutton 1 with label Copy and, as Action, use the command wizard to assign the following command (INSTRUCTION):

Table of Commands

Command Parameters

Planning-specific command EXEC_PLANNING_FUNCTION_SIMPLE (Execute Planning Function [Simple])

●      Data binding: reference to data provider of type Filter DP_FILT_TO and two variables (1 VERSION_FROM, 2 VERSION_TO)

●      Command-specific parameter: planning function VERSION_COPY

9.        4.      Create a CONTAINER_LAYOUT_ITEM_1 (Web Items → Enhanced → Container).

Choose the With Tray display option and enter label Version Copy under Tray Settings.

In the container (Internal Display → Layout Type: GRID → Row List), arrange the Web items in the following order:

Row 1: TEXT_ITEM_SOURCE

Row 2: DROPDOWN_ITEM_FROM

Row 3: TEXT_ITEM_TARGET

Row 4: DROPDOWN_ITEM_TO

Row 5: BUTTON_GROUP_COPY_FUNCTION

The following figure illustrates the layout of the VERSION_COPY Web template:

The table below contains the XHTML source text of the VERSION_COPY Web template:

XHTML Source Text of the VERSION_COPY Web Template<bi:bisp  xmlns="http://www.w3.org/TR/REC-html40" xmlns:bi="http://xml.sap.com/2005/01/bi/wad/bisp" xmlns:jsp="http://java.sun.com/JSP/Page" >    <html >        <head >            <title >BEx Web Application</title>            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />        </head>        <body >            <bi:SELECTOR_DATA_PROVIDER name="DP_FILT_FROM" >                <bi:SELECTOR_INITIAL_STATE type="CHOICE" value="SELECTION_OBJECT" >                    <bi:SELECTION_OBJECT value="VERSION_FILT" />                </bi:SELECTOR_INITIAL_STATE>            </bi:SELECTOR_DATA_PROVIDER>            <bi:SELECTOR_DATA_PROVIDER name="DP_FILT_TO" >                <bi:SELECTOR_INITIAL_STATE type="CHOICE" value="SELECTION_OBJECT" >                    <bi:SELECTION_OBJECT value="VERSION_FILT" />                </bi:SELECTOR_INITIAL_STATE>            </bi:SELECTOR_DATA_PROVIDER>            <bi:TEMPLATE_PARAMETERS name="TEMPLATE_PARAMETERS" /><!-- insert data providers, items and other template content here -->            <bi:CONTAINER_LAYOUT_ITEM name="CONTAINER_LAYOUT_ITEM_1" designwidth="10" designheight="10" >                <bi:WIDTH value="10" />                <bi:HEIGHT value="10" />                <bi:WITH_TRAY type="CHOICE" value="X" text="" >                    <bi:TRAY_SETTINGS type="COMPOSITE" >                        <bi:CAPTION value="Versionskopie" />                    </bi:TRAY_SETTINGS>                </bi:WITH_TRAY>                <bi:ROW_LIST type="ORDEREDLIST" >                    <bi:ROW type="ORDEREDLIST" index="1" >                        <bi:COLUMN type="COMPOSITE" index="2" >                            <bi:CHILD_ITEM_REF value="DROPDOWN_ITEM_FROM" />                            <bi:VALIGN value="CENTER" />                        </bi:COLUMN>                        <bi:COLUMN type="COMPOSITE" index="4" >                            <bi:CHILD_ITEM_REF value="DROPDOWN_ITEM_TO" />                            <bi:VALIGN value="CENTER" />                        </bi:COLUMN>                        <bi:COLUMN type="COMPOSITE" index="5" >                            <bi:CHILD_ITEM_REF value="BUTTON_GROUP_COPY_FUNCTION" />                        </bi:COLUMN>                        <bi:COLUMN type="COMPOSITE" index="1" >                            <bi:CHILD_ITEM_REF value="TEXT_ITEM_SOURCE" />                            <bi:VALIGN value="CENTER" />                        </bi:COLUMN>                        <bi:COLUMN type="COMPOSITE" index="3" >                            <bi:CHILD_ITEM_REF value="TEXT_ITEM_TARGET" />                            <bi:VALIGN value="CENTER" />                        </bi:COLUMN>                    </bi:ROW>                </bi:ROW_LIST>                <bi:DROPDOWN_ITEM name="DROPDOWN_ITEM_FROM" designheight="23" designwidth="150" >                    <bi:WIDTH value="150" />                    <bi:HEIGHT value="23" />                    <bi:DATA_BINDING_TYPE type="CHOICE" value="CHARACTERISTIC_SELECTION" >                        <bi:CHARACTERISTIC_SELECTION type="COMPOSITE" >                            <bi:DATA_PROVIDER_REF value="DP_FILT_FROM" />                            <bi:CHARACTERISTIC value="0VERSION" text="Version" />                            <bi:ALL_VALUES_ENTRY_INCLUDED value="" />                        </bi:CHARACTERISTIC_SELECTION>                    </bi:DATA_BINDING_TYPE>                </bi:DROPDOWN_ITEM>

                <bi:TEXT_ITEM name="TEXT_ITEM_TARGET" designheight="70" designwidth="200" >                    <bi:TEXT_BINDING type="CHOICE" value="TEXT_CONTENT" >                        <bi:TEXT_CONTENT value="Zielversion" />                    </bi:TEXT_BINDING>                </bi:TEXT_ITEM>                <bi:TEXT_ITEM name="TEXT_ITEM_SOURCE" designheight="70" designwidth="200" >                    <bi:TEXT_BINDING type="CHOICE" value="TEXT_CONTENT" >                        <bi:TEXT_CONTENT value="Quellversion" />                    </bi:TEXT_BINDING>                </bi:TEXT_ITEM>                <bi:DROPDOWN_ITEM name="DROPDOWN_ITEM_TO" designheight="23" designwidth="150" >                    <bi:WIDTH value="150" />                    <bi:HEIGHT value="23" />                    <bi:DATA_BINDING_TYPE type="CHOICE" value="CHARACTERISTIC_SELECTION" >                        <bi:CHARACTERISTIC_SELECTION type="COMPOSITE" >                            <bi:DATA_PROVIDER_REF value="DP_FILT_TO" />                            <bi:CHARACTERISTIC value="0VERSION" text="Version" />                            <bi:ALL_VALUES_ENTRY_INCLUDED value="" />                            <bi:LINKED_DATA_PROVIDER_REF_LIST type="ORDEREDLIST" >                                <bi:LINKED_DATA_PROVIDER_REF index="1" value="DP_FILT_COPY_FUNCTION" />                            </bi:LINKED_DATA_PROVIDER_REF_LIST>                        </bi:CHARACTERISTIC_SELECTION>                    </bi:DATA_BINDING_TYPE>                </bi:DROPDOWN_ITEM>                <bi:BUTTON_GROUP_ITEM name="BUTTON_GROUP_COPY_FUNCTION" designheight="23" designwidth="150" >                    <bi:WIDTH value="150" />                    <bi:HEIGHT value="23" />                    <bi:BUTTON_LIST type="ORDEREDLIST" >                        <bi:BUTTON type="COMPOSITE" index="1" >                            <bi:CAPTION value="Kopie" />                            <bi:ACTION type="CHOICE" value="INSTRUCTION" >                                <bi:INSTRUCTION >                                    <bi:EXEC_PLANNING_FUNCTION_SIMPLE >                                        <bi:SELECTOR_DATA_PROVIDER_REF value="DP_FILT_TO" />                                        <bi:PLANNING_FUNCTION value="VERSION_COPY" text="Versionskopie" />                                        <bi:VARIABLE_VALUES type="ORDEREDLIST" >                                            <bi:VARIABLE_VALUE type="COMPOSITE" index="1" >                                                <bi:VARIABLE value="VERSION_FROM" text="VERSION_FROM" />                                                <bi:VARIABLE_TYPE type="CHOICE" value="SELECTION_BINDING_TYPE" >                                                    <bi:SELECTION_BINDING_TYPE type="CHOICE" value="DATA_PROVIDER_CHARACTERISTIC" >                                                        <bi:DATA_PROVIDER_CHARACTERISTIC type="COMPOSITE" >                                                            <bi:DATA_PROVIDER_REF value="DP_FILT_FROM" />                                                            <bi:CHARACTERISTIC value="0VERSION" text="Version" />                                                        </bi:DATA_PROVIDER_CHARACTERISTIC>                                                    </bi:SELECTION_BINDING_TYPE>                                                </bi:VARIABLE_TYPE>                                            </bi:VARIABLE_VALUE>                                            <bi:VARIABLE_VALUE type="COMPOSITE" index="2" >                                                <bi:VARIABLE value="VERSION_TO" text="VERSION_TO" />                                                <bi:VARIABLE_TYPE type="CHOICE" value="SELECTION_BINDING_TYPE" >                                                    <bi:SELECTION_BINDING_TYPE type="CHOICE" value="DATA_PROVIDER_CHARACTERISTIC" >                                                        <bi:DATA_PROVIDER_CHARACTERISTIC type="COMPOSITE" >                                                            <bi:DATA_PROVIDER_REF value="DP_FILT_TO" />                                                            <bi:CHARACTERISTIC value="0VERSION" text="Version" />                                                        </bi:DATA_PROVIDER_CHARACTERISTIC>

                                                    </bi:SELECTION_BINDING_TYPE>                                                </bi:VARIABLE_TYPE>                                            </bi:VARIABLE_VALUE>                                        </bi:VARIABLE_VALUES>                                    </bi:EXEC_PLANNING_FUNCTION_SIMPLE>                                </bi:INSTRUCTION>                            </bi:ACTION>                        </bi:BUTTON>                    </bi:BUTTON_LIST>                </bi:BUTTON_GROUP_ITEM>            </bi:CONTAINER_LAYOUT_ITEM>        </body>    </html></bi:bisp>

Execution on the Web

10.        1.      Execute the Web template on the Web.11.        2.      For testing, extend the URL to include parameter &debug=X.

If you have set this parameter, the selection is shown in the Executing Planning Function section.

12.        3.      Choose the required versions using the dropdown boxes and copy the data between the versions.

  Revaluating Planning Functions (with Analysis Web Item) 

UseYou want to build a planning application with which you can enter turnover amounts for certain account numbers and revaluate them using a factor that can be set. If you select a row of the table, only the amount in this row is to be revaluated. If you do not select any rows, all values are to be revaluated. The planning application is to look roughly as follows on execution:

This example serves in particular to clarify the interaction between a planning function and an Analysis Web item. Special properties here are:

●      Variable handling in the planning function

●      Row selection in the Analysis Web item

PrerequisitesIn the planning modeler, you have created an aggregation level that contains the following InfoObjects: unit Currency Key, time characteristicsQuarter and Calendar Year, key figure Amount, characteristics Version, Account Number, Cost Center.

The planning function and the query are to use the same data of this aggregation level.

ProcedurePlanning Modeler: Creating Planning Functions, Variables, and Filters

       1.      Choose the Planning Functions tab page and create a planning function of the type Revaluate with technical name REVALUATE and description Revaluate for your aggregation level.

       2.      On the To the Parameters tab page, use the input help for the revaluation factor to create the REVAL_FACTOR variable with the Revaluation Factor description. The variable is to be specified in detail as follows: The variable is to be a required variable and is to be input ready; it is to be of type Number, but is not to contain a standard default value.

       3.      Choose the Filter tab page and create a filter with technical name ACCOUNT_FILT and description Revaluation Selection for your aggregation level.

Select the characteristics one after another and choose the input help icon in the column after Characteristic Restrictions. The dialog box for specifying characteristic restriction appears. Specify the required restrictions (in our example, Version = VERSION 1, Quarter = QUARTER 1,Calendar Year = 2007; Cost Center = 100002, Currency = Euro; for Account Number, all values are taken over), choose Add, and save the selections by clicking OK.

Choose Show Extended Settings and ensure that the Version characteristic cannot be changed on execution. (It must be possible to change theAmount key figure).

More information about creating planning functions, variables, and filters: Modeling Planning Scenarios

BEx Query Designer: Creating Queries

       1.      In the BEx Query Designer, create a query Revaluate (technical name: QUERY_REVALUATION) for your aggregation level.

       2.      Drag and drop the ACCOUNT_FILT filter into the Characteristic Restrictions area for filter values. In doing so, all characteristics are restricted to single values.

Drag and drop the Account Number characteristic into the area for default values.

       3.      Specify that the Account Number characteristic is in the rows. The values for this come from the master data.

Specify that the Amount key figure is in the columns. The values for this can be changed; on the Planning tab page, choose the Data Can be Changed Using User Input or Planning Functions option.

       4.      Save your query definition.

BEx Web Application Designer: Creating Web Templates

       1.      In the BEx Web Application Designer, create a Web template with technical name REVALUATION.

       2.      Create the following data providers:

○       DP_PLAN_DATA of the type Query View Data Provider, based on query QUERY_REVALUATION

○       DP_FILT_REVALUATION_FUNCTION of the type Filter. The data binding should come from the ACCOUNT_FILT filter.

       3.      Create the following Web items:

○       INPUT_FIELD_REVALUATION_FACTOR. Specify 10 as the default value (Internal Display → Text: 10).

○       BUTTON_GROUP_ REVALUATION. Using Internal Display, create pushbutton1 with label Revaluation and, as Action, use the command wizard to assign the following commands (INSTRUCTION):

Table of Commands

Command Parameters

Data provider-specific command: SET_SELECTION_STATE BY BINDING (Set Filter Values According to Different Sources)

●      Command target: target data provider DP_FILT_REVALUATION_FUNCTION

●      Data binding: selection binding using the Account Numbercharacteristic, where the value of the Web Item Selectionto come from the ANALYSIS_ITEM_1 Web item, characteristicNumber (ZD_ACCNT).

Planning-specific command EXEC_PLANNING_FUNCTION_SIMPLE (Execute Planning Function [Simple])

●      Data binding: Reference to data providers of type FilterDP_FILT_REVALUATE_FUNCTION, where the value from variable REVAL_FACTOR of connection type Web Item with Manual Input(ITEM_INPUT) is to come from INPUT_FIELD_REVALUATION_FACTOR.

●      Command-specific parameter: planning function REVALUATE

○       ANALYSIS_ITEM_1. Data provider DP_PLAN_DATA is assigned to the analysis grid as the (source) data provider.

Choose Behavior → Row Selection → Multiple (MULTIPLE).

In this case, it must be possible to select multiple rows and to execute the revaluation command on all selected rows. It is nottherefore possible to give the command along with the row selection; the command must instead be given using pushbuttons.

       4.      Create a CONTAINER_LAYOUT_ITEM_1 (Web Items → Enhanced → Container).

Divide the container into columns, choose the With Tray display option, and enter label Revaluation under Tray Settings.

Add the following Web items to the container:

○       1st row, 1st column: INPUT_FIELD_REVALUATION_FACTOR

1st row, 2nd column BUTTON_GROUP_ REVALUATION

○       2nd row, 1st column (with option Colspan=2, that is, with a merge of columns 1 and 2): ANALYSIS_ITEM_1

The following figure illustrates the layout of the REVALUATION Web template:

The table below contains the XHTML source text of the REVALUATION Web template:

XHTML Source Text of the REVALUATION Web Template

<bi:bisp  xmlns="http://www.w3.org/TR/REC-html40" xmlns:bi="http://xml.sap.com/2005/01/bi/wad/bisp" xmlns:jsp="http://java.sun.com/JSP/Page" >    <html >        <head >            <title >BEx Web Application</title>            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />        </head>        <body >            <bi:QUERY_VIEW_DATA_PROVIDER name="DP_PLAN_DATA" >                <bi:INITIAL_STATE type="CHOICE" value="QUERY" >                    <bi:QUERY value="QUERY_REVALUATION" text="QUERY_REVALUATION" />                </bi:INITIAL_STATE>            </bi:QUERY_VIEW_DATA_PROVIDER>            <bi:SELECTOR_DATA_PROVIDER name="DP_FILT_REVALUATION_FUNCTION" >                <bi:SELECTOR_INITIAL_STATE type="CHOICE" value="SELECTION_OBJECT" >                    <bi:SELECTION_OBJECT value="ACCOUNT_FILT" />                </bi:SELECTOR_INITIAL_STATE>            </bi:SELECTOR_DATA_PROVIDER>            <bi:TEMPLATE_PARAMETERS name="TEMPLATE_PARAMETERS" />            <bi:CONTAINER_LAYOUT_ITEM name="CONTAINER_LAYOUT_ITEM_1" designwidth="250" designheight="30" >                <bi:WIDTH value="250" />                <bi:HEIGHT value="30" />                <bi:WITH_TRAY type="CHOICE" value="X" text="" >                    <bi:TRAY_SETTINGS type="COMPOSITE" >                        <bi:CAPTION value="Umwertung" />                    </bi:TRAY_SETTINGS>                </bi:WITH_TRAY>                <bi:ROW_LIST type="ORDEREDLIST" >                    <bi:ROW type="ORDEREDLIST" index="1" >                        <bi:COLUMN type="COMPOSITE" index="1" >                            <bi:CHILD_ITEM_REF value="INPUT_FIELD_REVALUATION_FACTOR" />                        </bi:COLUMN>                        <bi:COLUMN type="COMPOSITE" index="2" >                            <bi:CHILD_ITEM_REF value="BUTTON_GROUP_REVALUATION" />                        </bi:COLUMN>                    </bi:ROW>                    <bi:ROW type="ORDEREDLIST" index="2" >                        <bi:COLUMN type="COMPOSITE" index="1" >                            <bi:CHILD_ITEM_REF value="ANALYSIS_ITEM_1" />                            <bi:COLSPAN value="2" />                        </bi:COLUMN>                    </bi:ROW>                </bi:ROW_LIST>                <bi:INPUT_FIELD_ITEM name="INPUT_FIELD_REVALUATION_FACTOR" designheight="70" designwidth="40" >                    <bi:WIDTH value="40" />                    <bi:TEXT_CONTENT value="10" />                    <bi:TEXT_ALIGNMENT value="END" />                </bi:INPUT_FIELD_ITEM>                <bi:BUTTON_GROUP_ITEM name="BUTTON_GROUP_REVALUATION" designheight="70" designwidth="50" >                    <bi:WIDTH value="50" />                    <bi:BUTTON_LIST type="ORDEREDLIST" >                        <bi:BUTTON type="COMPOSITE" index="1" >                            <bi:CAPTION value="Umwertung" />                            <bi:ACTION type="CHOICE" value="INSTRUCTION" >                                <bi:INSTRUCTION >                                    <bi:SET_SELECTION_STATE_BY_BINDING >                                        <bi:TARGET_DATA_PROVIDER_REF_LIST type="ORDEREDLIST" >                                            <bi:TARGET_DATA_PROVIDER_REF index="1" value="DP_FILT_REVALUATION_FUNCTION" />                                        </bi:TARGET_DATA_PROVIDER_REF_LIST>                                        <bi:SELECTION_BINDINGS type="UNORDEREDLIST" >                                            <bi:SELECTION_BINDING type="COMPOSITE" index="1" >                                                <bi:CHARACTERISTIC value="ZD_ACCNT" text="Account number" />                                                <bi:SELECTION_BINDING_TYPE type="CHOICE" value="ITEM_CHARACTERISTIC" >                                                    <bi:ITEM_CHARACTERISTIC type="COMPOSITE" >                                                        <bi:ITEM_REF value="ANALYSIS_ITEM_1" />                                                        <bi:CHARACTERISTIC value="ZD_ACCNT" text="Account number" />                                                    </bi:ITEM_CHARACTERISTIC>                                                </bi:SELECTION_BINDING_TYPE>                                            </bi:SELECTION_BINDING>                                        </bi:SELECTION_BINDINGS>                                    </bi:SET_SELECTION_STATE_BY_BINDING>                                    <bi:EXEC_PLANNING_FUNCTION_SIMPLE >

                                        <bi:SELECTOR_DATA_PROVIDER_REF value="DP_FILT_REVALUATION_FUNCTION" />                                        <bi:PLANNING_FUNCTION value="REVALUATE" text="Umwerten" />                                        <bi:VARIABLE_VALUES type="ORDEREDLIST" >                                            <bi:VARIABLE_VALUE type="COMPOSITE" index="1" >                                                <bi:VARIABLE value="REVAL_FACTOR" text="" />                                                <bi:VARIABLE_TYPE type="CHOICE" value="ITEM_INPUT" >                                                    <bi:ITEM_INPUT type="COMPOSITE" >                                                        <bi:ITEM_REF value="INPUT_FIELD_REVALUATION_FACTOR" />                                                    </bi:ITEM_INPUT>                                                </bi:VARIABLE_TYPE>                                            </bi:VARIABLE_VALUE>                                        </bi:VARIABLE_VALUES>                                    </bi:EXEC_PLANNING_FUNCTION_SIMPLE>                                </bi:INSTRUCTION>                            </bi:ACTION>                        </bi:BUTTON>                    </bi:BUTTON_LIST>                </bi:BUTTON_GROUP_ITEM>                <bi:ANALYSIS_ITEM name="ANALYSIS_ITEM_1" designwidth="400" designheight="200" >                    <bi:DATA_PROVIDER_REF value="DP_PLAN_DATA" />                    <bi:SELECT_ROWS type="CHOICE" value="MULTIPLE" />                </bi:ANALYSIS_ITEM>            </bi:CONTAINER_LAYOUT_ITEM><!-- insert data providers, items and other template content here -->        </body>    </html></bi:bisp>

Execution on the Web

       1.      Execute the Web template on the Web.

       2.      For testing, extend the URL to include parameter &debug=X.

If you have set this parameter, the selection is shown in the Executing Planning Function section.

       3.      Enter amounts for one or more account numbers, change the revaluation factor if necessary (default value = 10), select the required rows, and choose Revaluation.

For example, enter amount 100 in the first row, retain revaluation factor 10, and choose Revaluation. The query outputs an amount of 110 in both the selected row as well as in the overall result (as long as you have not entered any other values).

  Documentation (with Analysis Web Item) 

UseYou want to build a planning application with which you enter turnover amounts for certain account numbers and with which you can create a document for such a data record. The planning application is to look approximately as follows:

This example serves in particular to clarify the interaction between an Analysis Web item and an Individual DocumentWeb item. Special properties here are:

●      Row selection with command in the Analysis Web item. The row selection immediately takes effect in the document display.

Prerequisites●      As in example Revaluating Planning Functions (with Analysis Web Item), you use

○       an aggregation level that contains the following InfoObjects: unit Currency Key, time characteristics Quarter and Calendar Year, key figureAmount, characteristics Version, Account Number, Cost Center.

○       filter ACCOUNT_FILT

○       query QUERY_REVALUATION

●      In the InfoObject maintenance (transaction RSD1), you have set the option Characteristic is Document Property for characteristic Account Number (tab page General).

ProcedureBEx Web Application Designer: Creating Web Templates

       1.      In the BEx Web Application Designer, create a Web template with the name DOC_SELECTION.

       2.      Create the following data providers of type Query View Data Provider:

○       DP_DOCS_ALL

○       DP_DOCS_RESTRICTED

Both data providers are to be based on query QUERY_REVALUATION.

       3.      Create the following Web items:

○       ANALYSIS_ITEM_1. Data provider DP_DOCS_ALL is assigned to the analysis grid as the (source) data provider.

Choose Behavior → Row Selection → Single with Command (SINGLE_WITH_COMMAND).

Row selection Single (SINGLE): The user can only select one row; there is no roundtrip to the server. Row selection Single with Command: The user can only select one row, but the system starts a roundtrip to the server and executes activation and deactivation commands if necessary.

Example: Row 1 is active. You now select row 2. The system executes the deactivation command on row 1 if necessary and deactivates row 1. The system then selects row 2 and executes the activation command on row 2.

In our example, the aim is that when you select a row in the Analysis Web item, the system displays the document that corresponds to this row selection. To do this, use the command wizard to create the following command as the activation action:

Table of Commands

Command Parameter

Data provider-specific command SET_SELECTION_STATE BY BINDING (set filter values according to different sources)

●      Command target: target data provider DP_DOCS_RESTRICTED

●      Data binding: selection binding using the Account Number(ZD_ACCNT) characteristic, where the value of the binding type Web item selection is to come from the ANALYSIS_ITEM_1 Web item, characteristic Account Number (ZD_ACCNT).

Set the Document Icons for Data characteristic to On.

○       SINGLE_DOCUMENT_ITEM_1.

A document is to contain a maximum of 10 rows. It is to be embedded into the Web application (and not only displayed as a link). If multiple documents are included, these are to be displayed as a list. Set the following parameters accordingly:Internal Display → Maximum Number of Text Rows: 10; Display in Web Application : On; Web Item List of Documents: OnBehavior → Maintenance Possible: On; Processing Mode: OnData provider DP_DOCS_RESTRICTED is assigned to the document as the (source) data provider. The document is to be created for changing a turnover amount, that is, for a transaction data record. Set the following parameters accordingly:Data Binding → Data Provider: DP_DOCS_RESTRICTED, Document Class: InfoProvider[MULTI]

If you choose the Master Data setting, you can enter documentation for an account number.

The following figure illustrates the layout of the DOC_SELECTION Web template:

The table below contains the XHTML source text of the DOC_SELECTION Web template:

XHTML Source Text of the DOC_SELECTION Web Template

<bi:bisp  xmlns="http://www.w3.org/TR/REC-html40" xmlns:bi="http://xml.sap.com/2005/01/bi/wad/bisp" xmlns:jsp="http://java.sun.com/JSP/Page" >    <html >        <head >            <title >Netweaver BI Web Application</title>            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />        </head>        <body >            <bi:QUERY_VIEW_DATA_PROVIDER name="DP_DOCS_ALL" >                <bi:INITIAL_STATE type="CHOICE" value="QUERY" >                    <bi:QUERY value="QUERY_REVALUATION" text="QUERY_REVALUATION" />                </bi:INITIAL_STATE>            </bi:QUERY_VIEW_DATA_PROVIDER>            <bi:QUERY_VIEW_DATA_PROVIDER name="DP_DOCS_RESTRICTED" >                <bi:INITIAL_STATE type="CHOICE" value="QUERY" >                    <bi:QUERY value="QUERY_REVALUATION" text="QUERY_REVALUATION" />                </bi:INITIAL_STATE>            </bi:QUERY_VIEW_DATA_PROVIDER>            <bi:TEMPLATE_PARAMETERS name="TEMPLATE_PARAMETERS" /><!-- insert data providers, items and other template content here -->            <p >                <bi:ANALYSIS_ITEM name="ANALYSIS_ITEM_1" designwidth="400" designheight="200" >                    <bi:DATA_PROVIDER_REF value="DP_DOCS_ALL" />                    <bi:LINKED_DATA_PROVIDER_REF_LIST type="ORDEREDLIST" />                    <bi:NEW_LINES_COUNT value="0" />                    <bi:SELECT_ROWS value="SINGLE_WITH_COMMAND" >                        <bi:SINGLE_WITH_COMMAND type="COMPOSITE" >                            <bi:ACTIVATION_ACTION type="CHOICE" value="INSTRUCTION" >                                <bi:INSTRUCTION >                                    <bi:SET_SELECTION_STATE_BY_BINDING >                                        <bi:TARGET_DATA_PROVIDER_REF_LIST type="ORDEREDLIST" >                                            <bi:TARGET_DATA_PROVIDER_REF index="1" value="DP_DOCS_RESTRICTED" />                                        </bi:TARGET_DATA_PROVIDER_REF_LIST>                                        <bi:SELECTION_BINDINGS type="UNORDEREDLIST" >                                            <bi:SELECTION_BINDING type="COMPOSITE" index="1" >                                                <bi:SELECTION_BINDING_TYPE type="CHOICE" value="ITEM_CHARACTERISTIC" >                                                    <bi:ITEM_CHARACTERISTIC type="COMPOSITE" >                                                        <bi:ITEM_REF value="ANALYSIS_ITEM_1" />                                                        <bi:CHARACTERISTIC value="ZD_ACCNT" text="Account number" />                                                    </bi:ITEM_CHARACTERISTIC>                                                </bi:SELECTION_BINDING_TYPE>                                                <bi:CHARACTERISTIC value="ZD_ACCNT" text="Account number" />                                            </bi:SELECTION_BINDING>                                        </bi:SELECTION_BINDINGS>                                    </bi:SET_SELECTION_STATE_BY_BINDING>                                </bi:INSTRUCTION>                            </bi:ACTIVATION_ACTION>                        </bi:SINGLE_WITH_COMMAND>                    </bi:SELECT_ROWS>                    <bi:DOCUMENT_ICONS_DATA value="X" />                    <bi:BLOCK_COLUMNS_SIZE value="5" />                    <bi:BLOCK_ROWS_SIZE value="5" />                </bi:ANALYSIS_ITEM>            </p>            <p >                <bi:SINGLE_DOCUMENT_ITEM name="SINGLE_DOCUMENT_ITEM_1" designheight="300" designwidth="350" >                    <bi:DATA_PROVIDER_REF value="DP_DOCS_RESTRICTED" />                    <bi:MAX_TEXT_LINES value="10" />                    <bi:MAINTENANCE_POSSIBLE value="X" />                    <bi:EDIT_MODE value="X" />                    <bi:DOCUMENT_CLASS type="CHOICE" value="MULTI" />                    <bi:PROPERTY_LIST type="ORDEREDLIST" />                </bi:SINGLE_DOCUMENT_ITEM>            </p>        </body>    </html></bi:bisp>

Execution on the Web

       1.      Execute the Web template on the Web.

       2.      Select a row, enter a text in it, and save this text. In the corresponding amount field in the analysis grid, a document icon indicates that documentation exists for this data record.

       3.      If you have created documents for multiple rows, these are displayed as a document list.

Performing Manual Planning 

UseIn BI applications that use data providers that an input-ready query is assigned to, the system allows manual entry of data using either input-ready cells or new input-ready rows.

In input-ready cells, you can change individual key figure values for a posted data record. In new input-ready rows, you can either change posted data records or enter new data records for characteristic combinations that do not yet exist.

IntegrationYou use BEx Analyzer to create and execute BI applications that provide this function. Alternatively, you can create them in Web Application Designer and execute them on the Web. In BEx Analyzer, you use the Analysis Grid design item. In Web Application Designer, you use the Analysis Web item.

For more information about manually entering data in a BI application created using BEx Analyzer, see Functions for Manual Planning.

PrerequisitesThe following conditions apply if you want to change existing data:

●      At least one input ready key figure exists.

The following conditions apply if you want to enter data in new rows:

●      No active universal display hierarchies exist.

FeaturesInput Ready Queries at Execution

Whether the cells in an input-ready query can be changed at execution depends on the query view and possibly on other settings (such as settings for data slices and characteristic relationships).

With regard to whether the cells of a query view are input ready, note the following rules:

       1.      In a query that is used for manual planning, a cell is only input ready if each characteristic value of all the characteristics included in the aggregation level is unique. None of the aggregated values on the aggregation level are therefore input ready: Totals, subtotals and inner hierarchy nodes are not input ready.

       2.      To be able to change values for calculated key figures (like Average Price as a quotient of Amount and Quantity), these must be based on input-ready formulas, and at least one operand must be input ready. More information: Defining Inverse Formulas (Designtime) and Inverse Formulas(Runtime).

       3.      In order to change aggregated values (with respect to the aggregation level), these values must be disaggregated on all the data records that contribute to the aggregated value of the cell. More information: Disaggregation (Top-Down-Distribution).

       4.      If a query used for manual planning includes a navigation attribute that is restricted using a fixed or dynamic filter or a restricted key figure, the system treats the navigation attribute as a normal characteristic. The rule under point 1 applies here. The system only reacts as though the navigation attribute were not part of the query if the navigation attribute is not restricted.

       5.      In a query defined on a MultiProvider or a complex aggregation level that you want to use manual planning for, a cell is not input ready if the InfoProvider that is defined by this cell is:

8.                             a.      Not a real-time InfoCube9.                             b.      A real-time InfoCube that has been switched to load mode

       6.      If an input-ready query is executed in change mode, but the requested data is locked by another user, the query starts in display mode.

Input-Ready Objects (Cells and Rows)

Depending on the tool you are using, note the following differences:

BEx Analyzer Web Application Designer

New Input-Ready Rows

Depending on the tool you are using, note the following:

BEx Analyzer Web Application Designer

Posted data

You can enter plan data irrespective of whether data has been posted.

If no data is available in the analysis grid, you can use input help to restrict the free characteristics to a single value or drag and drop the free characteristics to the rows. In the columns, you can use no characteristics and no more than one structure.

Posted data

You can enter plan data irrespective of whether data has been posted.

If no data is available in the analysis grid, you can use input help to restrict the free characteristics to a single value or drag and drop the free characteristics to the rows. In the columns, you can use no characteristics and no more than one structure.

You can also switch the position of the rows and columns here.

Rows and columns

You can use no more than one structure in the columns or rows.

If data is not available in the analysis grid, you can use one structure only in the columns, but you cannot use a structure in the rows.

Rows and columns

You can use no more than one structure in the columns or rows.

Appearance of input-ready rows

New Input-new cells are always displayed under the table. You can enter data in all input-ready rows. The system determines the number of rows where data has been entered by checking the cells under the table in the first column. If one of these cells contains data, the system assumes that data has been entered for the corresponding row.

Appearance of input-ready rows

You set the number and position of the new input-ready new rows in the parameters of the relevant Web item (under Internal Display).

Input help

You can access input help for a cell by double-clicking it or pressing F4.

Input help

Input help is available for each input-ready row.

Entry

You can enter a key or text.

If you are working with text, the system has to be able to determine a key from the text in the logon language. We therefore recommend working with keys.

Entry

You have to enter a key.

ActivitiesInput-Ready Cells

In input-ready cells, you can change the individual key figure values for a posted data record.

Input-Ready Rows

You can enter new rows if you the analysis grid allows this. In the simplest case, you use the key figure structure in the data columns and use input help to restrict the free characteristics to a single value or drag and drop a free characteristic to the rows or columns.

You cannot enter a new row if the unit or currency you used is included in the drilldown and is not restricted to a single value.

To avoid this restriction, you can create a planning function that creates a new data record (a null record if null suppression is deactivated).

The system only displays a new input-ready row if at least one of the cells in the row is defined uniquely with regard to the characteristics in the underlying aggregation level. When using navigation attributes and time characteristics, avoid redundancy by making sure that you do not have derivable characteristics in the drilldown at the same time (like month and quarter).

In BEx Analyzer, note that the Analysis Grid design item has to be displayed in full size. You make this setting in design mode in the Analysis Grid Properties dialog box on the Clipping tab page. Choose Full Size as the horizontal and vertical setting.

If you chose the Suppress New Rows setting for the Analysis Grid design item (Analysis Grid Properties → tab page General), you can only change the key figure values for posted data records.

If you want to create a Web application, specify how many input ready new cells you want, and where to display them. You do this in the Web item parameters in BEx Web Application Designer. (The default setting is 0. New rows are not displayed in the default setting). In a Web template, new rows appear for a characteristic or its attributes if, in the Query Designer under Properties → Technical Name, you have chosen the Text display for this characteristic.

Depending on the tool you are using, proceed as follows:

BEx Analyzer Web Application

You are in change mode. In the new input-ready rows, enter the required key figure and characteristic values.

Execute the Web template and enter the required key figure and characteristic values in the new input-ready rows, .

Choose Transfer Values to transfer one or more changed or new data records to the server to be checked.

Choose Refresh to transfer one or more changed or new data records to the server to be checked.

Choose Save Values to save the data records persistently to the database.

Choose Save to save the data records persistently to the database.

The data is checked automatically during navigation (filter changes), and navigation is not permitted if any entries have errors.

 Functions for Manual Planning 

UseIn BEx Analyzer, you can use input-ready queries to create applications that allow manual data entry. These can be simple applications where you use input-ready queries only. On the other hand, they can be complex applications for manual planning where you can combine numerous queries that are input-ready or can be defined for a particular analysis alongside planning functions that change data automatically. 

The BEx Analyzer functions that help you when entering data are described below.

For an example of an application created using BEx Analyzer, see Creating Planning Applications.

PrerequisitesYou have defined one or more input-ready queries so that you can assign data providers to them. For more information about defining an input-ready query, see Input-Ready Queries.

FeaturesManual Entry of Data in an Analysis Grid

In BEx Analyzer, you use the Analysis Grid design item for manual planning. This uses the data

provider you have selected to reference an input-ready query (or query view). See  Analysis Grid. In the analysis grid, a structure element of the query is input-ready if you set the corresponding flag for the element in the query definition.

Note that a cell can only be input-ready if every characteristic for this cell is defined uniquely in the underlying aggregation level. The aggregation level models the levels on which key figure values can be changed. If you have free characteristics, you have to drag and drop them into the rows or columns before cells can be input ready.

Other settings in BI Integrated Planning, such as data slices or characteristic relationships, also affect whether data cells are input ready.

In the simplest case, you want to manually enter or change values in input-ready cells.

The system uses a predefined MS Excel format template (SAPBEXinputData) to help you when visualizing the input-ready cells. You can format this according to your requirements so that you can distinguish input-ready cells from cells that are not input ready. To change the format template, chooseFormat → Format Template.

In the default setting, all the cells in a workbook can be changed. If you activate cell protection in the workbook, you can only change the input-ready cells. In the context menu for the analysis grid, choose Properties. In the Properties of Analysis Grid dialog box, on theGeneral tab page, set the Enable Cell Protection indicator.

Depending on the analysis grid, you can also enter new rows. In the simplest case, you use the key figure structure in the data columns and use input help to restrict the free characteristics to a single value or drag and drop a free characteristic to the rows or columns. If no data is available in the analysis grid, you use input help to restrict the free characteristics to a single value and/or drag and drop the free characteristics into the rows.

If new rows can be entered, the system displays a row under the analysis grid. This row is formatted in the same way as the input-ready cells. More information: Performing Manual Planning

Transfer Values

Changed cells and new rows are checked on the BI server. Choose Transfer Values in the context menu for a cell that has been changed. The system reads the values from the workbook, transfers them to the BI server and checks them for consistency against the planning model. The system only accepts the data if all entries are ‘correct’. As soon as the changed data is available on the BI server, it is automatically visible in all other components of the workbook for manual planning purposes. Other analysis grids that are input ready or determined for a particular analysis are refreshed accordingly with the changed data.

The values are also checked and transferred (if applicable) implicitly with each navigation.

In the workbook settings on the General tab page, you can change the setting that defines when plan data is transferred. We recommend using the default Transfer Plan Values to Server Before Navigation option. If you select Transfer Plan Values to Server Before Navigation,  the system displays a confirmation prompt each time before it transfers the values. If you select Do Not Transfer Plan Values to Server Before Navigation, the input-ready plan data is not transferred.

Save Values

Data that has been changed while BEx Analyzer is open is retained on the BI server (in the planning buffer) if it is consistent. In the context menu, choose Save Values to save this data in the InfoProvider on the database on the BI server.

You can create functions for transferring (CHECK_VALUES) and saving (SAVE_AREA) changed data using buttons. For an example of how to create a save function, see Creating Planning Applications in BEx Analyzer.

Using a Formula to Change Values

In the context menu for an input-ready cell, you can choose Change Values Using Formula to access a calculator-like that helps you when entering data.

If you want to change individual cells or entire areas, highlight the area, enter a revaluation factor and choose enter or CTRL + enter. The selected area is revaluated accordingly.

You can get information about the valid syntax for this from the Office Assistant. Choose Help → Show Office Assistant.

 Disaggregation (Top-Down Distribution) 

PurposeDisaggregation (also called top-down distribution) helps you to manually enter data within manual planning. It enables you to make manual entries within input-ready queries, also for aggregated values .

Input-ready queries are used with aggregation levels; without the disaggregation, a cell is only input-ready if all characteristic values of all the characteristics contained in the aggregation level are uniquely defined. Accordingly, all the cells that contain aggregated values with respect to the aggregation level, such as totals, subtotals, and inner hierarchy nodes, are not input-ready. In order to change aggregated values (with respect to the aggregation level), these values must be disaggregated on all the data records that contribute to the aggregated value of the cell. In the Query Designer it is possible to perform this disaggregation for the following elements:

●      Key Figures

●      Restricted key figures

Disaggregation is only available for basic key figures with aggregation type SUM, but not for calculated key figures, key figures with exception aggregation, local aggregations and time key figures.

Note that disaggregation in queries does not invalidate the current design of the BI planning: New data records and delta records are always created for aggregation levels.

Disaggregation is not optimized for mass processing of data. We recommend that you use the top-down planning function type in batch processing for such scenarios.

Disaggregation in input-ready queries can have an effect on the application modeling of the BI planning, especially in the area of characteristic relationships.

More information: Input-Ready Query

ExampleSome simple examples that show how the system distributes values according to the settings made in the Query Designer are given below. The sample scenario is as follows: The aggregation level contains the characteristics: Product, Version, Fiscal Year Variant, Fiscal Year,Currency and the

key figure Amount.

Product is drilled down in the rows, and all other characteristics are limited to one value. As a result,

all the data required for the disaggregation is visible in the query view.

Example 1

In the Query Designer, the key figure Amount is defined by the setting No

Disaggregation vorgenommen.

No Disaggregation

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 20

TFT 19“ Monitor 1 10 14 14

TFT 21“ Monitor 1 0 2 2

Result 3 30 30 36

This result row is not input-ready. Only changing the values in the input-ready cells has an effect on the result cell.

Example 2

In the Query Designer, the key figure Amount is defined by the setting Disaggregation for distribution type Equal Distribution.

Disaggregate Entered Value, Equal Distribution

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 12

TFT 19“ Monitor 1 10 10 12

TFT 21“ Monitor 1 0 0 12

Result 3 30 36 36

This result row is input-ready. Its value changes from 30 to 36. Value 36 is distributed equally to all three affected cells (36/3 = 12).

Example 3

Disaggregate Entered Value, Analog Distribution (Self-Reference)

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 24

TFT 19“ Monitor 1 10 10 12

TFT 21“ Monitor 1 0 0 0

Result 3 30 36 36

The value of the result row changes from 30 to 36. 36 is distributed to the cells analogously to the previous cell values, that is weighted.

Example 4

In the Query Designer, the key figure Amount is defined by the setting Disaggregate Value Entered for distribution type Analog Distribution (With Reference to Following Structure Element).

Disaggregate Value Entered, Analog Distribution (to Following Structure Element)

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 12

TFT 19“ Monitor 1 10 10 12

TFT 21“ Monitor 1 0 0 12

Result 3 30 36 36

The value of the result row changes from 30 to 36. As a result of the selected distribution type, the values in key figure Amount (Reference) are used as reference for the analog distribution of the

changed value. (In this example this produces the same results as Example 1.)

You have the most flexible type of distribution when the reference column is input-ready. In this case you can enter the weighting for the distribution there.

Example 5

Disaggregate Difference To Value Entered, Equal Distribution

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 22

TFT 19“ Monitor 1 10 10 12

TFT 21“ Monitor 1 0 0 2

Result 3 30 36 36

The value of the result row changes from 30 to 36. The new value is not distributed to the affected cells; instead, only the difference between the value before input and after manual input (6) is distributed. Since distribution type Equal Distribution was selected, all affected cell values are modifed by the value 6/3 = 2.

Example 6

Disaggregate Difference to Value Entered Value, Analog Distribution (Self-Reference)

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 1 20 20 24

TFT 19“ Monitor 1 10 10 12

TFT 21“ Monitor 1 0 0 0

Result 3 30 36 36

The value of the result row changes from 30 to 36. The new value is not distributed to the affected cells; instead, only the difference between the value before input and after manual input (6) is distributed. The 6 is distributed to the cells analogously to the previous cell values, that is they are weighted.

Example 7

Disaggregate Difference to Value Entered, Analog Distribution (with Reference to Following Structure Element)

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 10 20 20 20 + 2 = 22

TFT 19“ Monitor 0 10 10 10 + 0 = 10

TFT 21“ Monitor 20 0 0 0 + 4 = 4

Result 30 30 36 36

The value of the result row changes from 30 to 36. The new value is not distributed to the affected cells; instead, only the difference between the value before input and after manual input (6) is distributed. Because of the selected distribution type, the values in key figure Amount(Reference) are used as

reference for the analog distribution of the changed value.

Example 8

All the examples have in common that the reference data for the distribution exists in the query view. In practice, however, this is often not the case, which can cause results that appear to be incorrect.  An example that contains such a supposed error is given below. The following data is assumed; all characteristics that are not specifically mentioned have a fixed value.

Disaggregation with Hidden Reference Data

Product Fiscal Year Amount

TFT 17“ Monitor 2007 0

TFT 19“ Monitor 2007 0

TFT 19“ Monitor 2008 0

TFT 21“ Monitor 2007 0

TFT 21“ Monitor 2008 0

TFT 21“ Monitor 2009 0

The same query view as above is shown, but the characteristic Fiscal Year is not drilled down. If

the result row changes from 0 to 6 and the system uses distribution type Equal Distribution, the values

are not distributed equally after aggregation over Fiscal Year. This is because each product has a

different number of data records and the system reads all the data records that contribute to the result.

Product Amount (Reference)

Amount (Before Input)

Amount (Manual Input)

Amount (After Input)

TFT 17“ Monitor 0 0 0 1

TFT 19“ Monitor 0 0 0 2

TFT 21“ Monitor 0 0 0 3

Result 0 0 6 0

In the above situation, a drilldown by Fiscal Year could have displayed all the data records used for the distribution.

When using disaggregation, we recommend that you model the planning application so that the reference data needed for the distribution always exists. Otherwise it is not possible to distribute the given values. To ensure that the reference data for the disaggregation exists, proceed as follows:

■       In the query definition under Access Type for Result Values you can define the Characteristic Relationship or Master Data so that the system proposes all the required data records. Limit the selections in the query to a number that is suitable

for manual planning. More information:  Characteristic Properties, tab page Advanced.

■       Another option is the planning application for creating proposals for planning data using planning functions, for example by copying actual data.

 Inverse Formulas at Runtime  This chapter provides information about runtime aspects of inverse formulas. We assume that you can

create input-ready and inverse formulas in Query Designer (see Input-Ready Queries, Examples: Inverse Formulas and Defining Inverse Formulas)

You can find examples showing runtime aspects of inverse formulas under Examples: Inverse Formulas at Runtime and in SAP Note 1236347.

You can use input-ready formulas in SAP BusinessObjects Analysis, Edition for Microsoft Office (version 1.1) and in BEx Analyzer and BEx Web Analyzer.

Note that rows can only be fixed in BEx Web Analyzer.

Input-Readiness of Formulas

Formulas inherit their input-readiness from their operands. If you have defined an input-ready formula F = F(op1, …, opn) in Query Designer, the system checks whether at least one operand is input ready at runtime. If this is not the case, formula F is not input ready either. If an operand opi = G is also an input-ready formula, the same rule applies.

As with input-ready structural elements, the input-readiness of formulas require unique definition of certain characteristics: If an input-ready formula or an operand in an input-ready formula uses exception aggregation, unique definition is required for all reference characteristics for the exception aggregation at cell level so that the formula can be input ready. This also applies for values of master data attributes in input-ready formulas (formula variables of type Replacement Path, whose variable has been replaced by the attribute value of a characteristic).

Sequence of Calculations

Calculating inverse formulas can be seen as a kind of “inverted” reporting. As BI Integrated Planning uses input-ready queries for manual planning, the system calculates the reporting formulas for the result set that is sent to the front end. In ABAP Dynpro terminology, reporting formulas are therefore calculated in PBO (process before output). After data has been changed manually in input-ready cells

in the query, a server roundtrip is triggered, known as a PAI (process after input). Inverse formulas are calculated at this point. Changes in input-ready formulas are returned to the basic key figures, while observing any disaggregation settings that have been made. This creates new delta records that are stored in the delta buffer. In the next, the OLAP processor reads the delta records in order to refresh its internal status and the result set. The reporting formulas are calculated again during this process.

For the inverse formulas, this means that there must be inversion of these input-ready formulas in the mathematical sense. Otherwise, a change in an input-ready formula would be overwritten in the next PBO after a completed PAI-PBO cycle.

The following section explains the general rules for the implemented initial calculation model and the symmetrical calculation model, which can be selected as an enhanced calculation mode in BEx Query

Designer (see Input-Ready Queries and Defining Inverse Formulas).

General Rules

Depending on which calculation mode is selected in BEx Query Designer, the system triggers calculation of inverse formulas either when input-ready formulas are changed/fixed, and other operands of input-ready formulas have been changed (initial - or asymmetrical calculation -mode), or if an element in a formula group has been manually changed or fixed (symmetrical calculation mode).

Let F = F(op1,..., opn) be an input-ready formula, and op1,..., opk with k < n be input-ready operands. In Query Designer, k inverse formulas have been created in order to calculate operands op1,..., opn:

Fi = Fi(F, op1,…, opi-1, opi+1, … , opk, … , opn)  for i = 1,…, k

If F has been changed for example, the system needs to find the ‘best’ inverse formula Fi for its calculation. The result of Fi is passed onto opi. The new value of opi can then trigger other calculations or a disaggregation.

The system uses the following rules for formula inversion.

       1.      Formula inversions are made based on data records. The values of the characteristics in the drilldown determine the data record here. Inverse formulas are calculated for each data record for the structural components defined in Query Designer. These calculations are not affected by other data records.

       2.      If there are nested formula groups, input-ready formulas can be calculated back to input-ready basic or restricted key figures by inversion of other input-ready formulas. If key figures use one of the disaggregation settings, these changes trigger a disaggregation.

       3.         In a server roundtrip, no more than one inverse formula is calculated per formula group. After a calculation, all elements of this formula group are temporarily fixed, meaning that the elements of a formula group that has already been calculated cannot be overwritten by calculations from other formula groups during this roundtrip.

       4.      To find the inverse formula that needs to be calculated, the system first gathers the elements that trigger calculations. These are changed or fixed cell values of input-ready formulas or elements in a formula group (for each data record). The calculation is triggered by different elements, depending on the calculation mode selected (asymmetrical or symmetrical). If an operand in the formula group was calculated in a previous step, this operand is also treated as fixed for the new calculation, meaning that it is considered a known source. Possible targets for calculation are input-ready operands in the current formula group, which are not changed, fixed or calculated. If one of the inverse formulas cannot clearly be recognized as requiring calculation, the system takes the inverse formula with the highest formula priority defined in BEx Query Designer.

       5.      Multiple formula groups can participate in the calculations triggered by manual changes or fixed cell values. As the formula priority definition relates to all elements in a formula group, it is not possible to tell which formula group is to be calculated first. The system calculates the formula groups in ascending order following the number of “degrees of freedom”. The current degree of freedom is worked out by taking the number of operands and subtracting the number of operands already recognized. These are operands that are constants, fixed, manually changed or were calculated in a previous step. If the current degree of freedom of the formula group is the same, the system checks whether the symmetrical calculation mode is used. If this is the case, the system analyzes the Note for Calculation to clarify the formula priority. In all other cases, the order in which the formula groups are processed remains undefined.

       6.      With regard to formula inversion, new rows are treated like existing ones. If the row already exists, changed or recalculated vales are aggregated by basic key figures.

The system does not try to find any old solution for the computational problem resulting from manual changes and other types of Customizing being performed on input-ready queries. The system finds a solution using the rules listed above. If this is not successful, the system informs you with an error message.

Error Handling

If the system does not find any inverse formulas for calculation, it means that the entries made by the user are invalid. The system generates messages providing information about the cause of the problem, such as too many manual changes or too many restrictions from fixed values.

There are cases where all formula inversions are possible, but the subsequent disaggregation of the values is not. This can be the case if all individual values in a subtotal, total or a hierarchy node and the subtotal, total or hierarchy node itself have been changed or calculated. The system generates messages accordingly.

Rounding Rules

Key figure values are saved in the database with a limited number of decimal places. When formulas are calculated, rounding normally takes place. Inverse formulas can be used to calculate key figures that are stored on the database. For key figures like this, every calculated key figure value or key figure value created by disaggregation is therefore rounded to the database decimals. If the system calculates aggregated values using inverse formulas and disaggregates the calculated values, serious rounding errors can occur. It is therefore important to realize that a manually changed value can deviate from the value entered after the formula inversion has been calculated and the result set updated. This also applies for fixed values.

We therefore recommend using the same number of database decimal places for all operands of inverse formulas.

Recommendations

We recommend using nested input-ready formulas. As far as possible, model input-ready formulas and formula inversions in such a way that there are not too many variants for possible calculations. The calculations made at runtime are then easier to understand.

To avoid formal division errors like divisions by zero for quotients as input-ready formulas, such as Average Price, use operator NDIV0. If no data has been planned yet for example, and the Master Data for Characteristic Relationships setting is used for a number of characteristics under Access Type for Result Values, a large number of empty data cells normally result. If you do not use data function NDIV0 here, the cells will not be input ready forAverage Price. If you do use NDIV0, however, you will get the calculation NDIV0( 0 / 0 ) = 0 for these types of cells, and Average Price can be changed.

General Rules for the %GT Percentage Function at Runtime

At runtime, an input-ready formula with the percentage function %GT(op), Percentage of Grand Total,   can only really be input ready if the op Operand is input ready at runtime.

For more information about general rules on how the “non-input ready” characteristic is inherited for subtotal, totals and hierarchy nodes, see SAP Note 994853.

For a detailed explanation of the rules, see the discussion of example 6, Percentage of Grand Total

in Examples: Inverse Formulas at Runtime.

Calculating the %GT Percentage Function in New Rows

The system also calculates inverse formulas in new rows. The produces changed values in the basic key figures: If rows already existed before, the system adds the changed values to the existing ones. There are no special checks for new rows.

 Examples: Inverse Formulas at Runtime  This chapter contains a number of examples that provide information about runtime aspects of inverse formulas. We assume that you can create input-ready and inverse formulas in Query Designer (see Input-Ready Queries, Examples: Inverse Formulas and Defining Inverse Formulas)

Example 1: Average Price

As in the documentation for defining inverse formulas in Query Designer, we will begin with the Average Price example. We assume that Sales andSales Quantity are restricted key figures (with the currency restricted to a value and an initial unit of measure for Sales and the opposite for Sales Quantity). In Query Designer, both restricted key figures use the Disaggregate Value Entered setting under Planning on Totals.

A data slice protects the products Comes after C++ and MMIX by D.E. Knuth.

As shown in the graphic below, the Tools totals row is not input ready, either for restricted key figures Sakes and Sales Quantity or for (input-ready) formula Average Price. The Average Price formula is not input ready here, as all operands of this formula are non-input ready.

Example 2: Formula inversion triggered by manual changes

We illustrate the general rules using the example of the input-ready formula Average Price (see Example 1 above).

We assume that the initial (asymmetrical) calculation mode is used.

Here is the Average Price carrier of the formula group that contains the following elements: Average Price, Sales and Sales Quantity. In Query Designer, the following inverse formulas have been defined:

13.        1.      ‘Sales’ = ‘Average price’ * ‘Sales Quantity’14.        2.      ‘Sales Quantity’’ = NDIV0( ‘Sales’ / ‘Average Price’ )

10.                             a.      We assume that the value for Average Price has been changed. Both inverse formulas can be used for the formula inversion. The system takes the formula with the highest formula priority, in this case the Sales formula.

11.                             b.      We assume that the values for Average Price and Sales have been changed. In this case, it is clear that the system has to calculate theSales Quantity formula.

12.                             c.      We assume that the value for Average Price has been changed and that the Sales cell has been fixed. In this case, it is clear that the system has to calculate the Sales Quantity formula.

13.                             d.      We assume that the value for Average Price has been changed and that the Sales cell is not input ready, for example because this key figure is protected by a data slice. In this case, it is clear that the system has to calculate the Sales Quantity formula.

14.                             e.      We assume that the values for Sales or Sales Quantity have been changed. In this case, inverse formulas do not come into play. The system calculates the Average Price.

15.                               f.      We assume that the value for Sales has been changed and that the Average Price cell has been fixed. In this case, it is clear that the system has to calculate the Sales formula.

We assume that the symmetrical calculation mode is used.

Here is the Average Price carrier of the formula group that contains the following elements: Average Price, Sales and Sales Quantity. In Query Designer, the following inverse formulas have been defined, and the carrier formula has the lowest priority:

15.        1.      ‘Sales’ = ‘Average price’ * ‘Sales Quantity’16.        2.      ‘Sales Quantity’’ = NDIV0( ‘Sales’ / ‘Average Price’ )17.        3.      ‘Average price’ (carrier formula)

16.                             a.      We assume that the value for Average Price has been changed. Both inverse formulas can be used for the formula inversion. The system takes the formula with the highest formula priority, in this case the Sales formula.

17.                             b.      We assume that the values for Average Price and Sales have been changed. In this case, it is clear that the system has to calculate theSales Quantity formula.

18.                             c.      We assume that the value for Average Price has been changed and that the Sales cell has been fixed. In this case, it is clear that the system has to calculate the Sales Quantity formula.

19.                             d.      We assume that the value for Average Price has been changed and that the Sales cell is not input ready, for example because this key figure is protected by a data slice. In this case, it is clear that the system has to calculate the Sales Quantity formula.

20.                             e.      We assume that the values for Sales have been changed. This triggers calculation of the formula group. Because Quantity has higher priority, Average Price is kept, and an inverse calculation is performed on Quantity.

21.                               f.      We assume that the values for Quantity have been changed. This triggers calculation of the formula group. Because Sales has the highest priority, Average Price is kept, and an inverse calculation is performed on Sales.

22.                             g.      We assume that the value for Sales has been changed and that the Average Price cell has been fixed. In this case, it is clear that the system has to calculate the Sales formula.

Example 3: Overlapping formula groups

In this example, we use three restricted key figures Sales Plan, Sales Forecast and Sales Actual. We also want to plan the percentage deviation of planned sales from forecast sales and planned sales from actual sales. We therefore create two input-ready formulas and the corresponding inverse formulas.

The input-ready formula for calculating the percentage deviation of planned from actual sales is as follows:

%Dev (P,A) = NDIV0( ‘Sales Plan’ % ‘Sales Actual’ )

The elements of this formula group are ‘%Dev(P,A)’, Sales Plan and Sales Actual.

The input-ready formula for calculating the percentage deviation of planned from forecast sales is as follows:

%Dev (P,A) = NDIV0( ‘Sales Plan’ % ‘Sales Forecast )

The elements of this formula group are ‘%Dev(P,F)’, Sales Plan and Sales Forecast.

Both formula groups contain the element Sales Plan. We assume that Sales Actual and Sales Forecast are not input ready, for example because the forecast was prepared by the planning administrator. In this case, the following elements are input ready: Sales Plan, ‘%Dev(P,A)’ and ‘%Dev(P,F)’. The system only requires inversions from ‘%Dev(P,A)’ to Sales Plan and from ‘%Dev(P,F)’ to Sales Plan.

Product %Dev (P,F) %Dev (P,A) Sales Plan Sales Forecast

Sales Actual

PC Medium 0 10  →  20 110 110 100

PC Small 0  →  10 10 220 220 200

PC High End 0  →  10 10  →  20 330 Error 330 300

Total 0 10 660 660 600

Manual entries are represented by an arrow (→). To provide greater transparency, this table contains all of the three examples that will be explained below. However, this does not mean that the changes were made in a single interaction step.

18.        1.      If you change ‘%Dev(P,A)’ for ‘PC Medium’, the system first calculates the Sales Plan in the PAI (process after input) and then calculates the percentage deviation ‘%Dev(P,F)’ in the PBO (process before output).

19.        2.      If you change ‘%Dev(P,F)’ for ‘PC Small’, the system first calculates the Sales Plan in the PAI and then calculates the percentage deviation ‘%Dev(P,A)’ in the PBO.

20.        3.      If you change ‘%Dev(P,A)’ and ‘%Dev(P,F)’ in a single step for ‘PC High End’, the system attempts to calculate ‘Sales Plan‘. This is possible for one formula group. For the other formula group, however, the system also attempts to reconcile Sales Plan at the same time. This produces an error, as the other key figures are not input ready and therefore cannot be changed by calculating inverse formulas. 

Apart from if you get the error described under 3, you will get the following result:

Product %Dev (P,F) %Dev (P,A) Sales Plan Sales Forecast

Sales Actual

PC Medium 9.09 20 120 110 100

PC Small 21.00 10 242 220 200

PC High End 0.00 10 330 330 300

Total 4.84 15.34 692 660 600

Example 4: Nested formula groups

In this example, we want to plan costs for a number of cost centers. We assume that we have two key figures: Fixed Costs and Variable Costs. Fixed Costs is not input ready, as we assume that we cannot influence these costs in this example. Variable Costs are planned. The total costs are the fixed costs plus the variable costs. We already have the total costs from the previous year in a restricted key figure Costs LY.  The fixed and variable costs in this do not interest us. What we would like to do, however, is to plan the percentage deviation of the total costs from the total costs in the previous year. To do this, we can form two input-ready formulas:

‘Total Costs = ‘Variable Costs + ‘Fixed Costs’

The elements of this formula group are Total Costs, Variable Costs and Fixed Costs.

The other input-ready formula is:

‘%Dev(T, LY) = ‘Total Costs’ % ‘Costs LY’

The elements of this formula group are ‘%Dev(T,LY)’, Total Costs and Costs LY.

The two formula groups are nested with each other, as the Total Costs formula is also used in the ‘%Dev(T,LY)’ formula.

Cost Center %Dev (T,LY) Total Costs Variable Costs

Fixed Costs Costs LY

4711 10 110  → 120 100 10 100

4712 10  → 20 220 200 20 200

4713 10  → 20 330  → 400 300 Error 30 300

Total 10 660 600 60 600

Manual entries are represented by an arrow (→). To provide greater transparency, this table contains all of the three examples that will be explained below. However, this does not mean that the changes were made in a single interaction step.

21.        1.      If you change the Total Costs for cost center 4711, the system first calculates the Variable Costs in the PAI and then calculates back to theTotal Costs and the percentage deviation with the previous year ‘%Dev(T,LY)’ in the PBO.

22.        2.         If you change the percentage deviation with the previous year ‘%Dev(T,LY)’ for cost center 4712, the system first calculates the Total Costs in the PAI, as the formula is input ready. This implicit change triggers the next formula inversion. In the result, the system also calculates

theVariable Costs in the PAI. In the PBO, the system then calculates back to the Total Costs and the percentage deviation with the previous year ‘%Dev(T,LY)’.

23.        3.         If you change the percentage deviation with the previous year ‘%Dev(T,LY)’ and the Total Costs for cost center 4713 in a single step, the only input-ready operand of formula ‘%Dev(T,LY)’ will change too at the same time. This means that formula inversion is not possible for the percentage deviation with the previous year ‘%Dev(T,LY)’. The system displays error messages informing you of this.

Apart from if you get the error described under 3, you will get the following result:

Cost Center %Dev (T,LY) Total Costs Variable Costs

Fixed Costs Costs LY

4711 20 120 110 10 100

4712 20 240 220 20 200

4713 10 330 300 30 300

Total 15 690 630 60 600

Example 5: Calculating inverse formulas and disaggregation

In this section, we will look at an even more complex example, where we change multiple values at various levels of the result set in a single step. We assume that the formulas has the highest priority.

 ‘Sales Quantity’’ = NDIV0( ‘Sales’ / ‘Average Price’ )

As shown by the arrows (→) in the table below, certain numbers on various summation levels were changed in a single step. Note that the system calculates the inverse formula for all levels first and then disaggregates changed or calculated values to the basic key figures.

Product Sales Quantity Average Price

PC Medium 4000.00 3 1333.33  → 800

PC Small 4000.00 4  → 3 1000.00  → 500

PC High End 4000.00 3 1333.33

Total 12000.00 10 1200.00  → 1000

These changes trigger the following calculations:

Product Sales Quantity Average Price

PC Medium 4000.00 (temporarily fixed)

4000.00 / 800 (priority) 1333.33  → 800

PC Small 3 * 500 4  → 3 1000.00  → 500

PC High End 4000.00 3 1333.33

Total 12000.00 (temporarily fixed)

12000.00 / 1000 (priority)

1200.00  → 1000

The intermediate result is as follows:

Product Sales Quantity Average Price

PC Medium 4000.00 (temporarily fixed)

5 (calculated) 800 (changed)

PC Small 1500 (calculated) 3 (changed) 500 (changed)

PC High End 4000.00 3 1333.33

Total 12000.00 (temporarily fixed)

12 (calculated) 1000 (changed)

The Sales Quantity column contains a changed Totals value and changes to values on lower levels. The system therefore starts the disaggregation of 12 – ( 5 + 3 ) = 4 for the one unchanged value of product ‘PC High End’.

As a result of calculations in the various rows, the Sales column contains temporarily fixed values and a changed value. The system therefore starts the disaggregation of 12000 – ( 4000 + 1500 ) = 6500 for the one unchanged value of product ‘PC High End’.

The result of the calculation of the inverse formulas and the disaggregation is as follows:

Product Sales Quantity Average Price

PC Medium 4000.00 5 800.00

PC Small 1500.00 3 500.00

PC High End 6500.00 4 1625.00

Total 12000.00 12 1000.00

Example 6: Percentage %GT

We provide an explanation of the runtime aspects of the percentage %GT example (see Examples: Inverse Formulas, Example 2).

We assume that the amount is a basic key figure whose distribution type for disaggregation is Analog Distribution (Self-Reference).

A data slice protects the products Comes after C++ and MMIX by D.E. Knuth.

As shown in the graphic below, the total in the Percentage of the Amount with Regard to the Total (% Contribution) is not input ready, as the corresponding value is always 100%. All other cells are input ready, with the exception of the values for Comes after C++ and MMIX by D.E. Knuth and the subtotals for these products. The basic key figure Amount is protected by a data slice. In the result, input-readiness is also deactivated forPercentage (% Contribution): The “non-input ready” characteristic was inherited by the %GT formula from the Amount operand. The “non-input ready” property was also inherited from the Tools subtotal, as all children of this hierarchy node are non-input ready.

The value of %GT for the total is always 100%; meaning that the total result is not input ready. The value for %GT therefore remains at 100% if you use a filter (on the axis) for Personal Computer. Calculations with %GT are still possible if no subtotals, totals or hierarchy nodes are displayed. It is also possible to hide key figure op - Amount in our example. Operand op – Amount  in our example – must be input ready though.

If both operand op – Amount in our example – and %GT are changed for the same level in a single interaction step, the system displays an error message. On the other hand, it is possible to change the total for op (Amount) and the values for %GT at a deeper level. In this case, the system takes the new value for grand total and the changed %GT value to calculate the new value for operand op (Amount) at the deeper level. These two changes trigger a disaggregation for operand op - Amount..

The grand total for Amount must not be zero. If it is, %GT cells are not input ready.

Values for %GT can also be outside the range 0 to 100, which generally produces negative values for the operand - Amount – after disaggregation.

 Cell Fixing 

UseTo lock input-ready cells against manual changes in planning applications, you can fix these cells. Cell fixing is a time-limited setting that only affects the current user session. Fixed cells are displayed with

the standard lock symbol  . The user can also undo cell fixing.

When working with input-ready and inverse formulas, it can be a helpful to fix cells (see Input-Ready Queries, Examples: Inverse Formulas and Inverse Formulas).

If disaggregation is used in a query, fixing a cell can help you to fix the values of higher or lower levels while manually changing other values (seePerforming Manual Planning and Disaggregation (Top-Down-Distribution)).

If you use cell fixing in an input-ready query for disaggregation, we recommend modeling hierarchical relationships by exclusively using BW hierarchies or subtotals and totals in characteristics in the drilldown. You should not use structure elements defined as hidden “hierarchies” in Query Designer for modeling.

IntegrationThere are two implementations of the cell fixing function. These are local cell fixing in the query (front-end cell fixing) and global cell fixing in a Web template (back-end cell fixing):

Local Cell Fixing in a Query (Front-End Cell Fixing)

Cell fixing is managed exclusively in the BI Java runtime for the current result set. Cell fixings remain in effect so long as no significant changes are made to the result set. The back-end system only recognizes the cell fixings during the server roundtrip and can thus take them into consideration in case of inverse formulas and disaggregation. 

Global Cell Fixing in a Planning Application in a Web Template (Back-End Cell Fixing)

Cell fixing is managed exclusively in the back-end system for all input-ready queries in the planning application. This makes it possible for a cell that is fixed in a query to be displayed as fixed in other queries that belong to the planning application and to be treated as such. 

More InformationFor more information about the two cell fixing methods, as well as the restrictions and modeling recommendations, see Local Cell Fixing in a Query (Front End) and Global Cell Fixing in a Planning Application (Back End).

 Local Cell Fixing in a Query (Front End) 

UseYou can lock, in other words “fix”, input-ready cells against manual changes in BEx Web Applications. These cell fixings are managed as local settings with reference to the current result set in the BI Java Web runtime.

This function is only implemented in the BI Java Web runtime, in other words in Web applications created using BEx Web Application Designer (WAD).

Planning functions and planning sequences ignore the cells fixed in the web at runtime. This means that fixed cells can be changed by planning functions and planning sequences however.

FeaturesCell fixings in a query remain in effect so long as the user does not make any significant changes on the result set. The user can then therefore perform the following activities without losing the cell fixings:

●      Sorting

●      Expanding or collapsing nodes in BW hierarchies

●      Changing display settings for characteristics

If the user performs one of the following activities though, the cells fixings are undone:

●      Calling the variable screen to change variable values,

●      Drilldown, removing the drilldown

●      Swapping row and column axes, swapping characteristics

●      Hierarchical axis display

●      Suppressing zero

●      Setting a filter

As cell fixing is a local setting that relates to the current result set, a cell fixed at runtime in the data model of the query is not known to the system. This means that a fixed cell is not comparable to a cell protected by a data slice. For the back-end system, a fixed cell behaves like a cell has been transferred without the value being changed.

The following restrictions therefore apply:

Fixed is a local property of the cell in the current result set. If the fixed cell shares data records with other cells, the fixed property is not applied to the other cells. For example, if two cells use the same data records and one of the cells is fixed, the other cell is not fixed. This point is particularly relevant for queries, in which a type of “hierarchy” is created from restricted key figures, as in the following example:

Revenue Jan. is modeled as the key figure Revenue, which is restricted to 1.2009 by the selection of the time characteristic.

Revenue Q1 is modeled as the key figure Revenue, which is restricted to 1.2009 - 3.2009 by the selection of the time characteristic.

If Revenue Jan. is fixed and Revenue Q1 is changed, the system would not account for the fixed property when distributing the value of Revenue Q1between the different months.

Therefore we recommend that you work with BW hierarchies when using fixed cells (as is the case with disaggregation). More information: SAP Note 994853.

ActivitiesYou can fix a cell by choosing Lock Cell in the context menu. It is also possible to fix/unlock an entire row or column using the corresponding commands in the context menu.

As an alternative, you can use the following URL parameter to set the cell fixing function at runtime: MENU_CELL_LOCKING = X. You can either insert the parameter directly into the URL of the Web application or set it in Web Application Designer in the XMHTL view (XHTML tab).

More InformationFor more information about cell fixing, see Cell Fixing and Global Cell Fixing in a Planning Application (Back End).

Global Cell Fixing in a Planning Application (Back End) 

UseGlobal cell fixing in a planning application is particularly suitable if a Web template contains multiple queries on multiple tab pages in the planning application, and these queries are closely linked but are used for different aspects of the planning application.

Goods planning in the retail environment is generally performed by planning multiple key figures in a certain logical sequence. This means for example that sales could be planned first, followed by price markdowns, goods receipt and finally the gross result. From the point of view of planning, these planning key figures are normally grouped in a logical sequence by corresponding query views on tab pages in the planning application, for example with query views for sales, price markdowns, goods receipt and the gross result. In most cases, the planned values for sales should be retained during planning on all tab

pages, while the other key figures are calculated and changed. If the user is satisfied with his/her sales planning, s/he will then fix these values and plan other key figure values. These fixed sales values must remain unchanged if the user navigates between tab pages (in other words between queries) in the planning application.

To guarantee that the system does this, cell fixings must be managed by the back-end system, since all objects involved in the definition of a cell need to be considered. Global cell fixing in a planning application allows more navigation steps in a query while retaining the cells fixings as local cell fixing on the front end and retaining the fixing for a cell in multiple queries in a planning application.

Defining Cell FixingsCell fixings are created for the current user session and are not persisted. When the planning application is restarted, no cells are fixed any more.

Depending on the position of the cursor, a user can fix a cell, a row or a column. Only input-ready cells can be fixed. Once they have been fixed, they cannot be changed manually any more. Cells that contain aggregated values are not fixed automatically if only fixed cells have gone into them.

You can fix all cells that contribute to a subtotal for example, but the system does not automatically fix the subtotal. Manually changing this subtotal will produce an error during the next server roundtrip however.

If cells have been fixed or if cell fixings have been deleted using the corresponding option in the context menu, the next server roundtrip transports this information to the back-end system. In the back-end system, the system translates the fixings into a format that is independent of the query, thus making it possible for cells with exactly the same definition to be fixed in other queries as well. Certain other properties of the query also need to be comparable, for example the filter used and certain characteristic properties.

Criteria for Matching the Fixing Context of the Query Views

Fixed cells are managed on the back end in accordance with their fixing context. A fixing context consists of the following information:

       1.      The query’s effective filter, in other words the intersection of the filter in the query definition and the dynamic filter

       2.      The sequence of characteristics on the query’s axes, and the following settings:

23.                             a.      Result display: always, never, with more than one value.24.                             b.      Using the BW hierarchy; setting for whether or not the hierarchy display is active.

We refer to these properties as the list geometry.

This basically means that the back-end server creates a fixing context when a cell is fixed. This fixing context contains the effective filter and the list geometry of the current query view. To be able to contain cell fixings of their own, all query views in a planning application must be compatible with this fixing context. If any query views in the planning application do not match – even just one - the system deletes all cell fixings.

Criteria for Matching Structure Elements of Queries

A further condition is that the definition of structure elements of queries that are based on a fixed cell must match.

The following input-ready structure elements of a query can form the basis of a fixed cell:

●      A basic key figure

●      A restricted key figure

●      A formula

Two structure elements match if all of the following properties are identical:

●      If the structure elements are basic or restricted key figures, the following properties must match:

○       The key figures must be the same.

○       The input-readiness setting must be set for both key figures.

○       The restrictions made for the key figure must be identical.

○       The disaggregation settings must be identical.

●      If the structure element is a formula, the formula definition must be identical, meaning that the formula expression edited in Query Designer is the same in terms of the operands, brackets,

data functions, variables, exception aggregation used, and in terms of the sequence of operands in the formula.

Managing Cell FixingsAs explained above, the back-end system manages the fixed cells in terms of their fixing context. A cell fixing based on a basic key figure or restricted key figure is also always assigned to a real-time enabled InfoCube via the aggregation level used in the input-ready fixed cell.

A fixed cell on an input-ready formula is assigned to the InfoProvider that was used in the query definition. The fixed cells on an input-ready formula can therefore only be used in other queries if these queries were defined on the same InfoProvider.

If the user performs any of the following activities, cell fixings are retained:

●      Display the properties of the characteristics (like Key or Text)

●      Display attributes of the characteristics

●      Sort the result set by characteristic values, texts or key figures

●      Switch the row axis and the column axis

●      Expand or collapse nodes in BW hierarchies or universal display hierarchies

●      Activate and deactivate a universal display hierarchy

●      Hide/show structure elements (filter structure elements for example)

●      Drill down in a characteristic to the lowest point on the right in the rows and the furthest point inside in the columns

●      Remove a characteristic in the drilldown: at the lowest point on the right in the rows and the furthest point inside in the columns

Note that some of the operations listed above hide fixed cells. This does not undo the cell fixings however. These “hidden” cell fixings also remain active and are taken into account by the system when calculating inverse formulas and during disaggregation.

If the user performs any of the following activities, all cell fixings are deleted:

●      Change the order of the characteristics included in a cell fixing

●      Change the axis of the characteristic included in a cell fixing

●      Change the Display Result setting of the characteristic included in a cell fixing

●      Change the settings for BW hierarchies (on/off) for characteristics included in a cell fixing,

●      Change the query’s dynamic filter (by restricting the variable values without restarting the query, using the filter dialog for a characteristic from context menu option Keep Filter Value for example)

●      Change the filter using the variable screen

●      Perform a planning function or planning sequence

What this all basically means is that any query view changes that are not compatible with the cell fixing context will result in all cell fixings being lost. The system displays a list of messages with information about the incompatible settings.

Any incompatibility as described above will result in the deletion of all cell fixings in the planning application query where it occurs.

Modeling Recommendations

To make effective use of use global cell fixings in a planning application with more than one query, queries should be modeled in such a way that the cell fixings for a query are not deleted in other queries at runtime due to incompatibilities in other queries.

Accordingly, the fixing context and the filters of all input-ready queries in the Web template should match.

In a compatibility check of the fixing context, the system uses the effective filter of the other queries to calculate the intersection of the static and dynamic filters of the queries used in the Web template. For performance reasons, note that the back-end system does not check whether various definitions express the same thing. We therefore recommend always using the same modeling type.

Filters should use the same type of restrictions (a value list for example) in all queries.

If a BW hierarchy is used as a display hierarchy in a query, the same BW hierarchy should be used as the selection hierarchy in the query’s filter.

ActivitiesTo activate the global cell fixing on the back end, you need to set a parameter in table RSADMIN. You can use program SAP_RSADMIN_MAINTAIN to do this. Set the following parameter:

OBJECT = RSPLS_PQ_BACKEND_CELL_LOCKING

VALUE = X

Once you have activated the global cell fixing on the back end, the local cell fixing will not work any more on the front end.

More InformationFor more information about cell fixing, see Cell Fixing and Local Cell Fixing in a Query (Front End).

 Saving Changed Values If you save your data in a BW-integrated planning application, the system persists the data changed since the last save on the database. The changes to the data are posted, not the absolute values.

Logging Saved ValuesYou can use BAdI BADI_RSPLS_LOGGING_ON_SAVE from enhancement spot RSPLS_LOGGING_ON_SAVE to log data saved in a BW-integrated planning application. This logging can be implemented for real-time InfoCubes.

The BAdI is filter-dependent. Create an implementation of the interface IF_RSPLS_LOGGING_ON_SAVE for every real-time InfoCube that you want to log.

Methods log_defined and log_structure are used to specify whether or in which format the data

is provided. In method log_structure, you can specify that context information about the name of

the writing user, the date, the time and the SAVE ID are displayed using special InfoObjects in the DDIC structure. Using the SAVE-ID you can identify a ‘save’ action in a planning application.

If a user saves data three times in a planning application and describes two real-time InfoCubes while logging is active for both InfoCubes for example, the system therefore creates the three SAVE-IDs. These IDs can be passed to both logging calls of the two InfoCubes, if required. You can therefore identify in the logs of the two InfoCubes, which data from InfoCube1 was saved together with which data from InfoCube2.

Methods log_write calls the actual logging for every ‘Save’ event in the application that transfers the

data in the structure specified forlog_structure. The actual logging is implemented in

method log_write. In other words, the data is written to a transparent table. Besides the data, the

request ID of the real-time InfoCube (where the data is saved) is also passed to the method log_write.

The methods in this interface are described in detail in the interface documentation (see Class Builder, transaction SE24).

You can use statistics events 50098 and 50099 to measure the processing times (see Overview of Statistics Events (Table RSDDSTATEVENTS)).

Checking Data Before Saving with a Planning SequenceTo prevent users in a planning application from saving invalid changed data, you can run a report. For every “Save” event for a specific real time-enabled InfoProvider, this report ensures that a specific planning sequence runs, thus checking the data in this InfoProvider.

       1.      To use this function, call ABAP Editor (transaction SE38) and run report RSPLS_PLSEQ_MAINTAIN.

       2.      Enter the required InfoProvider. You can use input help for this.

       3.      Enter the planning sequence that checks the data to be saved for this InfoProvider. You can use input help for this.

       4.      In the default setting, Only Process Changed Records is selected.

       5.      Enter an aggregation level as the Delta Determination level. 

If the planning sequence reports an error, the data will not be saved.

Business Planning Portal Role 

UseIn the portal, the Business Planning portal role provides users with a central point of access to Business Intelligence content, which contains the various Business Planning tools.

Technical name of the portal role: com.sap.ip.bi.business_planning_showcase

PrerequisitesThe system administration for the portal has assigned you the role as a user.

FeaturesThe Business Planning role in the portal contains the following tab pages:

Overview

This initial page provides an overview of the content of this portal role. In addition, it enables a quick start to call the Planning Modeler with one or more specific objects. Enter the search term (InfoProvider, aggregation level, filter, planning function, planning sequence) and choose Start. The system calls the Planning Modeler with the associated search results in a new window in the portal.

Planning Modeler

The planning modeler is the main application for accessing, modeling, testing, and administrating all objects for which it is necessary to build a planning model in BI Integrated Planning.

Planning Wizard

The planning wizard helps you to quickly build a planning scenario. It leads you through all the necessary steps and includes a test environment for your newly created scenario. All objects created here can be changed and enhanced in the planning modeler.

BEx Web Analyzer

Using the BEx Web Analyzer, you can navigate in queries and analyze data. For more information,

see  BEx Web Analyzer.

With the BEx Web Analyzer iView, a BEx Web Application iView is called with the 0ANALYSIS_PATTERN Web template. The BEx Web Application Query Stringproperty

has the value bi_template =0ANALYSIS_PATTERN. For more information, see:  BEx Web Application or Query as iView in the Portal.

The BEx Web Analyzer iView references a system with system alias SAP_BW. This system alias must be maintained in the BI system in the system landscape of the portal so that the BEx Web Analyzer appears.

 Transport of Planning Objects You use the BI transport connection and BEx transport requests to transport planning-model objects

into another system (see Modeling Planning Scenarios).

For more information, see  Transporting BI Objects and  Transporting BEx Objects.

Variables and filters that you have created in the planning modeler behave like the corresponding query elements. You have transport object ELEM.

Unlike BEx objects, however, planning objects are written to the BEx transport request or requests, even if the standard transport system is switched on.

This applies to the following object types from the planning area:

●      ALVL aggregation level

●      PLCR characteristic relationship

●      PLDS data slice

●      PLSE planning function

●      PLSQ planning sequence

●      PLST planning function type

More information:  Transportable Object Types.

 Lock Concept and Lock Management 

UseWhen a user requests transaction data in change mode, this data has to be locked exclusively for the user. The data records that have to be locked are specified in a selection table. A data record is locked by the selection table if for each characteristic in the selection table, the characteristic value in the data record lies within the selection. It does not matter whether this data record is on the database.

The following rules apply:

●      All the records in the selection are locked.

●      If the selection table is empty, each data record is locked since no restrictions exist.

●      For characteristics outside the aggregation level, selection * (all) is always locked.

The selection table is as follows:

Characteristic Characteristic Value

Fiscal year 2006

Product P1 - P10

This table describes a selection. All the records within this selection are locked. This includes, for example:

Fiscal year Product

2006 P1 Both values are in the selection so the record is locked.

2006 P20 P20 is not in the selection so the record is not locked

2007 P1 2007 is not in the selection so the record is not locked

2008 P11 Neither component is in the selection so the record is not locked

ActivitiesSelection tables have to be stored and managed centrally for all users and application servers. The SAP standard lock server cannot manage locks that are based on selection tables. For this reason, you have to make BI-specific settings for storing locks that are described by selection tables.

You access the BI lock management setting in the SAP Reference IMG (transaction SPRO) or in lock setting maintenance for planning (transaction RSPLSE). Sizing of the lock table used is necessary in order to use BI Integrated Planning. The sizing depends on the location of the lock table.

When implementing BI Integrated Planning, we recommend that you use an optimized lock concept for your planning application. This involves modeling selections in the components of the planning application in such a way that in change mode, different users can edit different objects.

Note that after you upgrade to SAP NetWeaver 7.0, BW-BPS also uses the lock settings of BI planning. This changes the setting for storing the lock table, making a sizing of the lock table necessary. Alternatively, you can store the lock table in the SAP lock server since the sizing of this lock table is performed in the BW-BPS implementation project. You must make all settings as described in SAP Note 635244 (such as selection of the relevant lock characteristics) using transaction RSPLSE.

More InformationManagement of Lock Settings

Sizing of Lock Tables

 Management of Lock Settings 

UseYou would like to get information about lock management in order to be able to react with the appropriate settings.

To from the screen BI Integrated Planning to the administration of the lock server, choose   Manage Lock Server (transaction code RSPLSE). TheDisplay Planning Lock Settings screen appears.

PrerequisitesMake sure that you have the necessary authorizations. There is an authorization object for displaying and changing lock settings in planning: S_RS_PLENQ.

FeaturesIf you are in change mode, you can make the required changes in change mode on the Lock Table and Lock Characteristics tab pages.

Tab Page: Lock Table

Here you specify where the lock table is stored (see Storage of Lock Tables).

You can only change from display mode to change mode if there are no active locks for any InfoCubes, that is, if no transaction data of a planning application is locked for any InfoCube. This ensures that locked transaction data is consistent.

Tab Page: Lock Characteristics

Here you specify which characteristics are relevant for lock checks (see Selection of Lock Characteristics).

You can only change from display mode to change mode if there are no active locks for the selected InfoCube, that is, if no transaction data of a planning application is locked for any InfoCube. This ensures that locked transaction data is consistent. It could be difficult to find a time window for selecting the lock characteristics of a given InfoCube.

You can display the relevant information on the Locks, Lock Conflict and Master Locks tab pages.

Tab Page: Lock

Here you display the locks that are set for a specific InfoProvider and user (see Display of Active Locks).

Tab Page: Locking Conflict

The system displays information about the last lock conflict (see Analysis of Lock Conflicts).

Tab Page: Master Locks

You can display the master locks that are set and delete them here (see Display of Master Locks).

Storage of Lock Tables 

UseSelection tables have to be stored and managed centrally for all users and application servers. The SAP standard lock server cannot manage locks that are based on selection tables. You therefore have to make your own settings for storing locks that are described by selection tables.

The current locks are stored in a lock table. On the Lock Table tab page, you specify where you want to store the lock table. There are three options for storing the lock table. You can select a suitable server depending on the storage type.

FeaturesStoring Lock Tables on the SAP Standard Lock Server

The selection tables are compressed and stored on the SAP standard lock server.

The collision check for locks is not performed by the lock server, but by an ABAP program. This check requires the selection tables to be copied to the user context. The collision check is set by default on the server you are logged on to. If you select a different, fixed server instead, the collision check is performed there with an RFC call.

This can be advantageous if the enqueue process is installed on a different (fast) server, and not on the central instance in order to possibly speed up the copy process for selections from a lock table to the user context. The server with the enqueue process is marked as such in the server selection.

In SAP lock management (transaction SM12), you use table RSPLS_S_LOCK to display the compressed lock records. To find the actual locked selections, you need to call transaction RSPLSE (see Displaying Active Locks).

This option requires the least administrative effort. It is suitable for small and mid-size installations. You can set the size of the lock table using profile parameter enque/table_size.

Storing Lock Tables in the Shared Object Memory of an Application Server (Default System Setting)

The selection tables are stored in non-compressed form in a shared object memory area. This is the default value of the system unless you are using the SAP Standalone Engine Server, in which case the above option (store the lock table in the SAP standard lock server) is preset.

This area is bound to an application server. In this case, the SAP standard lock server only contains a pointer to the selection (one lock record for each selection table). You need to specify a server that contains the lock table in Shared Object Memory. The collision check is performed on this server. (The enqueue server is set by default.) Therefore it is not necessary to copy the selections from the lock table to the user context. If you are locked onto a different server, the collision check is performed there with an RFC call.

Here too it might be useful to install the enqueue process different (quicker) server than the central instance. This is because during a lock process, the selections in the shared object memory are synchronized with the pointers on the SAP standard lock server. This synchronization is performed fastest if the server with the enqueue process is the same as the server with the lock table. This option is therefore normally set by default.

In SAP lock management (transaction SM12), you find one lock record for each locked selection if using table name RSPLS_S_LOCK_SYNC. You can find the actual locked selections in transaction RSPLSE (see Displaying Active Locks).

This option provides better performance than storing the lock table in the standard SAP lock server. The lock table has to guarantee the availability of the server though if you want to lock transaction data using selections. You can set the size of the shared object memory with profile parameter abap/shared_objects_size_MB.

Storing Lock Tables in SAP liveCache

The selection tables are stored in SAP liveCache.

This option is only available if SAP liveCache is installed. The collision check is then also performed in SAP liveCache.

This option is intended for large installations where you need to lock a large number of complex selections. Only use SAP liveCache in the BW lock server (see SAP Note 816730) if explicitly requested by SAP Support or Development. The shared memory solution is much easier to activate and is normally sufficient.

Selection of Lock Characteristics 

UseOn the Lock Characteristics tab page, you can specify which characteristics are used for the lock check. In the default settings, all the characteristics and the artificial characteristic 1KYFNM for a real-time InfoCube are relevant for the lock check.

To reduce the size of the lock table, you can exclude characteristics from the lock check that do not serve to divide lock selections. These include characteristics which are the same for all users or which have overlapping values.

If no characteristics are selected as being relevant, the whole InfoCube is locked.

ActivitiesSelect Lock Characteristics

       1.      To switch to change mode, choose  .

       2.      Select an InfoCube. In the default settings, the Lock Characteristic Selection area of the screen is empty since all the characteristics are relevant.

       3.      Press the enter pushbutton. In the Lock Characteristics area of the screen, the system displays all the lock characteristics that are currently selected.

       4.      Remove any characteristics that are not relevant for the lock check from the Lock Characteristics area of the screen.

In cost center planning, the characteristics Fiscal Year, Version, Cost Center and Cost Element are being used. If a number of users are performing planning for the same year and the same cost elements, the characteristics Cost Center and Version are sufficient to ensure that the different users’ selections do not overlap. In this case, only choose these characteristics as lock characteristics.

Select Navigation Attributes as Lock Characteristics

In the default settings, navigation attributes are not relevant for lock checks. This means that they are always completely locked. In some cases it is useful to specify navigation attributes as lock characteristics to reduce the size of the selection tables. For example, this allows you to use selections based on a product group instead of selections based on an extensive list of products that belong to the product group. 

In expert mode, you can include navigation attributes in the list of lock characteristics. 

You use ok_code EXPERT to switch on expert mode and NOEXPERT to switch it off again.

Make sure that no navigation attribute values are changed during planning. Otherwise two different users may both edit the same values of the related basic characteristic and in doing so write new delta records.

User 1 plans product P1 which is in product group (navigation attribute) PG1. PG1 is selected in the selection table and there is no restriction for product. If the product group is used to set the lock, the following may occur:  User 2 plans product group PG2: User 1 starts planning first; the system locks the data. During this time, the attribute of product P1 is changed from PG1 to PG2. User 2 starts planning. Since PG2 is now technically different to PG1, there is no lock conflict. Both users can plan key figure values for product P1. 

Display of Active Locks 

UseOn the Lock tab page, you can see the selections that are currently locked for each InfoProvider and user. This is similar to the Select Lock Entriesfunction in SAP lock management (transaction SM12).

FeaturesTable Locks: Header Entries

The system displays the header entries for each locked selection (InfoProvider, User Name, Lock Mode, Lock Records, Lock Handle). The user name, number of records in the locked selection, and lock mode are of particular interest.

The following lock modes are available:

●      E (exclusive): Write lock that is used for all data that is edited in change mode; the data is locked and can be edited by one user only.

●      S (shared): Read lock that means that reference data for planning functions, for example, cannot be changed at runtime.

For more information about the lock modes, see  SAP Lock Concept.

The lock handle (a 32-character GUID) represents a locked selection.

Table Lock Records

The system displays the locked selections. The display is grouped by header entry (Lock Handle), Characteristic, type of interval (Interval) and the lower and upper interval boundaries of the selection (Internal Characteristic Value). The selections themselves are normally displayed in the lock table: For each characteristic, each selection is a disjunctive union of open, half open and closed intervals.

The type of interval can be:

●      ( ) for an open interval

●      [ ) or ( ] for a half open interval

●      [ ] for a closed interval

Activities       1.      Select the InfoProvider. The system determines all existing locks for the real-time InfoCubes that

are included in the InfoProvider (the aggregation levels or MultiProviders, for example).

       2.      Select the user. You can use wildcard searches as follows: ‘PRE*’ or ‘*ABC*’. In the Locks: Header Entries table and the Lock Records table, the system lists the active locks.

       3.      Notify the user and if necessary, delete the locks.

If you want to delete active locks, use SAP lock management (transaction SM12). Depending on where the lock table is stored, you may have to select a different lock structure.

■       Lock table on SAP lock server: Table name RSPLS_S_LOCK. ■       Lock table in shared objects memory: Table name RSPLS_S_LOCK_SYNC. ■       Lock table in SAP liveCache: Table name LCA_GUID_STR.

However, in SAP lock management (transaction SM12) you cannot see exactly which data records are locked. To see which individual data records are locked, use the maintenance transaction for lock settings in planning (transaction RSPLSE).

  Analysis of Locking Conflicts 

UseOn the Locking Conflict tab page, the system displays the selections for the last lock conflict. You get the following information about the context of the caller:

●      InfoProvider

●      User who requested a lock

●      User with lock (user who has already locked the selection).

●      Date and time of the lock query in the system time

●      Whether or not the lock conflict occurred with a master lock

ActivitiesTo identify the cause of the lock conflict, compare the selections in tables Selection in Lock Request and Locked Selection. A lock conflict occurs if selections overlap.

 Display of Master Locks 

UseYou use master locks to ensure that complex planning sequences do not terminate because of lock conflicts with other users. On the tab Master Locks you can display and delete the master locks that are currently set.

Master locks are set at runtime by planning sequences at InfoCube level and linked to the process chains as steps. Before processing the data, the system determines all required selections. The system first tries to set a normal lock for these selections. If this is possible, these selections are saved as master locks and the normal locks are removed. After this, no user can change data within this area.

The process chain itself normally runs in the background. Individual subprocesses can be authenticated as master locks and only these are permitted to pass the master lock. At the runtime of the planning sequences, the data that is to be edited is protected by normal locks, as usual. Once the process chain has processed the data, the master locks are removed.

IntegrationMaster locks are only set by planning sequences in process chains.

FeaturesTable Master Locks: Header Entries

The master locks set by a process chain are assigned a lock handle. The system displays the header entries for each locked selection (Lock Handle, InfoCube, Process Chain, Process Variant).

Table Lock Records

The system displays the locked selections for the lock handle. The display is grouped by header entry (Lock Handle), related selections (Number of Selection Table), Characteristic, type of interval (Interval) and the lower and upper interval boundaries of the selection (Internal Characteristic Value). The selections themselves are normally displayed in the lock table: For each characteristic, each selection is a disjunctive union of open, half open and closed intervals.

The type of interval can be:

●      ( ) for an open interval

●      [ ) or ( ] for a half open interval

●      [ ] for a closed interval

Activities       1.      Select an InfoProvider. The system determines all existing master locks from the real time-

enabled InfoCubes or aggregation levels and shows them in the overview.

       2.      To delete a master lock, delete the corresponding row in the table Master Locks: Header Entries.

Even if you delete master locks, the transaction data is protected at runtime by normal active locks. Without the master lock, it might not be possible to execute parts of planning sequences due to lock conflicts with other users.

 Sizing of Lock Tables 

UseFor a real-time InfoCube, the BI lock server cannot be accessed for the duration of a lock operation. Space on the lock server is restricted. When you implement planning applications in a BI system it is therefore necessary to choose a design that keeps the number and size of the selections as small as possible. The smaller the lock table, the better the response times of the lock server.

You can reduce the size of the lock table by removing characteristics from the list of lock-relevant characteristics in a real-time InfoCube if these characteristics do not serve to divide the selection. These include characteristics which are the same for all users or which have overlapping values. For more information, see Selection of Lock Characteristics.

The following sections contain information about the sizing of the lock table for BI Integrated Planning. These sections explain how you calculate the required memory and set profile parameters accordingly.

For more information about the different options for storing lock tables, see Storage of Lock Tables.

For current sizing information, see SAP Note 928044, BI lock server.

IntegrationIn profile parameter maintenance (transaction RZ11), you can display the values that are set currently.

 Performance Tips SAP Note 1056259 contains an overview of how you can significantly improve the system performance by using a suitable customizing and design for BI Integrated Planning. The Note discusses the following topics in detail:

       1.      Background knowledge of the architecture of BI planning

       2.      Important values that affect performance

       3.      Recommendations for modeling

       4.      Availability of optimizations