Multi Planning Areas and InfoCube in SAP BW

Multi-Planning Areas (or Multi-Area) in the SAP BW and BPS are a tool to integrate data from different Basic Areas and thus Info Cubes within one planning area. This enables you for example to copy data from one planning area to another planning area easily within the BPS or to use plan and actual data from different Info Cube in one layout or planning function.A Multi-Area contains all characteristics that are contained in any of the Basic Areas within the Muliti-Area plus an additional characteristic „planning area“. Using this characteristic you can specify from which Basic Area you want to read data or where you want to write data back to.

Thus you can also use basic non transactional Info Cubes within the BPS as you can make sure that no data is posted back to these Info Cubes. A typical example for such a situation is if you want to do a plan/actual comparison. You can also use Multi-Areas to transfer and convert data from one Info Cube using the key figure based model into an InfoCube using the account based model and back. Another example for the use of Multi-Areas is the volume times price calculation given in the last slide.When you are using the same characteristics or key figures in two different planning areas you want to use in a Multi-Area and if these planning areas reside on different systems make sure that the technical settings for the characteristics and the key figures are the same in both Info Cubes.

As the records within a Multi-Area contain all characteristics of all the areas contained in the Multi-Area (plus the additional characteristic for the planning area) the records in a Multi-Area require more memory. Because of that and because of the additional work the system has to do planning functions in a planning area are a little slower than in a basic area. In order to keep the buffer size small and speed up the system you should:

Make sure that you only use a reasonable number of basic areas in a Multi-Area.Rather than use a Multi-Area to run planning functions that only access one basic area just use the basic area.

Plan Data and Actual Data – what are the options?

In a planning scenario you usually need actual data for a plan/actual comparison or for generating a starting value for this year‘s planning by copying last year‘s actual data.There are two ways to bring actual and plan data together within the BPS:

either you physically copy the actual data into the planning Info Cube or you access the data in the actual Info Cube(s) via Multi-Areas. Which approach is better? It depends…

Physical Copy:

Advantages:

If the actual data is on another granularity than the plan data or in another data model you can fit the data to the structure of the plan data using transfer/update rules or Fox formulas when copying the data.Planning and reporting can be done without influencing each other.

Disadvantages:

Data redundancy.
Read data using a Multi-Area:

Advantages:

No data redundancy, less physical memory is needed.

Disadvantages:

Data structure in planning and reporting must be similar.Multi-Areas are a little slower than basic areas.

Copy in Multi-Area versus Data Staging

If you want to transfer data from one Info Cube into another in the planning environment you can use the staging process or a copy function in a Multi-Area. What is the best way? It depends on the situation. You can use both provided that the target InfoCube is a trans-actual Info Cube. Here are some advantages and disadvantages of the two methods:

Data Staging:

Advantages:

Less memory is needed on the server as no buffering mechanism is used.Before writing into the data base you can drop the data base indices, write the data and then build up the indices again. This is faster than updating the indices after each record.The process is faster than a planning function.

Disadvantages:

As you use a transactional Info Cube as target you have to switch it to "load enabled" before the staging process starts and back to "planning enabled" afterwards. During that time and during the load process nobody can do planning on the Info Cube.

The scenario is more complex to set up.
Copy/Multi-Area:

Advantages:

A copy function is vary easy to set up. If the data has to be modified during the transfer process you can use FOX formulas that are very powerful and easier to understand/maintain than update/transfer rules.

Error handling – you get detailed error messages if the data cannot be saved in the target Info Cube. You do not have to set the plan/load switch in the Info Cube and thus can also do planning during the copy process.You can use the additional features of the planning environment such as a flexible selection of the data to be transferred via variables or derivation .

Disadvantages

As the planning buffer holds all records that are copied this scenario needs more memory.Because of the "overhead" in the planning and of the necessity to update the data base indices after each record when saving the data this approach is less performing.

Reporting from Transactional Info Cubes

You have different options to report the data you have planned in the transactional Info Cube.You can either read the data directly from the transactional InfoCube or transfer the data from the transactional InfoCube into a basic InfoCube and report the data from there. Both ways are possible and have their advantages and disadvantages.As the part of the data in the transactional InfoCube is contained in an open (and thus "yellow" request) the query will by default not read the latest data. Thus in order to see the latest data you have to set in the query a variable for the characteristic "Request ID" to the value "Most Current Data".

Reporting from the transactional Info Cube:

Advantages:

The data is always up to data.
The data is only held once so you do not have any data redundancy.

Disadvantages:

As the data is changed frequently in the planning the aggregates are not always up to data (performance).When using an Oracle data base one cannot use the usual BITMAP indexes for the table of uncompressed requests ("Ftable"). This would cause deadlocks when several users update data simultaneously. Therefore the system uses somewhat slower BTREE indexes.Moving the data to basic Info Cube and reporting from there.

Advantages:

You can use aggregates that are always up to data.
When using an Oracle data base you can use the faster Bitmap index.

Disadvantages:

The data is not always up to data.
The same data is held twice.