Skip to Content
Technical Articles

How-To: Write default.lgf

In this article I decided to accumulate some knowledge regarding default.lgf scripts.

Purpose of default.lgf:

To perform calculations triggered by user data send by some input schedule or journal. It can be also launched (if user selects the option) at the end of some standard DM chains (Copy, Move, Import, etc..).

For DM chains like DEFAULT_FORMULAS used to run scripts the default.lgf is NOT triggered.

Scope of default.lgf

When launched the default.lgf will receive scope as a combination of all members of all dimensions of data sent by user and actually saved to the cube. If some records are rejected by write back or validation badi then the scope of default.lgf will not contain the rejected members combination.


Dimension: DIM1 Members: D1M1, D1M2
Dimension: DIM2 Members: D2M1, D2M2

Input form (all intersections in the cube has value 1):

The user decided to change value in the cells marked with yellow to 2:

2 values (D1M1,D2M1) and (D1M2,D2M2) will be sent to the cube.

As a result the scope will be a combination of the following members: D1M1,D2M1,D1M2,D2M2

Generating 4 possible combinations:

Sent by user: (D1M1,D2M1); (D1M2,D2M2) and extra: (D1M2,D2M1) and (D1M1,D2M2)

4 values will be processed by default.lgf.

If the default.lgf is like:

*WHEN ACCOUNT //or any dimension
*IS * //any member

The result will be:

It means, that some extra combinations of members will be processed by default.lgf, not only changed data.

General rules:

