Skip to Content

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.

Example:

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
*REC(EXPRESSION=%VALUE%+1)
*ENDWHEN

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.

Sample:

For DM package script the code is like:

*XDIM_MEMBERSET SOMEDIM=%SOMEDIM_SET%  // member from user prompt - MEMBER1 or some fixed member
*WHEN SOMEDIM
*IS * // scoped in *XDIM_MEMBERSET
*REC(...)
*ENDWHEN

For default.lgf the code will be:

*WHEN SOMEDIM
*IS MEMBER1 // fixed member - condition to perform calculations in REC
*REC(...)
*ENDWHEN

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
*WHEN ACCOUNT
*IS *
*REC(EXPRESSION=%VALUE%+1) // +1 for ACC1
*ENDWHEN

*XDIM_MEMBERSET ACCOUNT=%ACCOUNT_SET%
// Filter is reset, %ACCOUNT_SET% contains original scope
*WHEN ACCOUNT
*IS *
*REC(EXPRESSION=%VALUE%+2) // +2 for ACC1,ACC2,ACC3
*ENDWHEN

*XDIM_FILTER ACCOUNT = [ACCOUNT].properties("ID") = "ACC2"
// The incoming scope will be filtered to ACC2 if present
*WHEN ACCOUNT
*IS *
*REC(EXPRESSION=%VALUE%+3) //+3 for ACC2
*ENDWHEN

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
*REC(EXPRESSION=%VALUE%*[SomeDim].[Member2]*[SomeDim].[Member3],SomeDim=ResultMember)
*ENDWHEN

*WHEN SomeDim
*IS Member2
*REC(EXPRESSION=%VALUE%*[SomeDim].[Member1]*[SomeDim].[Member3],SomeDim=ResultMember)
*ENDWHEN

*WHEN SomeDim
*IS Member3
*REC(EXPRESSION=%VALUE%*[SomeDim].[Member1]*[SomeDim].[Member1],SomeDim=ResultMember)
*ENDWHEN

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

*REC(EXPRESSION=[SomeDim].[Member1]*[SomeDim].[Member2]*[SomeDim].[Member3],SomeDim=ResultMember)

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:

ID MULT RESULT TYPE
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
*ENDLOOKUP

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

*WHEN SomeDim.TYPE
*IS %T%
*REC(EXPRESSION=%VALUE%*LOOKUP(M),SomeDim=SomeDim.RESULT)
*ENDWHEN

*NEXT

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

*FOR/NEXT Loops

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

Example:

Dimension ACCOUNT: Members: A, B, C

ID   ACCTYPE
A    INC
B    EXP
C    INC

default.lgf

*WHEN ACCOUNT
*IS A
*REC(EXPRESSION=%VALUE%+[ACCOUNT].[B],ACCOUNT=C)
*ENDWHEN

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

Calculations:

(-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: http://service.sap.com/sap/support/notes/1848284

*XDIM_MEMBERSET MEASURES = SIGNEDDATA

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

*DESTINATION_APP

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:

SourceModel:

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

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

TargetModel:

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

*DESTINATION_APP=TargetModel
*SKIP_DIM=DimMissingInTarget

*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!
*ENDWHEN
*ENDWHEN

*NEXT

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>
*DESTINATION_APP=TargetModel
*SKIP_DIM=DimMissingInTarget

*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=%VALUE%)
*ENDWHEN

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.

Example:

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

RUNLOGIC_PH BADI
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.

*START_BADI RUNLOGIC_PH
QUERY=OFF
WRITE=ON
LOGIC = CALLED_LOGIC.LGF
APPSET = SameEnvironment
APP = SameModel
DIMENSION ENTITY=BAS(ALLENTITIES)
DIMENSION SomeDim=%Somedim_SET% //script initial scope
...
CHANGED=ENTITY
*END_BADI

Write Back BADI instead of default.lgfThe 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.S. 2016.05.30 – LOOKUP – *DIM MEASURES=PERIODIC and *XDIM_MEMBERSET MEASURES=PERIODIC effect

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

To report this post you need to login first.

29 Comments

