Scheduling of Global Planning for SAP BW

In large scale planning models, where many planning areas and levels are included, it is necessary to bundle not only those parameter sets of one planning level, but those across planning levels and areas of SAP BW.Especially if large portions or the whole planning process should be calculated, it is too expensive to carry out all the parameter sets manually.Therefore, the global planning sequence can be used to bundle and order parameter sets across planning levels and areas.If the processing of the global planning sequence takes too long, then it can be scheduled in a batch run. Background processing, on the other hand, begins straight away.It is possible to link global and local sequences together in one global sequence.In addition to this, you must also use a global sequence when your processing sequence covers more than one package. They can also be used for automatic planning functions.


Scheduling

ABAP Editor is called either via transaction SE38 from the command line OR via Tools,ABAP Workbench,Development ,ABAP Editor.

Jobs may be monitored via System,Services,Jobs,Job Overview. A “job log” may be called from here.

More detailed functions to control jobs are found via Tools,Computing Center Management System (CCMS) ,Jobs.

Global planning sequences may be scheduled
Use the report UPC_BUNDLE_EXECUTE in the ABAP Editor
Executing this report you select an existing Planning Sequence – local and global sequences are listed together in name order
Variants may be saved for the UPC_BUNDLE_EXECUTE program to run a particular GPS
The run may be scheduled via Program,Execute in Background: Options include
Specified Date/Time
After job
After event
Jobs may be created to run the defined variant via System , Services , Jobs , Define Job
Best log information is found via planning workbench (BPS0) ,Planning,Planning Sequences, Tools , Logs
Include the job to run the GPS in a Process Chain via BW ,Administration,Process Chains

Resolving Memory Issues

The memory usage on the application server depends on several measures. For each user there’s an initial usage plus a variable memory usage which depends on the data volume that the user is processing. 

Initial usage: 3-5 MB for transaction BPS0
  1. Variable memory usage:
  2. Determined by the number of records read from BW or created in BPS;
  3. Increases during one planning session (new transaction and reference data is used/created).
  4. Rule of thumb for minimum requirement : number of records * size of record
  5. Data compression is used (by default) if buffered data is not currently processed.
If a lot of the configuration is based on multi areas that contain many basic planning areas, then this can lead to high memory consumption.If possible functions and layouts should be based on the basic planning areas instead of the multi planning area. The reduction of the memory consumption can be estimated by viewing the structures of the planning areas in transaction SE11.

Multi areas should be only used for cases where data of several basic planning areas is required (for example, copy functions). This is especially true, if the data models of the basic areas within a multi area don’t align very well, which is the case when key figure based and account based data models are combined.

Partitioning of Planning Packages

Basically, the selection of a planning package is broken down into a set of more restricted packages (independent ad-hoc packages based on a partition characteristic), and those ad-hoc packages are executed independently. In other words: We convert one huge function into a set of smaller 'smaller' functions. This conversion is done during runtime and doesn't require the creation of additional packages as the selection of ad-hoc package is adjusted during the execution time.

Setting up the planning packages in a partitioned way manually would be very cumbersome. Therefore, SAP provides program UPC_BUNDLE_EXECUTE_STEP that automatically partitions the packages of a global planning sequence using one characteristic.



Related Posts
No comments :
Labels: abap programming , SAP BW

Local and Global Planning Sequences in SAP BW

The local planning sequence method in SAP BW may be created by double-clicking on the planning level and choosing Create Planning Sequences from the context menu.It is not possible to trace planning sequences. You should test and/or trace each step of the sequence i.e. each planning function separately.

Local Planning Sequences is a  means of automating the execution of a series of planning functions/parameter groups in a previously defined order 

Availability:Local planning sequences are usable for functions within a single Planning Level of a Planning Area and Global planning sequences are usable for functions across several Planning Areas

Advantages:

Processes multiple functions as one single step thus minimizing
Likelihood of planning steps being omitted
Need for users to call up multiple individual functions

  1. Are a planning method belonging to the planning level
  2. Only one Planning Sequences method is created for the level
  3. Then multiple Planning Sequences may be created for the method – this is the equivalent to the parameter group
  4. Here a sequence of steps is entered
  5. To do this the super user simply enters on each line a particular planning function/parameter group combination from the level (or selects them via pop-up)
  6. Other planning sequences from the same level may also be entered or selected here
  7. Entries may subsequently be moved up or down in the sequence, and entries inserted or deleted
 Local Planning Sequence

Often during online planning sessions, a planner has to call up a sequence of individual parameter groups within one planning level. local sequence, that is connected to the associated planning level, bundles the processing sequence for the individual parameter groups together. Instead of completing each individual parameter group, the sequence is completed. This function calls up the single  parameter sets in the given order.

A planning sequence can contain other local planning sequences, Powersim models, or unstructured documents from SEM-BIC. However, an entry field is not available for the planning package field.This means that the local sequence can only contain parameter groups that can be completed in one package. If you want to include parameter groups from several different packages in one sequence,you need to use a global sequence.


Global Planning Sequences

  1. Work similarly to local planning sequences but without the restrictions
  2. Are accessed via the Menu "Planning" or via a push button "Global Planning Sequences" above the work area anywhere in BPS0
  3. Any number of global planning sequences may be entered
  4. The planning element combination that is entered/selected per line inside a GPS is:
  5. Planning Area / Planning Level / Planning Function (incl. Local Planning Sequence / Parameter Group / Planning Package)
  6. Other global planning sequences may also be entered or selected here
  7. Double-clicking on a GPS means "Execute" – Beware!
Automatic Execution in SAP BW

You use this function to ensure that, in context to a specification in a specific planning layout, one of your predefined functions is always completed.For example, you can assign a function of type currency translation to a layout that you are using for entering amounts in local currency, so that any amounts entered are automatically translated into group currency. This means that the amounts are available in both currencies, simplifying any questions that may arise between the main company and it's subsidiaries.

You can assign most functions to the planning layout so that they are automatically carried out.You can use functions from the same planning area, or you can also select a function from any other planning area.
A function that has been assigned to a planning layout for automatic execution will normally be completed when the following events take place. The function will be completed before the chosen action takes place:

  1. Saving
  2. Leaving the planning layout to go to a different object in the planning environment
  3. Executing a planning function within the planning layout.

You can define automatic execution on the first screen of the layout builder in the Planning Workbench. However, the functions or sequences are executed ONLY in the user interface in which they are configured! For example, an automatic function, which has been defined in the Planning Workbench, is not executed when using a Planning Folder.
 
Automatic execution of planning functions or sequences can be setup in the following places:

Planning Folders

Defined in configuration of Planning Folder
Executed based on four different events (before layout, after layout, start folder, saving).

Web Interfaces

Defined in configuration of Web Interface (create a button and assign to layout)
Executed based on "data change/commit" event only i.e. when data has been changed in the layout AND when navigating away from layout which includes saving or executing another function.


 
Global planning sequences can be included in the planning folder. The sequences can be added to under the global section or assigned to a layout.For each function, you can define when the function is executed:

Push button: The user executes the GPS by clicking on a button.
Execute before layout display: The GPS is executed before the planning layout is displayed. If the GPS changes data which is displayed in the layout, the changes are immediately visible in the layout.
Execute before layout change: The GPS is executed when you exit the planning layout. If the GPS changes data which is displayed in the layout, the changes are not immediately visible after opening the layout.
Execute when starting folder: The GPS is executed when the user enters the planning folder.
Execute when saving: The GPS is executed when the users save the data.




Related Posts
No comments :
Labels: abap programming , SAP ABAP , SAP BW

Exit Functions for SAP Business Warehouse

You can define your own planning functions of the type Exit Function to perform specific planning tasks that you cannot solve with any off the planning functions offered by SAP BW-BPS. You will need to provide function modules to modify the transaction data. Exit functions offer you extensive control over every detail for calculating plan data, however they also require the most work as you must write your own ABAP programs.