1.Don’t use *XDIM_MEMBERSET/*XDIM_ADDMEMBERSET in the default.lgf, do not redefine the scope. The original scope (not huge by the way) have to be processed.

2.Use *IS criteria in *WHEN/*ENDWHEN loop to select members for some calculations.


For DM package script the code is like:

*XDIM_MEMBERSET SOMEDIM=%SOMEDIM_SET%  // member from user prompt - MEMBER1 or some fixed member
*IS * // scoped in *XDIM_MEMBERSET

For default.lgf the code will be:

*IS MEMBER1 // fixed member - condition to perform calculations in REC

3.*XDIM_FILTER can be used sometimes to narrow the scope, but the benefit of filtering against *IS is not clear.Example:

ACCOUNT dimension contains 3 members: ACC1,ACC2,ACC3

*XDIM_FILTER ACCOUNT = [ACCOUNT].properties("ID") = "ACC1"
// The incoming scope will be filtered to ACC1 if present
*IS *

// Filter is reset, %ACCOUNT_SET% contains original scope
*IS *

*XDIM_FILTER ACCOUNT = [ACCOUNT].properties("ID") = "ACC2"
// The incoming scope will be filtered to ACC2 if present
*IS *

User send 1 for all 3 accounts (ACC1,ACC2,ACC3). The result is:

ACC1: 4
ACC2: 6
ACC3: 3

You also have to be on some recent SP level for *XDIM_FILTER to work correctly (read notes – search on “XDIM_FILTER”)

If you have to calculate some function, like:

Result = Func([SomeDim].[Member1],[SomeDim].[Member2],..,[SomeDim].[MemberN]) (N members total)

And store the Result in some member, then you have to write N *WHEN/*ENDWHEN loops to prevent aggregation if more then 1 member is in scope. Without multiple loops the result will be multiplied M times, where M is number of different members sent by input form simultaneously.

Example (multiply 3 members):

*WHEN SomeDim
*IS Member1

*WHEN SomeDim
*IS Member2

*WHEN SomeDim
*IS Member3

In this example the REC line can be the same for all 3 loops (%VALUE% can be replaced by direct member reference):


with minimum performance decrease.

Using LOOKUP to the same model to get expression argument member

In some cases for simple formula like multiplication of 2 members (price * qty), but with long list of members, LOOKUP can be used:

Lets assume we have members in dimension SomeDim:

Price1, Price2, Price3, Price4

Qty1, Qty2, Qty3, Qty4

Result have to be written to:

Amount1, Amount2, Amount3, Amount4

Then we can add for dimension SomeDim properties: MULT, RESULT and TYPE and fill it:

Price1 Qty1 Amount1 Price
Price2 Qty2 Amount2 Price
Price3 Qty3 Amount3 Price
Price4 Qty4 Amount4 Price
Qty1 Price1 Amount1 Qty
Qty2 Price2 Amount2 Qty
Qty3 Price3 Amount3 Qty
Qty4 Price4 Amount4 Qty

Code will be:

*LOOKUP SameModel
*DIM M:SomeDim=SomeDim.MULT //Get member ID stored in property MULT
*DIM MEASURES=PERIODIC //The default storage type of SameModel

*XDIM_MEMBERSET MEASURES=PERIODIC //The default storage type of SameModel
*FOR %T%=Price,Qty //Or 2 loops - to prevent aggregation.

*IS %T%


The lines *DIM MEASURES=PERIODIC and *XDIM_MEMBERSET MEASURES=PERIODIC are required for default.lgf (not required in DM package script)!


In general long and nested *FOR/*NEXT loops have to be avoided due to terrible performance. In most cases instead of *FOR/NEXT loops some property can be created and used in the script code.

Using some value stored as property in calculations

Sometimes it looks as a good idea to store some value in a property and to use it in calculations. Actually it’s a bad idea – you can’t directly reference the property value in the expression, you have to use some %VAR% and long *FOR/*NEXT loop. Always store values in SIGNEDDATA, may be use some dummy members.

SIGN and ACCTYPE in EXPRESSION calculations

The calculations in default.lgf use different sign conversion logic with ACCTYPE then the script run by DM package. As a result the same script can produce different results as a default.lgf and as a script in DM package.

For default.lgf (BPC NW 10 and BPC NW 7.5) all values read in the script scope are sign converted based on ACCTYPE property and the result of EXPRESSION calculation is also sign converted based on ACCTYPE property of the target account:

SignedData_Result = if(Result.ACCTYPE=INC,LEQ, -1, 1) * Function(if(Argument1.ACCTYPE=INC,LEQ, -1, 1) * SignedData_Argument1, if(Argument2.ACCTYPE=INC,LEQ, -1, 1) * SignedData_Argument2, …)


Dimension ACCOUNT: Members: A, B, C

A    INC
B    EXP
C    INC



The data sent by user in the input form will be:A: 5
B: 10

This data will be stored as SIGNEDDATA:

A: -5
B: 10


(-1 * -5 + 1 * 10) * (-1) = -15 (SignedData_Result)

And on the input form:

C: 15

Extra setting for BPC NW 10 was added in the note:


To make default.lgf sign logic same as for DM package

The same script launched by DM package (BPC NW 10) will not have any sign conversions, all calculations will be done with SIGNEDDATA values:

-5 + 10 = 5 (SignedData_Result)

The result on the report:

C: -5

For BPC NW 7.5 the sign logic in DM package is different! The formula will be:

SignedData_Result = Function(if(Argument1.ACCTYPE=INC,LEQ, -1, 1) * SignedData_Argument1, if(Argument2.ACCTYPE=INC,LEQ, -1, 1) * SignedData_Argument2, …)

-1 * -5 + 1 * 10 = 15 (SignedData_Result)

The result on the report:

C: -15


If it’s required to send data to the different model the *DESTINATION_APP statement can be used in default.lgf.

Sign conversion logic is also applicable to writing data using *DESTINATION_APP.

The same rules are applicable to *WHEN/*ENDWHEN loop after the *DESTINATION_APP (by the way, in BPC NW 10 *DESTINATION_APP statement is valid only to the next *WHEN/*ENDWHEN loop, have to be repeated before each *WHEN/*ENDWHEN sending data to other application (in BPC NW 7.5 all *WHEN/*ENDWHEN loops after single *DESTINATION_APP will write to target cube).

If some dimension is missing in the destination model *SKIP_DIM=SomeDim have to be used. But the issue can be in the following case:


DimMissingInTarget: Member1, Member2, …, MemberN (base) – having root parent All

SomeDim: Mem1, Mem2, … – dimension in both Source and Target


SomeDim: Mem1, Mem2, … – dimension in both Source and Target

If some of Member1, Member2, …, MemberN is changed in SourceModel the result of All have to be transferred to TargetModel

The code in default.lgf of SourceModel will be:

//some calculations in the SourceModel
*FOR %M%=Member1,Member2,...,MemberN //list of base members of the skipped dimension


*WHEN DimMissingInTarget
*IS %M%
*WHEN SomeDim //SomeDim - dimension existing both in Source and Target
*IS Mem1,Mem2,... //some list of members of SomeDim changed by user and to be transferred to TargetModel
*REC(EXPRESSION=[DimMissingInTarget].[All]) //Parent All value is used!


N loops for N base members of DimMissingInTarget (useful for small N)Another option for this particular case is to explicitly scope the skipped dimension with *XDIM_MEMBERSET:

*XDIM_MEMBERSET DimMissingInTarget=<ALL>

*WHEN SomeDim //SomeDim - dimension existing both in Source and Target
*IS Mem1,Mem2,... //some list of members of SomeDim changed by user and to be transferred to TargetModel

But in this case you have to put this code at the end of the default.lgf or restore original scope for DimMissingInTarget:

*XDIM_MEMBERSET DimMissingInTarget=%DimMissingInTarget_SET% // %xxx_SET% variable always contains the original script scope.

Custom Logic BADI in default.lgf

It’s also possible to call Custom Logic BADI in default.lgf to perform some calculations that are not easy or even not possible to implement using script logic. The badi have to work with the current scope and can contain some fixed parameters.


//Some calculations before badi call
QUERY=ON //to get records from the current scope
WRITE=ON //to use default write to cube
*END_BADI // Script scope will be reset to initial script scope here if changed before
//Some calculations after badi call

It’s also possible to use RUNLOGIC_PH BADI (How To Implement the RUNLOGIC_PH Keyword in SAP… | SCN) to speed up some calculations using CHANGED parameter. For example – single change of price have to recalculate values in multiple entities and multiple time periods.

APPSET = SameEnvironment
APP = SameModel
DIMENSION SomeDim=%Somedim_SET% //script initial scope

Write Back BADI instead of default.lgf The same functionality can be achieved by Write Back BADI – perform calculations triggered by user input. The details are described here: Calculations in Write Back BADI – Default.lgf R… | SCN

The significant difference between Write Back BADI and default.lgf is that Write Back BADI will receive data sent by user before it’s stored in the cube and only sent values will be processed.

B.R. Vadim

P.S. 2014.06.11 – incorrect case about function with “+/-” removed.

P.P.S. 2014.07.23 – sample for scope added

P.P.P.S. 2014.09.25 – *XDIM_FILTER functionality described

P.P.P.P.S. 2016.02.26 – effect of write back badi on the scope of default.lgf


P.P.P.P.P.P.S. 2016.07.06 – Sign effect for DM packages in BPC NW 7.5

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

    As always this is very useful. When it comes to script logic and BADIs, you are just superb 🙂 . I have a question regarding scoping -

    1. When user sends data through input form, scope is based on what dimensions we have in the row and column axes? Like in your example, we have (D1M1,D2M1); (D1M2,D2M2) and extra: (D1M2,D2M1) and (D1M1,D2M2) as scoped data. What if I had another dimension in any of the two axes? How are other dimensions scoped (from page axis then context?) The last part of the question may sound silly as you would place some calculation in default based on what data (the members selection) you are sending through input form, but just to be sure about scope of other dimensions, asking  this question.

    2. When the data is sent through journal, will the scope be limited to the member selection where journal is posted?

    3. Through DM runs, is everything scoped?



    • Hi Ashish,

      "When user sends data through input form, scope is" NOT "based on what dimensions we have in the row and column axes"! The scope is NOT based on the context!

      Scope is based on ONLY changed values!!! If user changed 3 values, each having one member for each dimension in the model. The combination of all members of changed values will generate the scope for default.lgf.

      Same for journal!

      For DM the scope is based on user selection in the advanced DM script and usially restricted with a number of *XDIM_MEMBERSET statements in the script logic code.

      B.R. Vadim

    • Ashish,

      You can perform a simple test: create some input form with number of base members on column and row axis. Let's assume, that at this moment all cells are empty. Add a simple default.lgf:

      *WHEN ACCOUNT //or any dim

      *IS *



      Save some values using input form and look on results.


      • Hi Vadim,

        In my script logic I had exactly the same thing which you wrote.

        Data that I tried to save through input form -

        Data which was finally there after save and default ran -

        So, it simply means scope is exactly the same for which you enter data.

        I am not able to comprehend this part of scoping -

        Sent by user: (D1M1,D2M1); (D1M2,D2M2) and extra: (D1M2,D2M1) and (D1M1,D2M2)

        If the extra selections are also scoped, should I not see data for 2006.Feb,Material cost and 2006.Jan, Labour cost as 1??



        • Ups, sorry!

          My mistake - to see the effect you have to sent 1 to all intersections before adding default.lgf (or some other value).

          Without previous value the scope still has all 4 combinations, but because there are no records - nothing is selected for WHEN/ENDWHEN.


          • Right, I got it. When_Ref_Data 🙂 the default is transaction mode so that's why it didn't post any record for the 2 extra combinations.

  • Hi Vadim,

    Not sure if I should open a new thread, but I have a question on dynamic calculation.  The following table illustrates what I wanted to do: to sum members for each node and send to a specific member for each node.  For instance, I want to sum MEMBER A1,A2,A3, and save (value of 1+2+3=6) to MEMBER NODE_A_SUM. I think I can repeat the following scripts to do the job. However, it's too repetitive if I have 20 nodes. Also, there can be new nodes/members setup later on and will requre scripts modified.    Is there a way to dynamically perform this calcuation?






    Enjoyed your posts on various topics!  Thanks.


    • Hi Ben,

      It's better to open a new discussion and start the explanation with: Why do you need to have base members with the same value as hierarchy parent node!


      • Thanks Vadim. I posted in a separate discussion "Perform Dynamic Calucation using Script Logic".  I provided some explanation as to the requirements.  Thank You.


  • SIGN and ACCTYPE in Expression Calculation:

    I have found that in the case of a PERIODIC Environment you have to use




      • You wrote in Chapter SIGN and ACCTYPE in Expression Calculation:

        Extra Setting in BPC 10 was added ...


        To make Default.lgf sign logic same as for DM Package

        This only works in YTD Environment.



        • Sorry, but incorrect!

          Test case: 2 models (PERIODIC and YTD) with the same default.lgf:


          *WHEN P_ACCOUNT

          *IS A_600000




          Calculations are performed the same way as for DM package!


          Old behavior:





  • In my Environment i got the following Error Message when using *XDIM_MEMBERSET MEASURES = SIGNEDDATA:

    2016-08-23 14_08_48-Save Results.jpg

    The reason for it might be a BADI call in Default.lgf:

    2016-08-23 14_14_03-Business Planning and Consolidation - Internet Explorer.jpg

    Without BADI call it works.

    On the other Hand, it works fine with *XDIM_MEMBERSET MEASURES= PERIODIC

    in both cases (Input schedule and DM Package)

    • It's a problem with the incorrect code of your badi!

      And *XDIM_MEMBERSET MEASURES= PERIODIC (for PERIODIC cube and YTD for YTD cube) do nothing for sign logic (just tested!)

      Please don't post untested things.

      • Don't claim that this is not tested!

        And don't claim that the code of the badi is incorrect!

        I have tested it very well and it works in my case.

        Feel free to test it with your own BADI than you will see the behaviour.

        • Sorry, but looks like you don't understand basic things 🙁

          Sign logic is relevant to calculations in REC(...), for custom badi it's another story (just debug what you have in ct_data 🙂 ) Side effect of "*XDIM_MEMBERSET MEASURES = SIGNEDDATA" on the badi execution can be corrected in the badi code. But if you don't have REC(...) in your code what for you need "XDIM_MEMBERSET MEASURES" in your script???

          • It seems that you cannot accept that others have conclusions you do not have.

            The starting position for my post was that a call of badi in default logic  has different results when running during send and in DM Package (e.g. IMPORT Package)

            I have one call of custom badi and one call of CALC_ACCOUNT in my default logic.

            The insertion of the code *XDIM_MEMBERSET MEASURES = SIGNEDDATA results in a errormessage during send.

            This occurs regardless of which code is executed in badi. I deny your statement: Side effect of "*XDIM_MEMBERSET MEASURES = SIGNEDDATA" on the badi execution can be corrected in the badi code.

            The errormessage during send occurs even the badi has no relevant code. (One record send, badi gets one record in CT_DATA and does nothing with it)

            I mean to say that the insertion of *XDIM_MEMBERSET MEASURES = PERIODIC in this case solves the problem of the sign problematic.

            That is fact and you cannot ignore it!

          • Sorry, but:

            "The starting position for my post was that a call of badi in default logic  has different results when running during send and in DM Package (e.g. IMPORT Package)" - incorrect, you started the discussion without any badi mentioned 🙂

            And the sign logic is not about badi, but about WHEN/REC/ENDWHEN - clearly stated in my main document. If you have only badi and CALC_ACCOUNT you don't need any *XDIM_MEMBERSET MEASURES statements! What for?

            And at the end - any badi can be easily corrected to work with *XDIM_MEMBERSET MEASURES = SIGNEDDATA. You have to simply replace SIGNEDDATA with nothing 🙂

            LOOP AT ct_data ASSIGNING <ls_rec>.

            <ls_result_rec> = <ls_rec>.

            *... other code

            ASSIGN COMPONENT ujr0_c_measure OF STRUCTURE <ls_result_rec> TO <ls_measure>.

            IF <ls_measure> = 'SIGNEDDATA'.

              <ls_measure> = ''.


            APPEND <ls_result_rec> TO <lt_final>.


            ct_data = <lt_final>.

  • Hi Vadim,

    My question is how in Default logic to work with data which were changed previously in the same Default logic? For example,

    *IS A1

    // Then I need to update account A3 based on changes of account A2.
    *IS A3

    The first idea is to improve the first *WHEN statement, but in reality it is much more complicated scenario that this one.

    To sum up, can default logic distinguish the changes that were done by this default logic?

    Thank you in advance,

    • Hi Oleksandr!

      Each separate WHEN/ENDWHEN will perform commit but the data scope will not change!
      Script has to be:
      //A1 data is sent
      *IS A1
      //A3 data is stored

      //also if A1 is sent
      //calculate A5 using A3 saved on prev step
      *IS A1

  • Greetings! Let me ask a question that is probably so simple I should not ask... but I will anyway! 🙂

    How can I eliminate an entity in a Logic file? The logic file is in BPC 7.5 NW and is for 'Carry Forward'. I have one Entity that I want to make sure is not affected by a carry forward process. I am trying to prove a concept and I am not a BPC script logic expert by any means, so please go easy on me.

    I tried the following as part of the code, but neither caused an error or honored my code:






    //*IS <> [ID](MY_OLD_ENTITY)  <-- this did not work either

    //    ENTITY = %ENTITY_SET%

        TID_RA = %TIME_SET%



  • Hi Vadim,

    I read through this blog and came accroos your advice not to use XDIM_ADDMEMBERSET in default.  However, if the passed data region does not contain the member you need in your calculation (example when using a GET statement), then I believe that there is no other way than to add it?

    Thanks for your feedback.

    • But there is no relation between “member you need in your calculation” and changing scope of script with XDIM_ADDMEMBERSET. In the calculations you can reference additional members using tuple expression or LOOKUP. Also in the calculations you can specify target member.

      The idea of default.lgf is:

      1. User saved some values using input form.
      2. Some other members has to be calculated depending on saved values.


      Accounts: Price, Quantity, Amount


      User can save Price or Quantity or both Price and Quantity. The script will have 2 WHEN/ENDWHEN loops:

      *IS Price
      *IS Quantity


      No XDIM…!

      P.S. "GET" is not supported in BPC NW, only for BPC MS

  • Hi, Vadim,

    Thank you for your post!

    Could you tell me which SCOPE will be sending for Account based calculation business rule in Default.lgf?

    Example of my code in default.lgf, this script calculate F99 - closing balance.


    I tested script many times and see that the default.lgf didn't filter scope that goes to Account based calculation business rule, it's executed every time when I save data in input schedule.


    • It's better to ask this question under the correct tag!

      But in general - what do you mean by filter??? CALC_ACCOUNT is not using any filter in your script - only TID_RA = %TIME_SET%



      • Vadim,

        When I talk about a filter, I mean the scope, that would be processed by default.lgf, when executing CALC_ACCOUNT.

        From my point of view, when I changed some members in input forms, default.lgf should be executed for only changed members, it works fine with statements like WHEN and ENDWHEN, but when we add in default.lfg statements like CALC_ACCOUNT, it works in another way. CALC_ACCOUNT executed always in full range of scope, defined in business rule.

        • Sorry, but it's not a right place to discuss specific issues! Please ask a normal question if you want an answer from me!