You must be Logged on to comment or reply to a post.

  1. Ashish Gupta

    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?

    Regards,

    Ashish

    (0) 
    1. Vadim Kalinin Post author

      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

      (0) 
    2. Vadim Kalinin Post author

      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 *

      *REC(EXPRESSION=%VALUE%+1)

      *ENDWHEN

      Save some values using input form and look on results.

      Vadim

      (0) 
      1. Ashish Gupta

        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??

        Regards,

        Ashish

        (0) 
        1. Vadim Kalinin Post author

          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.

          Vadim

          (0) 
          1. Ashish Gupta

            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.

            (0) 
  2. Benjamin Tan

    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?

    *WHEN DIM_ACCOUNT

    *IS MEMBERA1,MEMBERA2,MEMBERA3

    *REC(FACTOR=1,DIM_ACCOUNT=NODE_A_SUM

    *ENDWHEN

    Pic1.jpg

    Enjoyed your posts on various topics!  Thanks.

    Ben

    (0) 
    1. Vadim Kalinin Post author

      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!

      Vadim

      (0) 
      1. Benjamin Tan

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

        Ben

        (0) 
  3. Achim Linker

    SIGN and ACCTYPE in Expression Calculation:

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

    *XDIM_MEMBERSET MEASURES = PERIODIC.

    Regards,

    Achim

    (0) 
      1. Achim Linker

        You wrote in Chapter SIGN and ACCTYPE in Expression Calculation:

        Extra Setting in BPC 10 was added …

        *XDIM_MEMBERSET MEASURES = SIGNEDDATA.

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

        This only works in YTD Environment.

        Regards,

        Achim

        (0) 
        1. Vadim Kalinin Post author

          Sorry, but incorrect!

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

          *XDIM_MEMBERSET MEASURES = SIGNEDDATA

          *WHEN P_ACCOUNT

          *IS A_600000

          *REC(EXPRESSION=%VALUE%+[P_ACCOUNT].[A_400000],P_ACCOUNT=A_600005)

          *ENDWHEN

          Results:

          Calculations are performed the same way as for DM package!

          Without *XDIM_MEMBERSET MEASURES = SIGNEDDATA

          Old behavior:

          PERIODIC:

          A_600005=35

          YTD

          A_600005=51

          (0) 
  4. Achim Linker

    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)

    (0) 
    1. Vadim Kalinin Post author

      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.

      (0) 
      1. Achim Linker

        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.

        (0) 
        1. Vadim Kalinin Post author

          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???

          (0) 
          1. Achim Linker

            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!

            (0) 
            1. Vadim Kalinin Post author

              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> = ”.

              ENDIF.

              APPEND <ls_result_rec> TO <lt_final>.

              ENDLOOP.

              ct_data = <lt_final>.

              (0) 
  5. Oleksandr Master

    Hi Vadim,

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

    *WHEN ACCOUNT
    *IS A1
    *REC(FACTOR = [ACCOUNT].[A2], ACCOUNT = A3)
    *ENDWHEN

    // Then I need to update account A3 based on changes of account A2.
    *WHEN ACCOUNT
    *IS A3
    *REC(FACTOR = 1/[ACCOUNT].[A4], ACCOUNT = A5)
    *ENDWHEN

    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,
    Oleksandr

    (0) 
    1. Vadim Kalinin Post author

      Hi Oleksandr!

      Each separate WHEN/ENDWHEN will perform commit but the data scope will not change!
      Script has to be:
      //A1 data is sent
      *WHEN ACCOUNT
      *IS A1
      *REC(FACTOR = [ACCOUNT].[A2], ACCOUNT = A3)
      *ENDWHEN
      //A3 data is stored

      //also if A1 is sent
      //calculate A5 using A3 saved on prev step
      *WHEN ACCOUNT
      *IS A1
      *REC(EXPRESSION = [ACCOUNT].[A3]/[ACCOUNT].[A4], ACCOUNT = A5)
      *ENDWHEN

      (1) 
  6. Kurt Dukes

    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:

     

    *RUN_PROGRAM COPYOPENING

        CATEGORY = %CATEGORY_SET%

        CURRENCY = %RPT_CURRENCY_SET%

    *WHEN ENTITY
    *IS <> BAS](MY_OLD_ENTITY)

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

    //    ENTITY = %ENTITY_SET%

        TID_RA = %TIME_SET%

    *ENDRUN_PROGRAM

     

    (0) 
  7. Bjorn Van Damme

    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.

    (0) 
    1. Vadim Kalinin Post author

      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.

      Sample:

      Accounts: Price, Quantity, Amount

      Amount=Price*Quantity

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

      *WHEN ACCOUNT
      *IS Price
      *REC(EXPRESSION=%VALUE%*[ACCOUNT].[Quantity],ACCOUNT=Amount)
      *ENDWHEN
      
      *WHEN ACCOUNT
      *IS Quantity
      *REC(EXPRESSION=%VALUE%*[ACCOUNT].[Price],ACCOUNT=Amount)
      *ENDWHEN

       

      No XDIM…!

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

      (0) 

Leave a Reply