When an exit function is executed, the system retrieves the data defined by the planning package. The data is read either from the InfoCube or from the buffer, but the developer does not have to worry about this. In the first phase, the system builds subsets out of the selected data. How the subsets are built depends on the "fields to be changed" setting in the definition of the exit function. How many subsets are created depends on the "fields to be changed" and the selected data. Note: Subsets will be created only for existing data!

Now the system calls the INIT function. Preliminary work like reading reference data or selecting from a database table should be here. Optionally, you can return additional subsets. This way you can make sure that the main EXIT function is called for a subset.In the second phase, the main EXIT function is called once for each subset. This is very similar to a single FOREACH statement (not several nested FOREACH!) that includes all characteristics that are not in the "fields to be changed" (but remain in the "field list"). 

How to work with data in Exit Functions:
The data of a subset is passed to the EXIT function in an internal table (XTH_DATA). This is the BEFORE picture.Within a subset  (XTH_DATA) you can:

Create new data records
Delete data records


Related Posts
Customizing  SAP Controlling 
No comments :
Labels: abap programming , SAP ABAP , SAP BW

Using Formulas in SAP Business Warehouse

You can define formulas in SAP BW Screens and software which define how the transaction data is to be processed in order to generate plan data. Formula functions enable you to use extended mathematical functions to calculate plan data.In addition to different calculation functions, which you can use for value assignment in formulas, there is also the possibility to model complex flow structures with the formula language FOX (FOrmula eXtensions).

FOX Formulas - Example

How to specify a record in a formula:

{field to be changed 1, field to be changed 2, …, field t.b.c. n}.

If the key figure is a field to be changed then each key figure in a record can be addressed individually. If the key figure is not in the fields to be changed then all key figures of the data record will be changed according to the formula.We use the above Example: for each product we copy data from the current year (2004) to the next year (2005):

Field(s) to be changed: 0FISCYEAR
Formula: {2004} = {2005}.

You do not have to care about the product because of the subsets ("automatic FOREACH")!Do not forget the "." at the end of each statement

Some Elements of FOX Formulas

The planning function of the type formula calculation offers you a simple programming language for the manipulation of transaction data. It includes elements, which can be found in many macro languages for business applications.In addition to the formula calculation, there is also the possibility to create planning functions of the type Exit, in order to manipulate transaction data using a programming language. Weigh up the following points against each other in order to make a decision for one or the other function type.

Planning functions of the type formula are easily learned, and only require a small amount of training. Ideally, we imagine an end used in Controlling, who has already mastered an algorithmic programming language or a macro language, and can solve most of the problems with the formula language.Planning functions of the type Exit must always then be written, when you require features, which are yet not available in another way. Example: for the calculation of costs, customer tables must be accessed. Up to now, there is no feature to access formulas in any tables.

Generally, every Exit function module achieves a higher performance level than the formula calculation. The reason for this is mainly that every operand and every result from somewhat complex formulas are read separately from an internal table.In a self-written program, you would of course optimize this access. This performance point of view is a decisive criterion for larger quantities of data.


FOX Formulas – Foreach Statement

You have to define a local variable:

DATA year TYPE 0fiscyear.
Use this variable in the Foreach Statement:

FOREACH year.
{year} = {2004} * 2.
ENDFOR.

The values for YEAR are taken from the records in the selection of the planning package.

Assume we have data records for year 2005 and 2006.
First loop: YEAR is replaced with 2005, system calculates {2005} = {2004} * 2.

Second loop: YEAR is replaced with 2006, system calculates {2006} = {2004} * 2.

FOX Formulas – Nested Loops

Use nested FOREACH statements only if necessary.Use FOREACH VAR1,VAR2 wherever it is possible.


Variables In Formulas

In the example below we see use of the "Global" Variable being used in a FOX formula (PERCUR).This is used in the planning area to represent "Current Period". In variables set-up within the planning area the current period is set once per period to the current period value.

In addition the formula must work with "Local Variables". These are declared at the beginning of the formula: ZCURPER is used to represent current period, and ZFCPER the forecast period. There is also a counter, ZCOUNTER.

