Skip to Content
Technical Articles

Calculations in Write Back BADI – Default.lgf Replacement

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:



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…)


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:


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.


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

You must be Logged on to comment or reply to a post.
  • Hi Vadim,

    just one comment to the list of default.lgf benefits:

    I noticed, that work status for the *DESTINATION_APP is not checked in a proper way. It does not show as an error when executing default.lgf during save. It just doesn’t update receiving model so it creates inconsistency between sending/receiving model.

    Is this a bug?



    • Hi Ivan,

      It’s a bug/feature 🙂   You have to use some administration procedures to keep work status in sync when you use destination app.


  • Hi Vadim

    Just one comment, one of the main benefits of write back BADI is that it allows users to send data at non-leaf node. And then further processing can be defined to handle this record and then only leaf members can be added to ct_data. This can be big advantage where user wants to adjust aggregated values directly. Also do you know, how such functionality can be managed in BPC M ?

    • Hi Anurag,

      Ability to “send” data to non-leaf node is the side effect of write back badi 🙂 . Simply because that write back badi will receive all data sent by user, even to the read-only members like nodes, members with member formulas, members with locked work status, etc… The code inside write back badi can check for this conditions and process this data somehow: disaggregate to base members, redirect to some base member, etc.

      Unfortunately I have no idea how to do the same in BPC MS.


  • Hi Vadim,

    I have another issue with *DESTINATION_APP.

    I have two models: HR and FI. In HR I have dimensions HR_POSITION, COST_ELEMENT, etc and in FI only COST_CENTER, COST_ELEMENT etc.

    In my
    default.lgf I have following script:


    *IS E, V
    *REC(FACTOR = 1, COST_ELEMENT = 401001)
    *IS A
    *REC(FACTOR = 1, COST_ELEMENT = 401040)

    If I save this values then result in FI is 300.

    POS1 100
    POS2 200

    But if now I change POS1 to110 after save value in FI is 110 instead of 310 (110+200).

    POS1 110
    POS2 200

    Is this
    correct behaviour? Does it mean, that we practically cannot use *DESTINATION_APP in default.lgf in this case.

    Thank you


    • Hi Ivan,

      The question is not directly related to the blog subject, please open a new discussion, I will answer your question. Please also read my other document: How-To: Write default.lgf

      B.R. Vadim

      P.S. Also describe the content of the property HR_POSITION.COST_CENTER in the relation to HR_POSITION.EMP_TYPE

  • Hi Vadim,

    I am also trying to replace the default logic to a Write back BADI. I want the BADI to be triggered for input schedule and imports , have logic in the write back to do some calculations. The problem is the write back is triggering for input schedule(MAN) but not for DM filter. I added both the filters in the BADI but it does not trigger for imports.

    Any idea?


  • Hi Vadim,


    How many maximum records can be passed to write_back method of SAP? We are calling a custom BADI through DEFAULT.LGF in which we are using this method and wanted to know the maximum limit so that we can loop the data to be written in package size.