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

BDC Session and Call Transactions Methods

Data Transfer Methods

You can use the following methods to transfer data:

• CALL TRANSACTION: Data consistency check with the help of screen logic.
• Batch input with batch input sessions: Data consistency check with the help of screen logic

Difference between Batch Input and CALL TRANSACTION

If the direct input cannot be used for your task, this makes creating a data transfer program easier since the underlying transactions ensure that the data consistency checks are executed.

In the case of an error during the data transfer (if data records are inconsistent, for example), you can restart the transfer at the point in the program where the error occurred.
Data Transfer Overview

Batch input methods

With the batch input method, an ABAP program reads the external data that is to be entered in the SAP system and stores the data in a “batch input session”. The session records the actions that are required to transfer data into the system using normal SAP transactions.

When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System  Services  Batch input), or have the session run in the background processing system.

CALL TRANSACTION methods

In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data does not have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program.

Choosing Data Transfer Methods

Selecting a Data Transfer Method

When you transfer data in ABAP, you have three options to submit the data for the data transfer. Only the first two methods can be recommended without reservation. The third method, by way of CALL DIALOG, is outmoded. CALL DIALOG is less comfortable than the other methods. You should use it only if you must.

• Use the CALL TRANSACTION USING statement

Summary:

With CALL TRANSACTION USING, the system processes the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.
Your program prepares the data and then calls the corresponding transaction that is then processed immediately.

The most important features of CALL TRANSACTION USING are:

o Synchronous processing
o Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
o You can update the database both synchronously and asynchronously
The program specifies the update type
o Separate LUW (logical units of work) for the transaction
The system executes a database commit immediately before and after the CALL TRANSACTION USING statement
o No batch input processing log

• Create a session on the batch input queue.

Summary:

Offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging.

Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.

Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function module calls from the ABAP program.

The most important aspects of the session interface are:

o Asynchronous processing
o Transfers data for multiple transactions
o Synchronous database update

During processing, no transaction is started until the previous transaction has been written to the database.

o A batch input processing log is generated for each session
o Sessions cannot be generated in parallel
The batch input program must not open a session until it has closed the preceding session.

Executing Data Transfer Programs

Procedure

If you are using an SAP data transfer program, follow the procedure specified in the program documentation.
If you are using a generated data transfer program, proceed as follows:

1. Start the data transfer program.
2. Decide which batch input method you want to use for the data transfer.

a) CALL TRANSACTION USING:

You must specify the:

– Processing mode: You use this parameter to specify whether processing should take place in the background or in dialog mode.
Possible values are:

A Display all
E Display only errors
N No display
– Update mode: This parameter determines how the data is to be updated:
Possible values are:
S Synchronous
A Asynchronous
L Local update

Error session: Here you have the option to specify a session name for a batch input session in which data is to be written in the case of an error. You can use this to identify incorrect data records after the batch input program has run and to import the records into the R/3 System once you have corrected them.

If you are creating an error session, you must also specify:

– User: Specify the user with whose authorizations the sessions are processed.
– Keep session: This specifies whether or not the session should be deleted once it has been processed.
– Lock date: Specify the processing date for the error session.

b) Generate session:

– Session name: Specify a name for the batch input session to be generated.
– User: Specify the user with whose authorizations the sessions are processed.
– Keep session: This specifies whether or not the session should be deleted once it has been processed.
– Lock date: Specify the processing date for the error session.
3. Specify a character that is to be used as the NODATA character.
4. Specify the path of the data file from which the data is to be imported into the R/3 System.
5. Execute the program.
6. If you have generated a session, or if errors occurred in CALL TRANSACTION USING mode, you must now edit the generated sessions. You can find information on this in BC - System services in batch input sessions.

Creating a Session with BDC_OPEN_GROUP

Use the BDC_OPEN_GROUP function module to create a new session. Once you have created a session, then you can insert batch input data into it with BDC_INSERT.