Within the planning function the "Fields to be Changed" are respectively key figure name, fiscal year/period and version.Very simply the formula will calculate forecast sales quantity (0COPASLQTY) for the next five periods. ZFCPER is incremented (using the concept of a local time variable TMVL – see later unit for more information about this) for each of five times, and in each case the quantity for the respective forecast period is set to the actual quantity (version ACT) of the current period (using local variable ZCURPER).

The key point to note as far as syntax is concerned within the formula is that the local variable (ZCURPER) is set to the value held against the (global) variable within variable settings in the Planning Area.





FOX always uses INTERNAL format for characteristic values.For example, accounts have to be entered with leading zeros. 

Use F4 help for entering { }-operands.
If–statements versus conditions - when to use which:

In conditions you can use any variable – also variables with ranges, several values or hierarchy nodes.When using if-statements you only have one parameter group and thus only one formula. Therefore the formula is easier to understand. 

Use naming conventions for local FOX variables, e.g.:

  1. CHA_… for characteristics,
  2. KYF_… for key figures,
  3. VAR_… for global (BPS) variables,
  4. INT_… for integer numbers.

Do not use "ABAP" logic like PERIOD = PERIOD + 1. for calculating in time characteristics. Use the TMVL function instead PERIOD = TMVL(PERIOD, 1).

If you need the value of a characteristic that is not in the ‘fields to be changed‘ use the function OBJV().If there is no data in a subset, the FOREACH does nothing (empty loop) – be careful when creating new records using a FOREACH statement.No loop over reference data possible – reference data can only be used on "right side" of formulas.

No loop over master data possible – FOREACH statement only goes through existing records .

Performance:
If you use ATRV for a characteristic and the formula requires reference data, then the system ignores any restrictions for this characteristic when reading the reference data form the database.

Especially during the test phase, sending additional messages in the FOX formulas is very useful. Please refer to the online help for an explanation of the syntax of the MESSAGE statement.

Tip: Message number 001 of message class UPF is generic and can be used to include up to four parameters in the message. For example: MESSAGE E001(UPF) WITH 'Please enter data for period' FISCPER 'and year' FISCYEAR.

Since the system generates complex ABAP coding for each FOX formula, it does not make sense to use the standard ABAP debugger (/h) for debugging FOX formulas. Also including a BREAK-POINT in a FOX formula, is only relevant for experts (for example SAP Support).


Related Posts
No comments :
Labels: SAP ABAP , SAP BW

Statistical Forecast using SAP BW

The forecast function has been newly implemented in BW-BPS. In standard cases, the previous forecast function used within the bounds of SEM-BPS is no longer available. For compatibility reasons the system still provides the old function if you were using it within SEM-BPS.SAP recommends you use the newly implemented forecast function in BWBPS for new developments.

This explicitly enhances the functionality of the old (SEM-BPS) forecast function, even though it does not cover all aspects of it. (For example, you do not obtain forecasts according to Croston’s algorithm). For more information on the old (SEM-BPS) forecast function, see the online help.We can use a forecast procedure in SAP BW to predict the future development of key figures. The forecast function uses historic data to calculate expected forecast values with statistical procedures.

Prerequisites:

Historic data that can serve as reference data for the forecast must be available.The planning level,  in the context of which you create a forecast function, must contain at least one characteristic with a time reference (for example, fiscal year). The forecast period is copied from the selection in the planning package or planning level and therefore must be restricted there.

Forecast Models

The following forecast strategies are available to you for performing calculations:

  1. Automatic model selection
  2. Average
  3. Moving average
  4. Weighted moving average
  5. Simple exponential smoothing (constant model)
  6. Linear exponential smoothing (trend model)
  7. Seasonal exponential smoothing (seasonal model)
  8. Trend-seasonal exponential smoothing (multiplicative seasonal component)
  9. Trend-seasonal exponential smoothing (additive seasonal component)
  10. Linear regression

