Showing posts with label SAP BW. Show all posts
Showing posts with label SAP BW. Show all posts

Budgeting Hierarchy for SAP Business Warehousing

If you want to use the budgeting functionality of BW-BPS in SAP BW for hierarchies with one characteristic (hierarchy with postable nodes).

Handling of hierarchy display for BW hierarchies with postable nodes:
  1. In the planning level select the characteristic which is used in the hierarchy
  2. Planning level/package: select the hierarchy in the characteristic values
  3. On the first screen of the layout builder:
  4. Select the hierarchy bearing characteristic for the lead column.
  5. Choose "Hierarchical Data Model" and "BW Hierarchy with Postable Nodes".
  6. Select the totaling logic you wish to use for the budgeting function.
  7. Mark "Check Entry" if you want to ensure, that the not assigned values are not below zero.

Hierarchy with Several Characteristics

Requirements for hierarchical display:

  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed
  4. You want to post to not assigned values
  5. You want to use a structure from a hierarchy with several characteristics
  6. User can input data on different levels of the hierarchy
  7. Nodes are changeable


Hierarchy with Several Characteristics

If you want to use the budgeting functionality of BW-BPS with hierarchies with several characteristics (e.g. product group, product).
  1. In the planning area create characteristic relationships which reflect the relations of all characteristics used in the hierarchy you want to display. Usually you use the respective hierarchy to do so. (You could as well use attributes in order to derive the relations).
  2. In the planning level select all characteristics that are used in the hierarchy you want to display.
  3. In the planning level/package select all characteristic values you want to be displayed. Make sure you include the "initial value" which in this case means the "not assigned" #-symbol.
  4. On the first screen of the layout builder:
  5. Select all characteristics that are used in the hierarchy for the lead column (e.g. product group, product).
  6. Choose "Hierarchical Data Model" and "BPS Characteristic Hierarchy" (note: BPS characteristic hierarchy will create all possible combinations of the characteristic values that you selected in the planning level/package for the characteristics involved in the hierarchy. The characteristic relationship you created will verify which ones are 
  7. Select the totaling logic you wish to use for the budgeting function
    Mark "Check Entry" if you want to ensure, that the not assigned values are not below zero.
    On the second screen of the layout builder:
    define the sequence of the characteristics the same logic as in the hierarchy (e.g. 1. Product Group, 2. Product). 
BPS characteristic hierarchy (virtual hierarchy):

follow the same steps as described in "Handling of hierarchy display for BW hierarchies with several characteristic nodes" it is not mandatory to use characteristic hierarchies for BPS characteristic hierarchy display. If no characteristic relationship rule exists for the characteristics chosen in the level the system will just create all possible combinations of characteristics used in the lead column and display them as a hierarchy.


 Characteristic Hierarchy

Requirements for hierarchical display:

  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed
  4. User can input data on different levels of the hierarchy
  5. Nodes are changeable
  6. characteristic values are assigned more than once to a node.
  7. E.g. Items must be planned for different countries (specific product sales per country, specific balance sheet item per country)
  8. The hierarchy arises from all possible characteristic combinations, which can be formed from the
  9. characteristics of the lead column of a layout.
Characteristic Hierarchy

  1. If you want to use the budgeting functionality of BW-BPS with no BW hierarchy.this type of  "hierarchy" is just temporary (virtual) and does not necessarily mirror the hierarchical structure of your data model.
    BPS characteristic hierarchy (virtual hierarchy):
  2. follow the same steps as described in "Handling of hierarchy display for BW hierarchies with several characteristic nodes"
    it is not mandatory to use characteristic hierarchies for BPS characteristic hierarchy display. If no characteristic relationship rule exists for the characteristics chosen in the level the system will just create all possible combinations of characteristics used in the lead column and display them as a hierarchy.

Limitations:

The validity area of BW-BPS hierarchies always refers to only one specific layout.

Budgeting Logic: Top-Down

  1. The budgeting mode is set in the layout builder. Bottom up and top down mode are available in both planning with BPS-Hierarchies and in planning with BW Hierarchies with one characteristic.
  2. Top-down is chosen, when the planner is supposed to assign a fixed budget in his area of responsibility manually to hierarchy nodes and leaves he is responsible for.
  3. Once the budget is fixed and changes are made in the hierarchical lower nodes then the value on "#" is changed.When changes are done to the budget (budget correction in another layout/level) then the total and the value on "#" are changed.
Budgeting Logic: Bottom-Up

  1. In the bottom up mode the budget is not fixed and can be seen as a proposal which the planner may overwrite.
  2. If you do changes on a lower level then the value on "#" stays the same but the total is changed.
  3. If a budget change is done on a higher level then the difference is written on the value "#".
  4. Both modes can be used in a counter current planning scenario. The administrator can switch the mode of the layout according to the phase of the planning.

No comments :
Labels: SAP BW

SAP Business Warehouse Hierarchies and Attributes

SAP Business Warehouse Hierarchies and Attributes in BW-BPS can use attributes and hierarchies created in SAP BW.The maintenance of attributes and hierarchies is located in the Administrators Workbench of SAP BW (RSA1)

BW Hierarchies can be used in BPS in four different ways:

data selection in a planning level or package hierarchical display or sorted display of the data in a layout defining characteristic relationships.

  1. Creating variables for hierarchy nodes.
  2. For data selection an attribute value can be used in the level or package. Attributes can be used in variables as well.
  3. Attributes can be used for defining characteristic relationships.
  4. Attributes (attribute columns) can be displayed in all front-ends.

Data Selection via BW Hierarchies

  1. BW hierarchies can be used for selection in planning levels as well as planning packages. They can also be used in variables (type hierarchy node).
  2. For defining the selection via a hierarchy you specify the hierarchy (name, version, due date,…) and a node or a leaf of the hierarchy. The node can be a characteristic node of the characteristic used to define the hierarchy (base characteristic), a node of an external characteristic or a text node.
  3. The system will internally convert the selection via hierarchy into a selection by characteristic values of the base characteristic. If you select the node "Product Group Water" in the above example the system will use the three different types of water for the selection. If you choose the root node the system will select "Water 1", "Water 2", and "Water 3" and all of the four juices.

Benefits of using a hierarchy in a planning layout:

Expand and collapse according to a structure
Values are sorted according to the hierarchy logic
Only valid combinations are displayed
BW-BPS uses two different types of hierarchies – these are the standard BW

hierarchies plus the so-called BPS-Hierarchies that are generated when executing a layout.

Types of BW hierarchies used in BW-BPS:
 
hierarchies that contain only nodes and leaves from one characteristic (so-called hierarchies with postable nodes)

hierarchies with several characteristics and/or text nodes.

Base characteristic: characteristic on which the hierarchy is based upon (e.g. product is the base characteristic in a hierarchy, where product groups group products). The base characteristic is always the characteristic in the last level displayed in a hierarchy.

BW-BPS offers different uses for hierarchical planning

Display as hierarchy shows the data in the planning layout in a hierarchical structure following a bottom-up logic, i.e. data is entered on the lowest level of detail and totaled on the hierarchy nodes.
Display as hierarchy with budgeting logic shows the data in the planning layout in a hierarchical structure following either a bottom-up or a top-down logic.

Top-Down: Data may be entered (posted) on all hierarchy nodes and leaves except the top-node displayed in the planning layout. When data is entered on one of the higher level nodes, initially it is not assigned to lower nodes. After checking the new entry, the system generates an additional entry for the amounts that are still to be distributed (characteristic value "#" or a leaf with the characteristic value of the node for a BW characteristic hierarchy with postable internal nodes), on the same hierarchy level. The system uses these nodes in budgeting, to be able to save difference amounts between a higher-level hierarchy node (for example product group) and the total amounts of the lower-level node (for example product).

When data is entered on a lower-level hierarchy leaf or node, it is adjusted on the not assigned values of the same hierarchy level.

Bottom-up: Data may be entered on all nodes and leaves except the top-node displayed in the planning layout. After checking the new entry, the system will sum up to nodes above the node where data was changed and adjust the not assigned data so that the total on this hierarchy level stays balanced.

Display BW Hierarchy with several characteristics

Requirements for hierarchical display:

  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed
  4. User can input data only at lowest level in the hierarchy (leaves)
  5. Nodes show sums and must not be changeable

To enter data at higher hierarchy levels (e.g. product group in the layout above) you want to use a layout in another planning level.


Display as Hierarchy in One Lead Column

In order to use a BW hierarchy for display:
In the planning level/package: use a hierarchy for selection of the base characteristic (e.g. product)
Note: it is not necessary to select the characteristics used in the hierarchy nodes

On the first screen of the layout builder:
 
  1. Select base characteristic as only selection for the lead column
  2. On the last screen of the layout builder:
  3. Select "hierarchy"

This type of display provides all benefits of hierarchies in planning layouts:
 
  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed

Hint: if you do not mark "hierarchy" the data will be displayed as a flat table, but in the sort order of the hierarchy. This works also if you use more than one characteristic in the lead column.

Display BW Hierarchy with several characteristics

Requirements for hierarchical display:

  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed
  4. User can input data only at lowest level in the hierarchy (leaves)
  5. Nodes show sums and must not be changeable
  6. To enter data at higher hierarchy levels (e.g. product group in the layout above) you want to use a layout in another planning level.
  7. You want to post to not assigned values

Display as Hierarchy with Several Lead Columns

In order to present a hierarchy over several characteristics in a layout with multiple key columns you use the following settings:

  1. Use characteristic relationships (combination proposal) and the option "all possible combinations" in the first screen of the layout builder in order to get the proper characteristic combinations in the  layout.
  2. Use a hierarchy in the selection to obtain the proper sort order.
  3. Mark the flag "Totals as hierarchy" in the layout builder in order to be able to collapse and expand along the hierarchy. 

BPS Budgeting Function: Manual Disaggregation of Data

  1. BW-BPS offers different possibilities to disaggregate data manually – in BPS this is called "budgeting"
  2. Budgeting is possible with all types of hierarchical planning, no matter what type of hierarchical data model is used in manual planning
  3. With every type of hierarchy in BW-BPS a budgeting hierarchy display is possible.
  4. BW hierarchy with one characteristic (so called hierarchy with postable nodes)
  5. BW hierarchy with several different characteristics
  6. BW-BPS characteristic hierarchy (virtual hierarchies)
  7. The creation of the hierarchical display differs for the three different types of hierarchical display 

Budgeting Hierarchy – Hierarchy with One Characteristic

Requirements for hierarchical display:

  1. Expand and collapse according to a structure
  2. Values are sorted according to the hierarchy logic
  3. Only valid combinations are displayed
  4. You want to use a structure from a hierarchy with one characteristic
  5. User can input data on different levels of the hierarchy
  6. Nodes are changeable 
Related Posts
 
Scheduling of Global Planning for SAP BW
SAP Business Warehouse Simulation Introduction


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

SAP Business Warehouse Simulation Introduction

Simulation plays very important role in SAP Business Process and helpful in forecasting the business future requirements.Simulation is a procedure to analyze dynamic systems. In Simulation experiments are carried out based on a model of the reality, in order to gain insight regarding the real situation.Business simulations allow you to evaluate your business, identify key issues driving your processes and capture your company's specific business challenges Simulation models may range from simple linear equations with one unknown factor to sophisticated models that incorporate all known influences. Usually the focus of a simulation lies on aspects, which have the most impact on the simulated system, whereas minor important factors are left off or simplified.

There are different methods that support simulations: 

Forecasts: Forecasts examine trends in the presence and past and prolong those into the future. There is no guarantee that those trends will last, however besides day to day turbulence's there are a lot of development processes that are more linear than they look at first sight.
  1. Driver-based simulation
  2. Model-based simulation
  3. System dynamics: Small events can cause unforeseeable processes. Watch the stock markets (or the weather) and you can see the effects any day. System dynamics is the attempt to predict future situations based on all available information and specific theories. 
 Driver-based Planning

Planning is often executed on a very abstract detailed level (e.g. cost elements). When a cost center manager is asked to submit the expected costs for salary, travel, office equipment, overhead costs, etc. that information is usually based upon an information behind those figures (e.g. based on the number of employees working in his department). The challenge is to translate data from across business functions into critical information that tells a company what drives their business plan Driver-based planning takes those dependencies into consideration. It simplifies planning on an aggregated level and enables simulations based on different assumptions about the drivers. Reactions on changing business conditions can faster be decided upon by using changed driver values. 

Methods to support driver-based planning are:
  1. Attach documents: people are basically asked to submit a supporting narrative outlining the assumptions that are behind their numbers. 
  2. FOX Formulas: model inter dependencies of drivers and related plan figures 
  3. Planning sequences: Re-plan based on a predefined sequence of planning functions
  4. Versions: Simulate different scenarios without overwriting
  5. Reference Data: use relations and inter dependencies from the past  
Model-Based Planning

The planning process spans the whole organization. Decisions in one area of the company influence processes in other areas. These relationships may be executed sequential in the initial plan. For plan revisions the dependencies of the different plans may be modeled according to specific rules. That way it is possible to only change some plan assumptions and recalculate the full model.
Example:

Sales planning and production planning must be aligned so that based on the sales volume and assumed time for the demand the goods must be provided by production at the right time. Sales and production need resources in order to achieve their targets, e.g. sales representatives or production employees which influences headcount planning.
In addition to the integration aspect every department must conduct its internal planning process that in itself also may be model-based (e.g. calculation of capacity restrictions or scheduling in production planning)
Model-based planning reconstructs those inter dependencies and allows to simulate different scenarios based on alternative plan assumptions.

Methods to support model-based planning are: .
 
  1. FOX Formulas: map data models (e.g. master data) and transfer data
  2. Forecast Functions: predict future trends for value drivers which influence your overall model (e.g. sales growth)
  3. Multi-Planning Area: Exchange data between different plan cubes 
  4. Planning sequences: Re-plan based on a predefined sequence of planning functions 
  5. Versions: Simulate different scenarios without overwriting 
  6. Reference Data
  7. Aggregation: Every planning process involves a lot of detail which cannot be mapped to another process. However there are similarities (e.g. Sales volume = Demand volume, time period) that may be used as an integration level. The aggregation in a planning level allows to exchange the integration
    values.




Limitations of BW-BPS Regarding Simulation

Circular references (A+B=C, C+D= A)

Excel formulas: no circular references possible
FOX formulas: circular references possible through planning sequences

Iterations
BPS offers no predefined functionality for iterations
FOX formulas: iteration only by re-execution
Planning function type exit: iterations possible 
Graphical display of relationships

Dynamic Simulation

System Dynamics (SD) is an experimental approach to System Analysis. It is a way of understanding complex systems and modifying or changing them in some way. It also an approach for validating and assessing the consequences of implementing analytical (prescriptive) models or recommendations of a case study report.

System Dynamics is both
  1. a theory of structure in systems;
  2. an approach to policy design.
  3. System Dynamics is comprised of two concepts:
  4. Feedback Theory that provides general guidelines for organizing system structure.
  5. Computer Simulation that provides a means to deduce the behavior arising from a particular system structure.
  6. System dynamics is concerned with the construction of graphical and mathematical computer-based models, with detailed descriptions, that tells us how the conditions at one point in time lead to subsequent conditions at later points in time. The constructed model can then be simulated and its behavior observed over time.

To sum it up,

  1. System Dynamics is about studying complex and dynamic systems - systems which change over time.
  2. System Dynamics is about finding the 'why' (cause[s]) and 'how' (pattern) of system changes.
  3. The main benefit of system dynamics is to analyze single complex





Related Posts
No comments :
Labels: ABAP , abap programming , customer relationship management software , SAP BW

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
Subscribe to: Posts ( Atom )