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

BAPI SAMPLE CODE FOR FLAT FILE in SAP ABAP

BAPI SAMPLE CODE FOR FLAT FILE in SAP ABAP

REPORT ZBAPI.

DATA: BEGIN OF i_data OCCURS 0,
text(255),
END OF i_data.
DATA: i_ekko TYPE bapiekkoc.
DATA: it_ekko LIKE TABLE OF i_ekko INITIAL SIZE 0 WITH HEADER LINE.
DATA: BEGIN OF i_ekpo OCCURS 0,
po_item(5),
pur_mat(18),
plant(4),
net_price(23),
disp_quan(13),
END OF i_ekpo.
DATA: it_ekpo LIKE TABLE OF bapiekpoc INITIAL SIZE 0 WITH HEADER LINE .

DATA: BEGIN OF i_eket OCCURS 0,
po_item(5),
deliv_date(8),
quantity(13),
END OF i_eket.
DATA: it_eket LIKE TABLE OF bapieket INITIAL SIZE 0 WITH HEADER LINE.
DATA: v_index TYPE i.
DATA: return TYPE TABLE OF bapireturn INITIAL SIZE 0 WITH HEADER LINE.
DATA: po_num(10).

START-OF-SELECTION.

CALL FUNCTION 'UPLOAD'
  • EXPORTING
  • CODEPAGE = ' '
  • FILENAME = ' '
  • FILETYPE = ' '
  • ITEM = ' '
  • FILEMASK_MASK = ' '
  • FILEMASK_TEXT = ' '
  • FILETYPE_NO_CHANGE = ' '
  • FILEMASK_ALL = ' '
  • FILETYPE_NO_SHOW = ' '
  • LINE_EXIT = ' '
  • USER_FORM = ' '
  • USER_PROG = ' '
  • SILENT = 'S'
  • IMPORTING
  • FILESIZE =
  • CANCEL =
  • ACT_FILENAME =
  • ACT_FILETYPE =
TABLES
data_tab = i_data
  • EXCEPTIONS
  • CONVERSION_ERROR = 1
  • INVALID_TABLE_WIDTH = 2
  • INVALID_TYPE = 3
  • NO_BATCH = 4
  • UNKNOWN_ERROR = 5
  • GUI_REFUSE_FILETRANSFER = 6
  • OTHERS = 7
.
IF sy-subrc 0.
  • MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
  • WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.

loop at i_data.
if i_data-text(1) = 'H'.
shift i_data-text.
v_index = v_index + 1.
split i_data-text at ',' into i_ekko-doc_type
i_ekko-purch_org
i_ekko-pur_group
i_ekko-vendor.
append i_ekko to it_ekko.

elseif i_data-text(1) = 'I'.
shift i_data-text.
split i_data-text at ',' into i_ekpo-po_item
i_ekpo-pur_mat
i_ekpo-plant
i_ekpo-net_price
i_ekpo-disp_quan.
append i_ekpo.
move-corresponding i_ekpo to it_ekpo.
append it_ekpo.
clear it_ekpo.
else.
shift i_data-text.
split i_data-text at ',' into i_eket-po_item
i_eket-deliv_date
i_eket-quantity.

append it_eket .
move-corresponding i_eket to it_eket.
append it_eket.
clear it_eket.
endif.
endloop.

CALL FUNCTION 'BAPI_PO_CREATE'
EXPORTING
po_header = i_ekko
  • PO_HEADER_ADD_DATA =
  • HEADER_ADD_DATA_RELEVANT =
  • PO_ADDRESS =
  • SKIP_ITEMS_WITH_ERROR = 'X'
  • ITEM_ADD_DATA_RELEVANT =
  • HEADER_TECH_FIELDS =
  • IMPORTING
  • PURCHASEORDER =
tables
po_items = it_ekpo
  • PO_ITEM_ADD_DATA =
po_item_schedules = it_eket
  • PO_ITEM_ACCOUNT_ASSIGNMENT =
  • PO_ITEM_TEXT =