The automatic model selection forecast strategy allows you to let the system select the forecast model that best fits the trend of the historic data.

Statistical Forecast

The online help contains very detailed descriptions of all forecasting strategies and extensive explanations of the various parameters that can be set.


Design Planning Functions

This holds for EVERY planning function:

  1. Define the business scenario for the planning function.
  2. Determine the proper level – i.e. the level of aggregation in the Info Cube that is needed for the business scenario. You have to identify the proper characteristics and key figures.
  3. Write down some sample records in that level.
  4. Write down how the data records should look like after executing the planning function.
  5. Identify the fields in the data records that are changed or used for calculation by the planning function. These are the “fields to be changed” in the planning function.
  6. Identify the type of planning function (predefined type, formula (FOX), exit) and configure the planning function.

Before a planning function is executed the selected data is cut into smaller sets of records called subsets.The planning function will be executed several times, once for each subset. The data from the package is grouped by the characteristics that are not in the fields to be changed: within a subset all records have the same characteristic values for those characteristics.Reason for building subsets: makes the coding of planning functions and Fox formulas much easier.

Subsets and formulas (FOX): system is doing a "FOREACH" statement for you for every characteristic that is not in the fields to be changed.You cannot rely on the sort order of the subsets! Do not code on the order in a formula or exit function.


When to Use Formulas (FOX)

There is no predefined planning function that does the job.The task cannot be done in one standard planning function but several planning functions/sequence are needed. The customizing of a standard planning function gets to complicated.

Performance:

Most of the time it is faster to have one fox formula doing the job than a number of planning functions.

When to Use Exit Functions

Use an Exit if:
 
  1. The logic in FOX would be very complicated
  2. You need a lot of reference data that should not be locked
  3. You want to create new records from reference data
  4. You need several complex FOX formulas for doing the job
  5. You need syntax elements that are not contained in the FOX
  6. The execution of the planning function takes too long (not the reading from the database!)

You need the same planning function in different levels. You can use the same exit function is several places instead of copying a predefined or formula function to the different levels

Disadvantages of Exits:

  1. You need ABAP programming skills
  2. Have to make sure there is someone in the project that can maintain exits (ABAP function modules)
Related Posts
No comments :
Labels: SAP ABAP , SAP BW

Currency Translation in SAP BW

In global companies planning occurs in different currencies. Usually the operations plans are in local currency and the business unit plans in group currency.The currency translation function can be used for both reconciliation and consideration of currency rate in the planning process.  

Key figure
You enter both the key figure that you want to translate, as well as the key figure in which the translated value should be stored using SAP BW . If you enter the same key figure for both fields, the original values of the key figure will be overwritten by those of the target currency. However you can also store the translated values in another key figure.If, within one parameter group, you translate different initial key figures into the same target key figure, then the values in the target key figure are added up. Exchange rate type Here you enter which exchange rate (in relation to the date of translation) should be used for the currency translation, for example, average rate, current exchange rate, historical exchange rate and so on.

Target currency

Here you define the currency into which the key figures should be  translated (the current valid currency of the key figure is automatically calculated). Under the currencies you select the one which is available in your system directly.


How to Model Currency Translation

Please keep in mind that planning functions may generate double data and often don't have a delta functionality.This is the case for the Currency Translation function too, as the upper example describes. Therefore one must bundle a Delete Function and the Currency Translation Function in a Planning Sequence. 





Unit of Measure Conversion

Key figure

You enter both the key figure that you want to translate, as well as the key figure in which the translated value should be stored. If you enter the same key figure for both fields, the original values of the key figure will be overwritten by those of the target unit. However, you can also store the translated values in another key figure. If, within one parameter group, you translate different initial key figures into the same target key figure, then the values in the target key figure are added up.

Conversion unit : Here you enter which unit the key figure should be converted into.

Characteristic target unit

Here you can select a characteristic that is contained in the unit-bearing planning level, through which the target unit is determined. Defining the target unit with one of the above methods is only then allowed, if a certain unit for the key figure is not already predetermined in the definition of the target key figure. You can only define the target unit with one of the methods that is described. If you predetermine a target currency as well as a currency-bearing characteristic, the system rejects this entry.

