Multi-Planning Area
Definition
A planning area that combines the characteristics and keys figures of several basic planning areas. A multi-planning area also contains the characteristic planning area. This is created automatically and can be used to identify and select all the basic planning areas combined in the multi-planning area. The technical names of the basic planning area are valid values for this characteristic. When the system reads the transaction data it fills this field automatically with the technical name of the planning area from which the data record was read. Consequently, you are also able to use non-transactional InfoCubes.
Characteristics that do not exist in a basic planning area but exist in the level of a multi-planning area are handled in the following way: When reading, the system checks whether the initial value for this characteristic is permitted in the selection condition of the planning level or planning package.
· If the initial values are contained in the selection condition, the data records are read from the basic planning area and transformed into records for the multi-planning area. The initial value is assigned to characteristics and key figures that are not available.
· If the initial values are not contained in the selection condition, no basic planning area data records are read.
If a planning function is to generate values that are not the same as the initial value for characteristics that are not available in the basic planning area, an error message is produced.
A multi-planning area does not contain any data of its own.
Use
Accessing Data in More Than One InfoCube
You use multi-planning areas in order to access data from two or more InfoCubes simultaneously. It is not a problem if the InfoCubes have different data models (also see Data Modeling: Key Figure Model and Account Model). The multi-planning areas are especially useful if you want to read data from one planning area and write it to another.
You want to plan resources for the sales department in your enterprise. The BW system that you are using as a data basis for BW-BPS contains one InfoCube with personnel data and one with sales data. To use the personnel data and the sales data at the same time, even though it is split into separate InfoCubes, create a multi-planning area. You then assign two basic planning areas to the multi-planning area. The two InfoCubes are already assigned to these basic planning areas.
Accessing Data in One InfoCube from More Than One Multi-Planning Area
You can also use multi-planning areas to get around a restriction to the basic planning areas: In the BW-BPS planning environment you are not permitted to assign the same InfoCube to more than one planning area. However, if you require a multiple assignment of this type for a particular reason, first create a basic planning area and assign the relevant InfoCube to it. To access the InfoCube, you can create as many multi-planning areas as required and assign the basic planning area you have created to them.
Reporting from Transactional InfoCubes
You have various options for displaying the data that you have planned in transactional InfoCubes.
· You can read the data straight from the transactional InfoCube.
· You can transfer the data from the transactional InfoCube into a basis InfoCube and display it there.
As the part of the data in the transactional InfoCube is located in an open request (which is therefore “yellow”), the query does not read the most up-to-date data by default. So that all the data is read you have to set a variable for the Request ID characteristic to the value Most Current Data in the query.
The following table offers an overview of the advantages and disadvantages of this type of reporting:
Reporting from Transactional InfoCubes
PRO |
CONTRA |
· Data is always up to date. · Data is always held in one place so there is no redundant data. |
· Aggregates are not always up to date as data is often changed during planning. · If you have an Oracle database, you are not able to use the usual BITMAP indexes for the F table. Concurrent locks may be set if several users update data at the same time. Therefore the system uses the BTREE indexes which are somewhat slower. |
Reporting from Basis InfoCubes
PRO |
CONTRA |
· You are always able to access up to date aggregates. · If you have an Oracle database, you are able to use the usual, quicker BITMAP indexes for the F table. |
· Data is not always up to date. · Data is always held in two places so there may be redundant data. |
Maintaining Multi-Planning Areas
You edit multi-planning areas just like normal (basic) planning areas: You create planning levels, define planning packages and planning functions, and execute these functions. Changes that you make to any data for a basic planning area, which is referenced by a multi-planning area, are automatically visible in the multi-planning area too, and vice versa. You can work with a multi-planning area and its underlying basic planning area simultaneously.
As a multi-planning area contains all the characteristics and key figures of the basic planning area, as well as the characteristic planning area, more main memory space and more CPU time is used than when working with basic planning areas. You can improve performance by reducing the size of the planning buffer. In this regard:
§ only use as many basic planning areas in a multi-planning area as are strictly necessary
§ execute planning functions that only affect one basic planning area directly in the basic planning area
Structure
A multi-planning area contains all the characteristics and key figures of those planning areas that are combined in the multi-planning area, as well as the planning area characteristic, which is generated by the system automatically. This characteristic enables you to assign key figures to a particular basic planning area. BW-BPS ensures that this characteristic is always selected. You can also use the planning area characteristic to read data from one planning area and write it to another. To do this, you create a planning function (for example, of type copy) and include planning area in the list of fields to be changed. Then, in a parameter group for the function, you determine which planning area the data is to be written to.
The procedure described above for cross-planning-area data processing is the only way to get around the fact that planning functions are restricted to the data in their own planning areas.
As well as using the copy function in a multi-planning area, you can transfer data from one InfoCube to another using a data mart or data staging. The following table offers a concise overview of the advantages and disadvantages of the two techniques:
Data Staging
PRO |
CONTRA |
· The server requires less memory capacity as there is no buffer. · Instead of having to recreate the database indexes of the database table after each data record transfer, you can save time by: § ... § ... a. deleting the database indexes b. transferring data c. recreating the database indexes · The data staging process is quicker than executing a planning function. |
· As you are using a transactional InfoCube as the target, you have to switch this from Planning enabled to Load enabled before you start the data staging process and then reverse it again after. |
Copying to the Multi-Planning Area
PRO |
CONTRA |
· The copy function is very easy to set up. If data has to be changed during the transfer process you can use the FOX formulas. · If data cannot be saved in the target InfoCube, you receive a detailed error message. · You do not have to switch between Planning enabled and Load enabled in the transactional InfoCube and can therefore continue planning while copying takes place. · You can use the additional features in the planning environment, for example, the flexible selection of data to be transferred using variables or derivations. |
· The server requires a lot of memory capacity as all of the data to be copied is located in the planning buffer. When saving, you have to refresh the indexes of the database table after each data record. |
Integration
In order to work with multi-planning areas you must first have created basic planning areas. You cannot delete a planning area that is referenced by a multi-planning area.
You can only change the composition of the basic planning areas that make up a multi-planning area until you save the multi-planning area. This is similar to the restriction with basic planning areas. You cannot subsequently change their assignment to an InfoCube.
Make sure that the technical settings for the characteristics and key figures in the various InfoCubes are the same, if:
...
1. you are using the same characteristics or key figures in different planning areas and
2. these planning areas are in different systems.
See also:
Multi-Planning Area: Application Examples