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.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor

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