Conversion rates

The conversion rates are stored in tables T006*. The rates are often loaded from SAP R/3 or have to be maintained manually via the SAP Implementation Guide (transaction SPRO or directly using transaction CUNI).The same rules for modeling apply here as for currency conversion: If one key figure is involved, then the unit conversion should be preceded with a delete function. If two key figures are involved a characteristic relationship should be setup.



Related Posts
No comments :
Labels: SAP ABAP , SAP BW

SAP Business Warehouse Distribution Functions

With the distribution function, you can distribute values from one planning level to another planning level in SAP BW. Typically this function is used for top-down distributions from one organizational unit to another organizational unit below. The distribution is completed for vertical reconciliation purposes. Another scenario is a distribution along a product hierarchy.When the function is executed, the values are rolled up including the assigned and non-assigned values, and are then distributed to the destination, specified by the fields to be changed.

The # sign, that stands for "not assigned", is very important when using this planning function as it is used to write the debit and credit records to the function table. It is important to note that the seasonal distribution is not a specific planning function but a way of using the distribution function.For your modeling, it is important that the planning function for the distribution that is used for the modeling, can be used exclusively for a key figure model.


Distribution Variants

There are two basic variants available for completing distribution.The distribution is either based on reference values which are already available in the database or on weighting factors which have to be entered manually.The total value is not changed by the distribution function. Only existing data is distributed according to the defined rule.

1. Distribution by Keys
2. Distribution by Keys from Sender to Receiver
3. Distribution by Reference Data
4. Distribution by Reference Data from Sender to Receiver

Distribution by Key

When distributing by key, you provide characteristics values and the shares by which distribution is to take place. For the fields to be changed you select the characteristics that you want to use and distribute the plan data using their values. The distribution factors with which you distribute the total amount to be distributed in the parameter groups represent relative values. These relate to the sum of the factors used in the parameter group: The system views the total that is formed from the addition of all factors within a parameter group as 100% and then determines the relative weight of every factor for distribution. 


Distribution by Reference Data

When distributing with reference data, you make the same settings as when distributing by key. In addition, you select one or more characteristics that are to be used to determine reference data.


Additional Settings for Distributions