You cannot re-open a session that already exists and has been closed. If you call BDC_OPEN_GROUP with the name of an existing session, then an additional session with the same name is created.

A batch input program may have only one session open at a time. Before opening a session, make sure that any sessions that the program closes any sessions that it previously had opened.

BDC_OPEN_GROUP takes the following EXPORTING parameters:

• CLIENT

Client in which the session is to be processed.
Default: If you don't provide a value for this parameter, the default is the client under which the batch input program runs when the session is created.

• GROUP

Name of the session that is to be created. May be up to 12 characters long.

Default: None. You must specify a session name.

• HOLDDATE

Lock date. The session is locked and may not be processed until after the date that you specify. Only a system administrator with the LOCK authorization for the authorization object Batch Input Authorizations can unlock and run a session before this date.

Format: YYYYMMDD (8 digits).
Default: No lock date, session can be processed immediately. A lock date is optional.

• KEEP

Retain session after successful processing. Set this option to the value X to have a session kept after it has been successfully processed. A session that is kept remains in the input/output queue until an administrator deletes it.

Sessions that contain errors in transactions are kept even if KEEP is not set.
Default: If not set, then sessions that are successfully processed are deleted. Only the batch input log is kept.

• USER

Authorizations user for background processing. This is the user name that is used for checking authorizations if a session is started in background processing. The user must be authorized for all of the transactions and functions that are to be executed in a session. Otherwise, transactions will be terminated with “no authorization” errors.

The user can be of type dialog or background. Dialog users are normal interactive users in the SAP system. Background users are user master records that are specially defined for providing authorizations for background processing jobs.


Advantages:

Types of BDC :
CLASSICAL BATCH INPUT (Session Method)
CALL TRANSACTION

Session method

1) synchronous processing.
2) can tranfer large amount of data.
3) processing is slower.
4) error log is created
5) data is not updated until session is processed.

Call transaction

1) asynchronous processing
2) can transfer small amount of data
3) processing is faster.
4) errors need to be handled explicitly
5) data is updated automatically

RELATED POSTS

No comments :
Labels: abap programming , BDC SAMPLE CODES , SAP ABAP

BADI and Customer exits in SAP ABAP

Business Add-Ins are a new SAP enhancement technique based on ABAP Objects. They can be inserted into the SAP System to accommodate user requirements too specific to be included inthe standard delivery. Since specific industries often require special functions, SAP allows you to predefine these points in your software.

As with customer exits two different views are available:

1·In the definition view, an application programmer predefines exit points in a source that allow specific industry sectors, partners, and customers to attach additional software to standard SAP source code without having to modify the original object.

2· In the implementation view, the users of Business Add-Ins can customize the logic they need or use a standard logic if one is available.

In contrast to customer exits, Business Add-Ins no longer assume a two-level infrastructure (SAP and customer solutions), but instead allow for a multi-level system landscape (SAP, partner, and customer solutions, as well as country versions, industry solutions, and the like). Definitions and implementations of Business Add-Ins can be created at each level within such a system infrastructure.

SAP guarantees the upward compatibility of all Business Add-In interfaces. Release upgrades do not affect enhancement calls from within the standard software nor do they affect the validity of call interfaces. You do not have to register Business Add-Ins in SSCR.

The Business Add-In enhancement technique differentiates between enhancements that can only be implemented once and enhancements that can be used actively by any number of customers at the same time. In addition, Business Add-Ins can be defined according to filter values. This allows you to control add-in implementation and make it dependent on specific criteria (on a specific Country value, for example).

All ABAP sources, screens, GUIs, and table interfaces created using this enhancement technique are defined in a manner that allows customers to include their own enhancements in the standard. A single Business Add-In contains all of the interfaces necessary to implement a specific task.

Related Posts:

No comments :
Labels: BADI'S IN ABAP , MODIFICATIONS USER EIXTS CUSTOMER EIXTS , SAP ABAP

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