Financial Management Blogs by Members
Dive into a treasure trove of SAP financial management wisdom shared by a vibrant community of bloggers. Submit a blog post of your own to share knowledge.
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member186338
Active Contributor


In this post I want to describe the concept of performing calculations in the write back badi instead of default.lgf. Let's assume that we have some default.lgf with a number of *WHEN/ENDWHEN loops doing some calculations like price*quantity, price*quantity*(1-discount), etc. If you have a lot of formulas the calculation time can be significant and users will have to wait saving data in the input form.

Difference between default.lgf and write back badi:

Default.lgf

Benefits:

Easy to maintain

Easy to copy data to another model using *DESTINATION_APP

All checks are done automatically (security, work status, write to calculated members etc...)

Issues:

Execution speed (even with ABAP calculation engine for BPC 10).

Unnecessary calculations can be performed (default.lgf scope is a combination of all members of sent data!)

Hard to generate multiple records triggered by single member change (example - single price for the whole year in some member, update all months amount)

Write back badi:

Benefits:

High execution speed.

Only sent data will trigger the calculation (write back badi receives the table with sent data, not the scope).

Easy to generate multiple records having single value sent.

Issues:

Hard to maintain (ABAP developer required).

Write access have to be checked before calculations.

Special code have to be added to write to the different cube.

Write back badi sample logic:

1. All data sent by user from a single EPM/EVDRE report will be passed to write back badi as a table (including parent values).

2. Only members used in formulas will be processed by badi calculations, the rest will be processed by default.

3. Initial write to the cube with create_write_back and write_back will be done inside badi to ensure that the sent values are stored (removing rejected records from calculation process).

4. Reference data (data for members used in the formulas but not existing in the sent records table) have to be read from cube.

5. Number of functions have to be defined - each representing the ABAP code of the formulas required.

6. Table with original records saved in the cube and reference data records have to be processed by the functions from previous point.

7. Calculated records have to be added to original ct_data to have correct messages.

8. If write to other cube is required then it have to be implemented with create_write_back and write_back.

9. At the end of badi ct_data will contain original records and calculated records. This table will be written to the cube generating correct messages.

B.R. Vadim

17 Comments