RETURN = return
  • PO_LIMITS =
  • PO_CONTRACT_LIMITS =
  • PO_SERVICES =
  • PO_SRV_ACCASS_VALUES =
  • PO_SERVICES_TEXT =
  • PO_BUSINESS_PARTNER =
  • EXTENSIONIN =
  • POADDRDELIVERY =
.
write: po_num.
loop at return.

write:/ return-message,return-type.
endloop.

Here it is.


RELATED POSTS

SAP ABAP BAPI 1
SAP ABAP BAPI 2
SAP ABAP BAPI 3
SAP ABAP BAPI 4

No comments :
Labels: ABAP , ASAP , BAPI'S IN 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

Handling errors in BAPI in SAP ABAP

You have to create a parameter named Return for every BAPI. This parameter returns exception messages or success messages to the calling program.

BAPIs themselves must not trigger any messages (such as MESSAGE xnnn) in the coding. In particular they must not generate terminations or display dialog boxes. Instead, all messages must be intercepted internally and reported back to the calling program in the Return parameter. Otherwise the BAPI will not be processed correctly and control may not be given back to the calling program.

All error messages or indeed any message that may be returned by the BAPI, must be defined in message table (Tools -> ABAP Workbench -> Development -> Programming environment -> Messages) and described in the documentation for the return parameter. This also applies to the most important or most likely error messages generated by other programs that can be indirectly passed via the BAPI to the application program.

ans in BAPI'S u can handle the errors with the help of BAPI RETURN parameter.

U have to declare an internal table like BAPIRET2. u need to pass this internal table to the RETURN structure .Now this internal table will capture the error messages once u run the BAPI.

In Every Bapi there will be a RETURN parameter of type BAPIRET2.

WE PASS IT AS TABLES PARAMETERS
AND ALL THE ERRORS ARE COLLECTED INTO IT
see the sample code
REPORT z34332_bdc_create_material .

data: la_headdata type BAPIMATHEAD,
la_clientdata type BAPI_MARA,
la_CLIENTDATAX type BAPI_MARAX,
la_return type BAPIRET2.

data: i_materialdescription type table of BAPI_MAKT,
wa_materialdescription like line of i_materialdescription.

la_headdata-MATERIAL = '000000000000000004'.
la_headdata-IND_SECTOR = 'M'.
la_headdata-MATL_TYPE = 'FERT'.

la_clientdata-BASE_UOM = 'FT3'.
la_CLIENTDATAX-BASE_UOM = 'X'.
la_clientdata-MATL_GROUP = '01'.
la_CLIENTDATAX-MATL_GROUP = 'X'.

wa_materialdescription = 'TEST'.
append wa_materialdescription to i_materialdescription.
clear: wa_materialdescription.

CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
EXPORTING
headdata = la_headdata
CLIENTDATA = la_clientdata
CLIENTDATAX = la_CLIENTDATAX

* PLANTDATA =
* PLANTDATAX =
* FORECASTPARAMETERS =
* FORECASTPARAMETERSX =
* PLANNINGDATA =
* PLANNINGDATAX =
* STORAGELOCATIONDATA =
* STORAGELOCATIONDATAX =
* VALUATIONDATA =
* VALUATIONDATAX =
* WAREHOUSENUMBERDATA =
* WAREHOUSENUMBERDATAX =
* SALESDATA =
* SALESDATAX =
* STORAGETYPEDATA =
* STORAGETYPEDATAX =
* FLAG_ONLINE = ' '
* FLAG_CAD_CALL = ' '

IMPORTING
RETURN = la_return
TABLES
MATERIALDESCRIPTION = i_materialdescription

* UNITSOFMEASURE =
* UNITSOFMEASUREX =
* INTERNATIONALARTNOS =
* MATERIALLONGTEXT =
* TAXCLASSIFICATIONS =
* RETURNMESSAGES =
* PRTDATA =
* PRTDATAX =
* EXTENSIONIN =
* EXTENSIONINX =

.

write: la_return-TYPE, ',', la_return-MESSAGE.
clear: la_headdata, la_return, la_clientdata, la_clientdatax.

Related Posts

No comments :
Labels: ABAP , BAPI'S IN ABAP , SAP

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