For the basic function types distribute with reference data and distribute by key you can also specify that only those data records should be included in distribution that contain the initial value "not assigned" (#) for the characteristics to be changed. Retain values at sender data record For the extended function types distribute with reference data from sender to receiver and distribute by key from sender to receiver, you can decide whether the values that you distribute to the receiver data records should remain posted at the sender data records, or whether the appropriate sender data records should be deleted after distribution.

Related Posts
No comments :
Labels: SAP ABAP , SAP BW

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.



Related Posts
No comments :
Labels: SAP ABAP , SAP BW

Authorizations on Plan Data in SAP BW

The authorization check for accessing BW-BPS objects belongs to the general SAP authorization check process. The SAP authorization check is based on the authorization objects. An authorization object is made up of a maximum of 10 authorization fields. To define an authorization for an authorization object, you must specify values for the individual fields in the object. You can create as many authorizations together with different values and fields for an authorization object. Profiles are lists of authorization objects. A user's authorizations for the various objects in the SAP BW System are determined by authorization profiles that are assigned to the user master record.

In the BW-BPS one has to distinguish between authorizations on transaction data and on customizing objects.Authorization on transaction data controls whether the user is allowed to use, see or change a set of data from an Info Cube.Authorizations on customizing control whether a user can use or change a  customizing object like a layout or a planning function.

Authorizations regarding InfoCube and transaction data will be evaluated for reporting and planning. Example: If a user has reporting permission for a cost center it is automatically valid for planning also. Reading transaction data requires authorization for InfoCube access (S_RS_ICUBE) and for transaction data (reporting authorization).In reporting you only have to control the read access. In planning you have to distinguish between read and write access.You create authorization objects using transaction RSSM or SU21. You add authorization relevant characteristics and key figures to the authorization object. In planning you should add the technical InfoObject 0ACTIVITY for distinguishing between read and write access.If you use layouts with MS Excel the system has to read the Excel templates for the planning layouts. Thus you need the authorizations for the object S_BPS_DS (Class name SEM_BPS and Class type OT).

All authorization objects for planning are delivered. They use the standard SAP authorization concept and can be displayed e.g. by using transaction SU21. They follow a naming convention: all planning objects start with "R_".

Authorization objects used in the planning framework (FW):

  1. R_AREA Planning area
  2. R_PLEVEL Planning level
  3. R_PACKAGE Planning package – no execution activity
  4. R_METHOD Planning method
  5. R_PARAM Parameter group

 All authorization objects offer the following activities

02 Change
03 Display
16 Execute (except package)
21 Transport
 All objects mentioned before have a hierarchical relationship as shown in the slide. The activities are inherited automatically.Example: Activity ‚execute‘ for R_PLEVEL ô€ƒŽ all functions and layouts defined for the planning level can be executed.

Hint 1: You cannot exclude any planning levels or packages. Instead you have to include all planning levels and packages explicitly.
Hint 2: For Manual Planning use the planning method "0-MP", for local sequences use "0-BF".


 


R_PROFILE Planning profile
R_BUNDLE Global planning sequence
R_WEBITF Web Interfaces (customizing and execution)
R_PM_NAME Planning folder
R_STS_CUST Customizing Status and Tracking System (STS)
R_STS_SUP Super user access to STS
R_STS_PT Executing STS (sub plan and planning sessions) as normal user


Related Posts
No comments :
Labels: abap programming , SAP BW

Layouts Types in SAP Business Warehousing Continued

Totals and Automatic Calculation

Totals can be used in data columns and also in rows provided that you have chosen the type "key figures in data columns, rows individually defined" or the type "key figures in lead columns". When defining totals you can either list every column individually (e.g. C(1)+C(2)+…) or use ranges (e.g. C(1):C(3) which is equivalent to C(1)+C(2)+C(3)). The calculation for rows works accordingly.  You can use this feature for example for calculating values for quarters i.e. totals over 3 periods .

You can use totals in totals. For calculating the grand total over the year you can sum up the totals over the quarters instead of summing up all the periods.Totals can be used for dynamic columns as well. If say the dynamic column in column 2 you can just write C(2). When the system replaces the dynamic column by the actual number of column then the system will also adapt the formula. If say the dynamic column is replaced by three columns then the system will replace C(2) by C(2)+C(3)+C(4) in every formula. All formulas that use columns "behind" dynamic columns (in our example a formula like C(3)) will be adopted accordingly (C(3) would be replaced by C(5) in all formulas).


Automatic Calculations in Excel

When using Microsoft Excel in the GUI you can use the automatic calculation functionality. It works for user defined totals (in columns or user defined rows) as well as for the totals in rows (set on the last screen of the layout builder). The system uses Excel macros for these calculations. The calculations are done as soon as the user enters a new value – the user does not have to press any button.

Automatic Aggregation: When changing a value in a non-total cell the system will calculate all totals in the layout automatically. Automatic Disaggregation: The totals are input on. When a user enters a value on a total the system will automatically distribute this value. There are different ways to determine the distribution key: 

Same – use the current distribution as a distribution key
Equal" – distribute evenly use a reference column within the layout for the distribution key (refers to the planning function "distribute with reference data") If the layout uses totals rows and columns you can specify whether the values are first distributed to the rows and then to the columns or vice versa.You can lock (and unlock) cells against the automatic changes. If, for example, you have a layout with production data in 12 columns. You know exactly that you cannot go beyond the value you have already entered for say July as most of the workers are on annual leave. 


 

Documents in Layouts

In  SAP BW you can store documents to a characteristics (and Key figure) combination. Using such documents you comment single plan values directly in Manual Planning.For using this feature you have to mark all relevant characteristics as "document enabled" in the administrator workbench (flag "characteristic is document attr."). On the third screen of the layout builder you have to set the flag "use documents". You can create, change or delete documents of type Word, Excel, PowerPoint or pure text. If there is a document available for a cell in Excel then there is a small shape that can be clicked and that launches the document or a list of all available documents if there is more than one. 

In SAP ALV every cell that contains a document is marked in blue.There are delivered Exit functions that can be used to copy documents and to delete documents. Have a look at function group UPFX.The system also uses the buffering mechanism for documents. When using Manual Planning in the Web (Web Interfaces) you can only create, change delete or view pure text documents. Any Word, Excel or PowerPoint document is not visible in the Web Interface.The document storage it the Knowledge Warehouse. Thus you can use the same documents throughout the entire BW including BW-BPS. 



Documents in Planning Folders

The documents in layouts can be used in planning folders as well.In SAP ALV (in folders as well as in the framework) cells that have a document attaches have a blue background color. Documents can be created, changed and deleted.Additionally you can create an detail application "documents" in the framework that shows all documents within the package selection as a list. This feature can also be used in planning folders in the output area of a planning folder with input/output area. Documents can only be displayed when using this feature.

Special Design Features in Excel

When using Microsoft Excel for the layout you have additional design options that you can configure on the third screen of the layout builder.Within the areas in the layout the system creates ranges. These ranges are "named ranges" in the Excel and can be:

formatted individually using either one of the predefined styles or a new style,freely positioned on the Excel sheet (make sure that they do not overlap at execution time – e.g. when using dynamic columns the number of columns can change).

Each row in the header, each heading and each column (data column or key column) is a range. Range can only be moved as a whole. If for a characteristic in the key column you use text/description or description/text then the range is two Excel columns wide, otherwise it is only one column wide.The BPS used predefined delivered styles for formatting the ranges. For each range you can use one of these standard styles, you can modify the standard styles or create new styles. You simply format the entire range using the desired style. The system will read and store the name of the style.

There are some elements in the screen which used fixed style – you cannot set another style but you might modify these predefined styles. These elements/styles are:

every cell that is input on will be formatted with the style "SEM-BPS-input-on"
the grand total will be formatted with the style "SEM-BPS-total"
all subtotals (or sub-nodes in a hierarchy) will be formatted with the styles "SEM-BPS-sub1" or "SEM


Master Template and Data Storage in Layouts

When you create a layout that is using Excel then the system gets a physical copy from a "master template" and saves the Excel as a file in the BDS (Business Document Server) after you have done changes in the layout builder. Thus the BPS uses two different storage locations for changes you do in the third screen of the layout builder: 

BPS Database tables: positions of the ranges, names of the used styles
BDS (Excel file): background, formulas, definition of styles, additional sheets, macros, …

If you do not like the delivered standards in the master template you can import your own master template (so-called custom master). The best way to do is to get a copy of the delivered SAP master template (report UPP_GET_MASTER_COPY), modify the Excel sheet (e.g. change the background, include a logo etc.), and check the file in as a custom master (report UPP_MASTER_CHECKIN). The system will not delete the delivered master. If you want to go back to the delivered master template run the report UPP_DELETE_CUTOM_MASTER. When creating a new master template make sure that the styles with the predefined names are still available.

When importing a new master template then all layouts that are created after that will have the new appearance. All older layouts will still have the "old" look. If you want to change this appearance you can run report UPP_LAYOUTS_UPDATE_WITH_MASTER. This report exchanges the saved Excel file in all selected layouts with the current master template. Changes in the files itself (like additional sheets, macros etc. ) will be lost.Remember that the Excel template is stored as a file on the server but has to be transferred and started on the PC when executing a layout. The larger the Excel file is (e.g. large pictures) the more time is lost for transferring the file to the PC and for starting it. So keep the Excel sheets at a reasonable size. In order to speed up the transfer process the system will store the Excel file in the temporary directory on the PC such that the Excel file only has to be transferred once.



Related Posts
No comments :
Labels: abap programming , SAP BW
Subscribe to: Posts ( Atom )