Script Logic

10/21/2020
Application Help - SAP Business Planning

and Consolidation, version for SAP
BW/4HANA (Standard con guration)
Generated on: 2020-10-21
SAP Business Planning and Consolidation, version for SAP BW/4HANA | 11.0 SP04
PUBLIC
Original content: https://help.sap.com/viewer/d1711b4a86b447c38415629229003c02/11.0.4/en-US
Warning
This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product documentation. The
information included in custom documentation may not re ect the arrangement of topics in the SAP Help Portal, and may be missing
important aspects and/or correlations to other topics. For this reason, it is not for productive use.
For more information, please visit the https://help.sap.com/viewer/disclaimer.
Script Logic
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=20724612&topics=53f895ad28cb498eb3ac79f3e9a6… 1/63
10/21/2020
Script logic is a feature that allows you to create les called logic scripts containing instructions for performing calculations on planning
and consolidation data
Features
You can perform logic calculations on base level members only. In addition, logic is speci c to each model.
Business Planning and Consolidation provides a library of MDX formulas, and the EnvironmentShell sample environment contains a
number of logic functions.
 Note
Logic keywords are not case-sensitive. However, all environment, model, dimension, and member names in K2 are case-sensitive.
You have the following two les for each piece of script logic you create:
An .LGF le, which is an ASCII le you create and edit when setting up logic calculations. You access the .LGF le through the logic
editor.
An .LGX le, which is the compiled logic le created by the system when you validate and save your logic. This is an executable
version of the .LGF le that is not stored in Business Planning and Consolidation.
Default logic is a special logic statement that is executed on every writeback to a model. All logic in Default.LGF is run after data sends.
Data is rst committed to the model and then, Default.LGF is run on model data. Having all of your logic in the Default.LGF logic le
might become unmanageable. Therefore you can create other logic les, such as FXTrans.LGF for foreign currency translation and
ICElim.LGF for intercompany eliminations. Your default logic can contain an INCLUDE statement to execute speci c logic in real-time,
such as currency translation if desired, rather than having to run a separate batch process.
You access logic les from the Script Logic subdirectory within the hierarchy of a model.
Logic Library
Business Planning and Consolidation has a library of standard logic functions available for your use. The le has the extension .LGF, which
can be called at validation by using the INCLUDE function in your logic le. The logic module scans the library le for the appropriate
formulas to use based on the information in the .LGF le.
The following are examples of logic delivered with Business Planning and Consolidation:
Allocation.lgf: runs an allocation
Calcaccount.lgf: used to prepare Cash Flow; runs an Account Calculation business rule
Consolidation.lgf: used to run a Legal Consolidation business rule
Copy_Opening.lgf: used to run a Balance Carry Forward business rule
FX_Trans.lgf: used to run currency conversion
ICBooking.lgf: used for running Intercompany reconciliation and difference posting
ICData.lgf: used to run Intercompany reconciliation
ICElim.lgf: used to run Intercompany reconciliation
MDXlib.lgf: library of MDX nancial functions
System_Constants.lgf: stores constant values for use within script logic. See the System Constants File section that follows for
more information.
System_Library.lgf: includes basic examples of a set of keywords
Validation.lgf: used for running a Validation rule
10/21/2020
System Constants File
The system constants le is the logic le that maps your dimension names for a model to the standard Business Planning and
Consolidation logic. By updating the dimension constants le with your dimensions, you avoid having to change or rewrite any of the
standard functions that are included with Business Planning and Consolidation.
The system constants le is located in the \\root\Webfolders\ <Environment>\systemlibrary\logiclibrary folder. You

can edit this le using download and upload functions from transaction UJFS in the ABAP interface.
Running Script Logic
Script logic can be automatically invoked each time the system sends data to the database. Instructions in the default logic le are
executed immediately after data is sent and you can see the results immediately. Script logic can be run from Data Manager for batch
processing of formulas. Using Data Manager to execute Logic module formulas is useful for calculations that do not need to be executed
immediately. For example, you may decide to wait until all data has been entered in the local currency before generating the translated
amounts in reporting currencies.
Activities
From the Planning and Consolidation Administration screen, you can view all logic scripts for a model by choosing Logic Scripts under the
Rules section. After that select a model and choose Open. All logic scripts that have been set up for that model display.
You can create a new logic script for the selected model by choosing New, then assigning a name to the logic script. You can type directly
into the logic editor. You can also insert Business Planning and Consolidation keywords, MDX keywords, dimension names, and member
names from the dropdown lists, replacing variables in the keywords as appropriate. To add a keyword from the dropdown lists to a line in a
script, you can double-click on a keyword, you can select a keyword and then select Insert Keyword, and you can drag and drop a keyword
from the dropdown list into a line in the logic editor.
You can comment out and uncomment blocks of script logic, as well as individual lines, in the logic editor.
When you create new logic script and edit an existing script, you can validate its syntax. Any problems with the logic display in the lower
portion of the logic editor with line numbers to make locating and resolving the problems easier.
You can copy an existing logic script by selecting a le, then providing a name for the new script, and modifying it as you need.
You can use the following color coding in the logic editor to assist in writing and troubleshooting logic scripts:
Keywords display in blue
Constant values display in green
Comments display in grey
Incorrect syntax, such as parenthesis errors, misspelled keywords and dimension names, and unrecognized words, displays in red
You can easily resolve errors in script logic using the error lines in the lower portion of the logic editor window. Errors in a script appear by
line number.
More Information
For more detailed documentation of script logic and examples, see the Enterprise Performance Management (EPM) How-to Guides
section of the SAP SDN at: http://wiki.sdn.sap.com/wiki/display/BPX/Enterprise+Performance+Management+%28EPM%29+How-
to+Guides .
Related Information
Library of MDX Functions
Logic Keyword Reference
10/21/2020
Library of MDX Functions

Business Planning and Consolidation provides several multidimensional expressions ( MDX) functions you can use in your dimension rule
formulas. You can also use some of these MDX functions in advanced rule formulas.
A majority of the MDX functions de ne industry-standard nancial ratios. You can use ratios to evaluate the performance of your business
and identify potential problems. Ratios expose factors such as the earning power, solvency, efficiency, and debt load of your business.
The following table describes some of the more common MDX functions:
MDX Function Description Parameters
Ancestor Returns the ancestor of a member at a speci ed level <Member>, <Level>
ClosingPeriod Returns the last sibling among the descendants of a member [<Level>[, <Member>] ]
at a level
Cousin Returns the member with the same relative position under a <Member1>, <Member2>
member as the member speci ed
Current Member Returns the current member along a dimension during an (none)
iteration
Default Member Returns the default member of a dimension (none)
FirstChild Returns the rst child of a member (none)
FirstSibling Returns the rst child of the parent of a member (none)
IsEmpty Determines if an expression evaluates to the empty cell value <Expression>
Item Returns a member from a tuple <Numeric Expression>
Lag Returns a member prior to the speci ed member along the <Numeric Expression>
member's dimension
LastChild Returns the last child of a member (none)
LastSibling Returns the last child of the parent of a member (none)
Lead Returns a member further along the speci ed member's <Numeric Expression>
dimension
Members Returns the member whose name is speci ed by a string (none)

expression
NextMember Returns the next member in the level that contains a (none)
speci ed member
OpeningPeriod Returns the rst sibling among the descendants of a member [<Level>[, <Member>] ]
at a level
ParallelPeriod Returns a member from a prior period in the same relative [<Level>[, <Numeric Expression>[,
position as a speci ed member <Member>] ] ]
Parent Returns the parent of a member (none)
PrevMember Returns the previous member in the level that contains a (none)
speci ed member
Aggregate Returns a calculated value using the appropriate aggregate <Set>[, <Numeric Expression>]
function, based on the context of the function
Avg Returns the average value of a numeric expression evaluated <Set>[, <Numeric Expression>]
over a set
CoalesceEmpty Coalesces an empty cell value to a number <Numeric Expression>[, <Numeric

Expression>...]
10/21/2020
MDX Function Description Parameters
Correlation Returns the correlation of two series evaluated over a set <Set>, <Numeric Expression>[, <Numeric
Expression>]
Count Returns the number of tuples in a set, empty cells included <Set>[, EXCLUDEEMPTY | INCLUDEEMPTY]
unless the optional EXCLUDEEMPTY ag is used
IIf Returns one of two values determined by a logical test <Logical Expression>, <Numeric
Expression>, <Numeric Expression>
LinRegIntercept Calculates the linear regression of a set and returns the value <Set>, <Numeric Expression>[, <Numeric
of b in the regression line y = ax + b Expression>]
LinRegPoint Calculates the linear regression of a set and returns the value <Numeric Expression>, <Set>, <Numeric
of y in the regression line y = ax + b Expression>[, <Numeric Expression>]
LinRegR2 Calculates the linear regression of a set and returns R2 (the <Set>, <Numeric Expression>[, <Numeric
coefficient of determination) Expression>]
LinRegSlope Calculates the linear regression of a set and returns the value <Set>, <Numeric Expression>[, <Numeric
of a in the regression line y = ax + b Expression>]
LinRegVariance Calculates the linear regression of a set and returns the <Set>, <Numeric Expression>[, <Numeric
variance associated with the regression line y = ax + b Expression>]
Max Returns the maximum value of a numeric expression <Set>[, <Numeric Expression>]
evaluated over a set
Median Returns the median value of a numeric expression evaluated <Set>[, <Numeric Expression>]
over a set
Min Returns the minimum value of a numeric expression <Set>[, <Numeric Expression>]
evaluated over a set
Sum Returns the sum of a numeric expression evaluated over a set <Set>[, <Numeric Expression>]
For additional NW BI MDX keywords, run function module BAPI_MDPROVIDER_GET_FUNCTIONS via transaction SE37.
Custom Logic and BADI

You use this instruction to call any custom ABAP programming you have written.
Activities
Run the following instruction to call custom ABAP programs:
*CALL_CUSTOM_LOGIC <filter_value_of_the_BADI>
where lter_value_of_the_BADI is the name of the lter you provided during the BADI implementation of UJ_CUSTOM_LOGIC BADI.
Custom logic example
*CALL_CUSTOM_LOGIC COMPLEX_ALLOCATION
BADI examples
*START_BADI / *END_BADI call any custom ABAP programming written using UJ_CUSTOM_LOGIC BADI (Transaction SE19) and
allow you to export parameters to ABAP codes in the BADI.
Syntax
*START_BADI <filter_value_of_your_BADI_implementation>
10/21/2020
<key1> = <value1>
<key2> = <value2>
*END_BADI
where filter_value_of_your_BADI_implementation is the name of the lter you provided during the BADI implementation of
UJ_CUSTOM_LOGIC BADI.
Syntax example
The following example shows how to call an implemented BADI, with CALC_ACCT as the lter value, for adding two accounts to a
destination account:
*START_BADI ROUND
DECIMAL = 2
*END_BADI
The DECIMAL parameter is visible in the IT_PARAM internal table inside the EXECUTE method. In the EXECUTE method, you can write
custom code to change the incoming transactional data of CT_DATA.
Optional Parameters
You can use the following optional parameters within a *START_BADI / *END_BADI instruction:
Query - Performs the default query. Valid values are On, the default, and Off. Set Query to Off if you want to perform your own query.
Write - Automatically writes back the data. Valid values are On, the default, and Off.
Example
Implementing code (in EXECUTE method of the implemented class) for declining depreciation
 Note
Before you can use a BADI in script logic, implement UJ_CUSTOM_LOGIC BADI from transaction SE19. See the ABAP online help at
http://help.sap.com/saphelp_nw70/helpdata/en/32/a83942424dac04e10000000a1550b0/content.htm . for information on how
to implement a BADI.
METHOD if_uj_custom_logic~execute.
DATA: ls_param TYPE ujk_s_script_logic_hashentry,
l_log TYPE string,
l_ast_acct(16) TYPE c,
l_year(3) TYPE n,
l_percentage(3) TYPE p,
lo_model TYPE REF TO if_uj_model,
lo_dim TYPE REF TO if_uja_dim_data,
ls_dim TYPE uja_s_dim,
10/21/2020
time_dim(16) TYPE c,
lr_rec TYPE REF TO data,
lr_result_rec TYPE REF TO data,
l_intermediate_value TYPE uj_sdata,
lt_final TYPE REF TO data.
FIELD-SYMBOLS: <ls_rec> TYPE ANY,
<ls_result_rec> TYPE ANY,
<ls_time> TYPE ANY,
<ls_signed.data> TYPE ANY,
<lt_final> TYPE STANDARD TABLE
* Make sure all the parameters are passed.
CLEAR ls_param.
READ TABLE it_param WITH KEY hashkey = 'YEAR' INTO ls_param.
IF sy-subrc NE 0.
l_log = 'You have not specified the parameter ''YEAR'' which is required.'.
cl_ujk_logger=>log( i_object = l_log ).
RAISE EXCEPTION TYPE cx_uj_custom_logic.
EXIT.
ENDIF.
l_year = ls_param-hashvalue.
CLEAR ls_param.
READ TABLE it_param WITH KEY hashkey = 'PERCENTAGE' INTO ls_param.
IF sy-subrc NE 0.
l_log = 'You have not specified the parameter ''PERCENTAGE'' which is required.'.
cl_ujk_logger=>log( i_object = l_log ).
RAISE EXCEPTION TYPE cx_uj_custom_logic.
EXIT.
ENDIF.
l_percentage = ls_param-hashvalue.
* Get name of the account dim
10/21/2020
cl_uj_model=>get_model( EXPORTING i_appset_id = i_appset_id
RECEIVING ro_model = lo_model ).
CALL METHOD lo_model->get_dim_data_by_type
EXPORTING
i_dim_type = uj00_cs_dim_type-time
i_appl_id
= i_appl_id
RECEIVING
ro_dim_data = lo_dim.
TRY.
CALL METHOD lo_dim->get_info
IMPORTING
es_dim_info = ls_dim.
ENDTRY.
time_dim = ls_dim-dimension. TRANSLATE time_dim TO UPPER CASE.
CREATE DATA lt_final LIKE ct_data.
ASSIGN lt_final->* TO <lt_final>. CREATE DATA lr_result_rec LIKE LINE OF ct_data. ASSIGN
lr_result_rec->* TO <ls_result_rec>. CREATE DATA lr_rec LIKE LINE OF ct_data. ASSIGN lr_rec->* TO
<ls_rec>.
* Loop through incoming data and create a result set
LOOP AT ct_data ASSIGNING <ls_rec>.
<ls_result_rec> = <ls_rec>.
ASSIGN COMPONENT time_dim OF STRUCTURE <ls_result_rec> TO <ls_time>.
<ls_time>+0(4) = is <ls_time>+0(4) + l_year.
ASSIGN COMPONENT 'SIGNEDDATA' OF STRUCTURE <ls_result_rec> TO <ls_signeddata>.
DO l_year TIMES.
l_intermediate_value = l_intermediate_value + ( <ls_signeddata> - l_intermediate_value ) *

l_percentage / 100.
ENDDO.
<ls_signeddata> = <ls_signeddata> - l_intermediate_value.
APPEND <ls_result_rec> TO <lt_final>.
ENDLOOP.
10/21/2020
* Send the result data back.
 Note
Business Planning and Consolidation always overwrites existing values.
ct_data = <lt_final>.
ENDMETHOD.
Script logic le content to call the BADI:
*START_BADI DECD
QUERY = ON
WRITE = ON
YEAR = 1
PERCENTAGE = 10 *END_BADI
 Note
ET_MESSAGE in the BADI logs the messages to the Data Manager.
If you want to stop the execution, raise the cx_uj_custom_logic exception within a BADI implementation.
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be
used in a productive system environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of
certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors
or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or by its gross negligence.
More Information
For instructions about creating an SAP Business Add-In, see the ABAP model help in the SAP NetWeaver Library.
Logic Keyword Reference

This reference contains descriptions of all the logic keywords you can use in this product.
More Information
*ADD / *ENDADD
*BEGIN / *END
*DESTINATION_APP
*FOR / *NEXT
*FUNCTION / *ENDFUNCTION
*INCLUDE
*REC
LOOKUP
*RUNALLOCATION
*SELECT
10/21/2020
*SELECTCASE / *ENDSELECT
*SUB( ) / *ENDSUB
*WHEN / *ENDWHEN
*XDIM_MEMBERSET
*XDIM_ADDMEMBERSET
*XDIM_MAXMEMBERS
*XDIM_PACKAGEBY
*XDIM_FILTER
*COMMIT
Special Keywords
TMVL Parameter
*ADD / *ENDADD
This structure allows you to automatically cumulate a set of members to a calculated member as speci ed in a comma delimited range.
The range can be dynamically derived using a *SELECT( ) instruction. See *SELECT.
The syntax is:
*ADD {variable} = {set}
{formula}
*ENDADD
 Example
*ADD %ACC%=[CE0004010],[CE0004020],[CE0004030] [#CE0661000] = %ACC%/[CE0652000]
*ENDADD
*COMMIT
[#CE00661000] = [CE0661000]/[CE0652000]
The ADD statement expands into:
[P_ACCT].[#CE0661000] =[P_ACCT].[CE0004010]/[P_ACCT].[CE0652000]+[P_ACCT].[CE0004020]/[P_ACCT].
 Note
The expression to the right of the equals sign ( = ) currently does not support more complex expressions.
Only one formula can be written inside the ADD/ ENDADD structure.
*BEGIN / *END
https://help.sap.com/http.svc/dynamicpdfcontentpreview?deliverable_id=20724612&topics=53f895ad28cb498eb3ac79f3e9a… 10/63
10/21/2020
The BEGIN/ END structure can be used to split long formulas across multiple lines to improve readability.
The validation process trims and joins all lines between the BEGIN and END statements.
 Example
*BEGIN
[P_ACCT].[#CE0661000] =
[P_ACC].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[CE0004030] )
[P_ACCT].[CE0652000]
*END
*DESTINATION_APP
The DESTINATION_APP keyword allows you to write the results of calculations to a different model.
Syntax
*DESTINATION_APP = {app name}
Often, the destination model shares only some of the dimensions of the original model. In this case, the missing dimensions can be
dropped from the original records with the instruction:
*SKIP_DIM= {dimension name}[,{dimension name},…]
When the original model has dimensions that are not found in the destination model, the SKIP_DIM keyword is mandatory. Validation
cannot pass without the SKIP_DIM keyword.
Multiple dimension names can be supplied to the instruction separated either by commas or by multiple SKIP_DIM instructions entered
on separate lines.
If the destination model has dimensions that do not exist in the original model, these can be added to the passed records, using the
instruction:
*ADD_DIM {dimension name}={value}[,{dimension name}={value} [, {dimension name} = {dimension

name(source): Property name}, #]
Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple ADD_DIM instructions
entered on separate lines. Dimension properties (dimension from the source model) are also supported.
Example:
To explain DESTINATION_APP with SKIP_DIM, ADD_DIM, and RENAME_DIM, another model DETAIL_PLAN is created by copying the
PLANNING model from the delivered EnvironmentShell. It is necessary to do the following steps:
Create new dimensions PRODUCT and MARKET and add these to the DETAIL_PLAN model
Replace P_ACCT with P_ACCTDETAIL
Remove the P_ACTIVITY dimension from the DETAIL_PLAN InfoProvider using the following syntax:
10/21/2020
*XDIM_MEMBERSET TIME = 2006.AUG
*XDIM_MEMBERSET CATEGORY=ACTUAL
*DESTINATION_APP=DETAIL_PLAN
*SKIP_DIM = P_ACTIVITY
*ADD_DIM P_DATASRC=INPUT, MARKET = PRODUCT:MARKET
*RENAME_DIM P_ACCT=P_ACCTDETAIL
*WHEN CATEGORY
*IS "ACTUAL"
*REC(EXPRESSION=%VALUE%)
*ENDWHEN
Explanation: DETAIL_PLAN is the target model, which has all dimensions of PLANNING except for P_ACCT. This dimension is replaced
with P_ACCTDETAIL. Also, DETAIL_PLAN has two additional dimensions, namely P_DATASRC and MARKET. The above script logic
moves the data into DETAIL_PLAN with:
P_DATASRC de ned by the keyword INPUT
MARKET by using the value of the property 'MARKET' of the dimension PRODUCT, which must exist in the source model
The corresponding values of P_ACCT are copied to P_ACCTDETAIL
The keyword RENAME_DIM can be used, to change name of one or more dimensions. The syntax is:
*RENAME_DIM {dimension name}={value}[,{dimension name}={value},…]
This instruction can be used when data is to be written into a model where a dimension is named with a different ID.
Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple RENAME_DIM
instructions entered on separate lines.
Any combination of the three keywords, above, is supported.
Examples
Example 1
Environment: EnvironmentShell_V
Model: PLANNING
In this example, EnvironmentShell_V is a copy of EnvironmentShell and COPY_PLANNING is a copy of the PLANNING model.
You can execute the script, shown in this example, in a PLANNING model to copy ACTUAL data to the COPY_PLAN model.
If the *DESTINATION_APP command appears once in the middle of the script, all remaining data writing of the script logic le occurs in
the referenced destination model. Any data writes before the *DESTINATION_APP are written in the model where the script is currently
being run.

10/21/2020
*DESTINATION_APP=COPY_PLANNING
*WHEN CATEGORY
*IS "ACTUAL"
*ENDWHEN
Example 2
To explain DESTINATION_APP with SKIP_DIM, ADD_DIM, and RENAME_DIM, another model DETAIL_PLAN is created by copying the
PLANNING model from the delivered EnvironmentShell. It is necessary to:
Create new dimensions PRODUCT and MARKET and add these to the DETAIL_PLAN model
Replace P_ACCT with P_ACCTDETAIL
Remove the P_ACTIVITY dimension from the DETAIL_PLAN InfoProvider

*DESTINATION_APP=DETAIL_PLAN
*SKIP_DIM = P_ACTIVITY
*ADD_DIM P_DATASRC=INPUT, PRODUCT = NO_PRODUCT, MARKET = NO_MARKET
*RENAME_DIM P_ACCT=P_ACCTDETAIL
*WHEN CATEGORY
*IS "ACTUAL"
*ENDWHEN
Explanation
DETAIL_PLAN is the target model, which has all dimensions of PLANNING except for P_ACCT. This dimension is replaced with
P_ACCTDETAIL. Also, DETAIL_PLAN has two additional dimensions, namely PRODUCT, and MARKET.
The above script logic moves the data into DETAIL_PLAN with:
Blank data in the PRODUCT and MARKET dimensions
P_DATASRC de ned by the keyword INPUT
corresponding values of P_ACCT copied to P_ACCTDETAIL
*FOR / *NEXT
*FOR / *NEXT is used to repeat certain scripts written between a FOR and an immediate NEXT for a set of members. Sets of members
can be provided either directly in the FOR statement or through variables.
The Logic Module supports any number of FOR… NEXT loops in the body of the logic les. The syntax is the following:
*FOR {variable1} = {set1} [ AND {variable2={set2}]
{text}
10/21/2020
{text}
*NEXT
 Example
In a logic le, you may need to repeat some calculation for a set of entities. This works automatically when you write:
*XDIM_MEMBERSET TIME = 2006.JAN
*XDIM_MEMBERSET CATEGORY = Q1FCST_LOAD
*FOR %Q1% = 2006.JAN, 2006.FEB, 2006.MAR
*RUNALLOCATION
*FACTOR=1/3
*DIM TIME WHAT = 2009.JAN; WHERE = %Q1%;
*DIM CATEGORY WHAT=Q1FCST_LOAD; WHERE=FQ1;
*ENDALLOCATION
*NEXT
Assuming the forecast data for Q1 is loaded in 2006.JAN, the above script allocates this data into each period in Q1 equally.
 Note
Only one variable is allowed per *FOR statement.
*FUNCTION / *ENDFUNCTION
A user-de ned function is the name of a placeholder that you can insert into formulas in place of a corresponding MDX statement or part of
one. This can greatly improve the readability of a logic statement.
The de nitions of the logic functions can be inserted anywhere in a logic le or in an included le. Their syntax is the following:
For single line functions
*FUNCTION {functionname}({Param1}[,{Param2}…]) = {Function Text}
For multi-line functions
*FUNCTION {functionname}({Param1}[,{Param2}…])
{Function text}
{Function text}
10/21/2020
*ENDFUNCTION
An unlimited number of functions can be de ned within a script logic le.
An unlimited number of parameters can be passed to a function to dynamically modify the corresponding MDX string.
Functions currently cannot be nested, meaning a function cannot contain another function.
The position of the functions in the logic le is irrelevant, unless the same function is rede ned, in which case the new de nition of the
function applies only from the point of the rede nition.
The values of the passed parameters are replaced in the function text without any validation, even if they are embedded in longer words.
Use caution when de ning the names of the parameters to avoid the risk of con icts with MDX reserved words and with the text
surrounding them in logic. The best practice is to always surround the name of the parameters with a delimiter, as in the following example:
 Example
*FUNCTION Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION[#CE0661000] = Price([CE0004000],[CE0652000])
The example calculates the price. You do not have to check the denominator for zero to avoid a divide-by-zero error. The Script Logic
engine automatically replaces the divide-by-zero error with a zero.
You can also use *FUNCTION to substitute members or dimensions to make scripts more readable.
*FUNCTION PERSONAL_COST = CE0004000
*FUNCTION LAB_HOUR = CE0652000
*FUNCTION PER_PRICE = CE0661000
*FUNCTION ACCOUNT = P_ACCT
Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION
[ACCOUNT].[#PER_PRICE] = Price([ACCOUNT].[PERSONAL_COST],[ACCOUNT].[LAB_HOUR])
The following characters, plus the blank character, are invalid in logic functions names:
+-/*^%><=()[]{},.;':&\|#~"
*INCLUDE
Multiple les can be combined into one logic le by the use of the instruction INCLUDE.
10/21/2020
During the LGX generation of the script logic execution step, the statements in the INCLUDE le are combined with the main le.
 Example
*INCLUDE FUNCTION_DEFINITIONS.LGF
[ACCOUNT].[#PER_PRICE] =
Price([ACCOUNT].[PERSONAL_COST],[ACCOUNT].[LAB_HOUR])
A FUNCTION_DEFINITIONS.LGF le can include all de nitions:
*FUNCTION PERSONAL_COST = CE0004000
*FUNCTION LAB_HOUR = CE0652000
*FUNCTION PER_PRICE = CE0661000
*FUNCTION ACCOUNT = P_ACCT
Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION
*REC
The *REC( ) instruction tells the program what to do once the speci ed criteria has been met.
Each REC instruction generates one new record to post to the database. Each source record can generate as many records as desired, even
pointing to the same destination cell.
The parameters of the REC( ) function specify what to modify of the original record. Any dimension member can be modi ed using the
following syntax:
{DimensionName}={member}
 Example
*XDIM_MEMBERSET P_ACCT = CE0004010
*WHEN CATEGORY
*IS ACTUAL *REC(FACTOR = 1.1, CATEGORY="FORECAST")
*ENDWHEN
The {member} must be enclosed in double quotes and can contain the name of any dimension enclosed between percent signs (for
example: ENTITY="IC_%ENTITY%"). In this case, the dimension name is replaced with the value of the current member for that
dimension, and not with just the dimension name.
You can use property values in WHEN statement.
10/21/2020
 Example
*XDIM_MEMBERSET CATEGORY = PLAN
*WHEN TIME.YEAR
*IS "2007"
*REC(FACTOR = 1.1, CATEGORY="FORECAST")
*ENDWHEN
The above script copies the 2007 plan data to Forecast. You can also read property values and assign them to dimensions.
 Example
*XDIM_MEMBERSET P_ACCT = CE0004010,CE0652000
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=([P_ACCT].[CE0004010],[P_ACTIVITY].[NONE])/([P_ACCT].[CE0652000],[P_ACTIVITY].[
*ENDWHEN
Restrictions For Using the REC Instruction
You cannot use other MDX keywords (such as PARENT and DESCENDANTS) in FACTOR or EXPRESSION instructions. The only
permitted operations are addition (+), subtraction (-), multiplication (*), and division (/), combinations of these operators, and
parenthesis for tuple and priorities of the operations.
You cannot use the GET() function to refer to another source value. The MDX tuple format acts as a GET function.
You cannot use NOADD or FLD functions within REC.
Dynamic properties such as HLEVEL, PARENTHn are not supported in the REC statement.
REC always needs to be accompanied by WHEN / IS / ENDWHEN. Stand-alone REC statements do not have any effect.
You cannot use SIGNEDDATA or any measure name in a WHEN statement to write a condition on a measure value.
WHEN / IS / REC / ENDWHEN cannot be used in SELECTCASE / ENDSELECT.
Using Multiple REC Statements
You can write multiple REC statements within one WHEN/ IS/ ENDWHEN statement.
Syntax
*WHEN {dim}
* IS {condition_value}
*REC({FACTOR or EXPRESSION instruction},dim=…)
10/21/2020
*ENDWHEN
 Example
*XDIM_MEMBERSET TIME = 2006.AUG,2006.SEP
*XDIM_MEMBERSET P_ACCT=CE0004010
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/1.5098, RPTCURRENCY="EUR")
*REC(EXPRESSION=%VALUE%/1.0666, RPTCURRENCY="CAD")
*REC(EXPRESSION=%VALUE%/1.9183, RPTCURRENCY="GBP")
*ENDWHEN
The script shown above creates EUR, CAD, and GBP posts in the InfoProvider.
Referring To Another Source Value Within A FACTOR/EXPRESSION Instruction
You can assign a source value from the scoped data for a FACTOR or EXPRESSION instruction to calculate a new value inside a *REC( )
statement. To refer to another source value, you must use fully quali ed MDX formatting, including an Account dimension.
 Note
You have the ability to use implicit Account members in direct MDX statements within script logic.
Syntax
*WHEN {dim}
* IS {condition_value}
*ENDWHEN
 Example
Environment: EnvironmentShell_V (Copy of EnvironmentShell)
Application: Planning
*WHEN P_ACCT
*IS "CE0004010"
10/21/2020
*REC(EXPRESSION=%VALUE%/[P_ACCT].[CE0004020], P_ACCT="CE0661000")
*ENDWHEN
You can use tuples as well.
 Example
Environment: EnvironmentShell_V (Copy of EnvironmentShell)
Application: Planning
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/([P_ACCT].[CE0652000],[P_ACTIVITY].[LABPRD]), P_ACCT="CE0661000")
*ENDWHEN
LOOKUP
A function that refers to another source value
To calculate a new value inside a *REC( ) statement, you can use the LOOKUP function to assign a source value that is outside the
scoped data for a FACTOR or an EXPRESSION instruction.
Syntax
*LOOKUP {Model}
*DIM [{LookupID}:]{DimensionName}="Value" | {CallingDimensionName}[.{Property}]
*DIM MEASURES="MeasureName"
*ENDLOOKUP
 Example
In the following example, you are reading RATE information and using it in the calculation. You can also use FOR/NEXT to look up
multiple values.
Environment: EnvironmentShell_V (Copy of the EnvironmentShell sample environment)
Model: Planning
10/21/2020
*LOOKUP RATE
*DIM TIME="2006.AUG"
*DIM CATEGORY="ACTUAL"
*DIM R_ACCT="AVG"
*DIM R_ENTITY="GLOBAL"
*DIM RATEEUR:INPUTCURRENCY="EUR"
*DIM MEASURES="PERIODIC"
*ENDLOOKUP
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/LOOKUP(RATEEUR), RPTCURRENCY="EUR")
*ENDWHEN
 Example
In the following example, you are rst reading all reporting currencies in the *SELECT statement and assigning the values to variable
%CUR%. Using FOR/NEXT, you read their rates from RATE model. Then, you use them in the calculation.
Values in the models before the execution of the script:
PLANNING model data:
TIME P_ACCT ENTITY P_ACTIVITY CATEGORY Currency P_DATASRC SignData
2006.AUG CE0004010 C9000 NONE ACTUAL LC UPLOAD 157,915.81
Rate model data:
Category InputCurrency R_ACCT R_ENTITY TIME SignData
ACTUAL EUR AVG GLOBAL 2006.AUG 1.5022
ACTUAL USD AVG GLOBAL 2006.SEP 1.0000
*XDIM_MEMBERSET TIME=2006.AUG
*SELECT(%CUR%, "[ID]", RPTCURRENCY, "[REPORTING]=Y")
*LOOKUP RATE
*DIM R_ACCT="AVG"
10/21/2020
*DIM TIME="2006.AUG"
*FOR %LOOP_CUR%=%CUR%
*DIM C_%LOOP_CUR%:INPUTCURRENCY="%LOOP_CUR%"
*NEXT
*ENDLOOKUP
*WHEN P_ACCT
*IS "CE0004010"
*FOR %LOOP_CUR%=%CUR%
*REC(EXPRESSION=%VALUE%/LOOKUP(C_%LOOP_CUR%), RPTCURRENCY=%LOOP_CUR%)
*NEXT
*ENDWHEN
Values in the model after the execution of the script:
2006.AUG CE0004010 C9000 NONE ACTUAL EUR UPLOAD 105,123.03
2006.SEP CE0004010 C9000 NONE ACTUAL USD UPLOAD 157,915.81
You can also pass property values to scope members to look up data.
 Example
In this example, the corresponding Entity's currency is read from master data and this is used to look up the rate value.
*XDIM_MEMBERSET ENTITY=C9000
*LOOKUP RATE *DIM TIME="2006.AUG"
*DIM R_ACCT="AVG"
*DIM RATE:INPUTCURRENCY=ENTITY.CURRENCY
*ENDLOOKUP
*WHEN P_ACCT
10/21/2020
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/LOOKUP(RATE), RPTCURRENCY=ENTITY.CURRENCY)
*ENDWHEN
Restriction
Reading multiple measures within a single LOOKUP by assigning different lookup IDs is not supported.
*RUNALLOCATION
Allocation helps distribute data from a source region to a target region using the speci ed driver.
Syntax
*RUNALLOCATION
*FACTOR=<driver>
*DIM P_ACCT WHAT=<soure>; WHERE=<target>; USING=<distribution key>; [TOTAL=<distribution key>]
*DIM <other dimensions>
*ENDALLOCATION
WHAT (Source)
The source value represents the range of data values to be allocated by the allocation function. This value is quali ed by one or several
tuples in the model.
Possible WHAT options are:
Options Descriptions Example
Member A speci ed dimension base member. *DIM Region WHAT = US
[property]="property value" A lter to select dimension members based on a *DIM Product_Group = [Fruit] =
speci ed property and a given value for that "apples"
property.
BAS All leaf level members of a speci c dimension parent *DIM Product_Group = BAS(TotalProduct)
member
same as WHERE Use the same members de ned in the WHERE *DIM Account WHERE = Rent
parameter for the speci ed dimension
*DIM Account WHAT = Rent
<> member The <> operand references all members not equal to *DIM Region USING <> Corp
a de ned member.
In the <>member mode, the member should be base

member in the dimension.
If the <> is used, all other base members in that

dimension should be included in the region.
10/21/2020
Restriction of WHAT
You cannot use blank or [ALL] in WHAT condition.
You cannot use non-base members with <>.
USING and TOTAL (Distribution key)
The basis of the allocation is the de nition of a portion or complete source value to be allocated. The method of de ning the basis is the
use of a factor. A factor can be the value or values that can be multiplied or divided to derive a value (added or subtracted potential future
support).
A factor can also derive values based on a de ned region of data referred as using, or the basis region.
Possible USING and TOTAL options are:
Member A speci ed dimension base member. *DIM Region USING = US
member
same as WHERE Use the same members de ned in the WHERE *DIM Account WHERE = Rent
parameter for the speci ed dimension. The same
*DIM Account USING = PercentAcct
dimension must be for both WHERE and USING.
 Note
WHERE only supports a single member reference.
<> member The <> operand references all members not equal to *DIM Region USING <> Corp
a de ned member.
In the <>member mode, the member should be base

member in the dimension.
If the <> is used, all other base members in that

dimension should be included in the region.
property.
Restriction of USING
You cannot use >0. For example, USING = Amount >0 is not supported.
USING and TOTAL must have the same de nition.
You cannot use non-base members with <>.
You cannot use parent member directly in USING. BAS(parent) is still allowed as described above.
FACTOR (Driver)
FACTOR can be used to de ne any arithmetic expression, written in the {expression} parameter, and can contain operands, parentheses,
constants, and one or both of the keywords USING and TOTAL, representing respectively the amount coming from the USING region, the
amount of the driver, and the amount coming from the TOTAL region, the sum of the drivers.
If FACTOR is omitted, the FACTOR defaults to 1.
If the arithmetic expression is omitted, the default is multiplication.
Possible FACTOR options are:
10/21/2020
.8 Only a xed amount is to be applied to the source Tuple value of the WHAT is 10 for product A
value for allocation.
10*.8 = 8
USING The value of the USING region de ned is used as the Tuple value of the WHAT is 10 for product A, tuple
basis of the allocation. This provides the ability to value of the USING is .8
change values without having to edit the de nition of
the allocation. 10*.8 = 8
-1 * USING/100 Calculation takes the de ned region as USING, and Tuple value of the USING region is 70 for product A.
reverses the value (negative), then divides the value
Or -70/100 = -.7
by 100.
1 * USING/100 (-70%) (1-70)/100 = -.69 (-69%)
 Note
This is used with driver accounts not reporting
values.
USING/TOTAL Calculation takes the region de ned as USING, and Tuple value of USING region is 70 for product A. The
divides the total value for the region de ned as total of the TOTAL region (tuples) is 700, assuming
TOTAL. that the using region is for all regions not just US.
70/700 = .1 (10%)
Basic Mathematical expression with Calculation takes the region de ned as USING, and Tuple value of the USING region is 70 for product A.
USING & TOTAL does the necessary mathematical operations with
1+70 = 71
the total value for the region de ned as TOTAL.
(For example, 1 + USING, USING -1 ,
and 1 - USING) 70 -1 = 69
1-70 = -69
Restriction of FACTOR
You cannot use any script logic keywords in FACTOR expression.
WHERE (Target)
The target identi es the tuples to which the values should be allocated. It represents dimension member combinations to which the values
should be distributed. The target identi es the dimension for which the value of the members is modi ed as compared to the source, and
only explicitly mentioned and characterized dimension should be modi ed.
The keyword WHERE is used in combination with the keyword *DIM to identify the target dimension members (the values to be modi ed
against the source).
Possible WHERE options are:
Member A speci ed dimension base member. *DIM Region WHERE = US
member
same as WHAT Use the same members de ned in the WHAT *DIM Account WHAT = Rent
parameter for the speci ed dimension
*DIM Account WHERE = Rent
blank or [All] The ability to assume all base members for given *DIM Entity =
dimensions either via a blank parameter or [ALL] key
*DIM IntCo = [ALL]
word
10/21/2020
property.
Common Restriction
*APP (ability to write in different model if needed), COUNT and LIST keywords inside RUNALLOCATION or any other options not
mentioned above are not supported.
Examples
Example 1
The account RENT is entered in entity GLOBALOPS, inter-company NON_INTERCO. This amount must be allocated using a percentage of
allocation that is entered by the user in account PERCENT in the appropriate entities and for the desired members of the CATEGORY,
TIME, DATASRC, and RPTCURRENCY dimensions.
This allocation demonstrates the following features:
It uses the {dimensiontype}DIM keyword to identify the dimensions by type
It uses the <<< and >>> keywords to reference the de nitions used to the left or to the right
Before Allocation
Source Account ( RENT) data:
RENT CHINA China
RENT JAPAN Japan
RENT INDIA India
RENT ASAREST Rest of Asia
RENT ASA Asia 50,000,000.00
Driver (Percent Account) data:
PERCENT CHINA China 10.00
PERCENT JAPAN Japan 32.00
PERCENT INDIA India 8.00
PERCENT ASAREST Rest of Asia 50.00
*XDIM_MEMBERSET TIME=2006.SEP
*XDIM_MEMBERSET P_ACCT=RENT,PERCENT
*XDIM_MEMBERSET ENTITY=ASA,INDIA,CHINA,JAPAN,ASAREST
*RUNALLOCATION
*FACTOR=USING/100
*DIM P_ACCT WHAT=RENT; WHERE=<<<; USING=PERCENT
*DIM ENTITY WHAT=ASA; WHERE=INDIA,CHINA,JAPAN,ASAREST; USING=<<<
*ENDALLOCATION
After Allocation
RENT CHINA China 5,000,000.00
10/21/2020
RENT JAPAN Japan 16,000,000.00
RENT INDIA India 4,000,000.00
RENT ASAREST Rest of Asia 25,000,000.00
RENT ASA Asia 50,000,000.00
Example 2
The account RENT is entered in entity GLOBALOPS, inter-company NON_INTERCO. This amount must be allocated on the basis of the
square meters of rented space used by all European entities.
Allocation uses historical rent as the driver
It uses the BAS( ) keyword to build a list of members
Before Allocation
Below is the history data shown for the 2008.JAN period. Asia is the parent node.
Entity CATEGORY 2008.JAN
Asia all ACTUAL
Asia ACTUAL
China ACTUAL 1,500.00
Japan ACTUAL 7,000.00
India ACTUAL 500.00
Rest of Asia ACTUAL 5,000.00
Planning Asia ACTUAL
Source Account ( RENT) data:
To allocate 50,000 to base countries
This input can be received in the Planning Asia entity
Driver data:
The historical data is the Driver
*XDIM_MEMBERSET TIME=2008.JAN,2009.JAN
*XDIM_MEMBERSET P_ACCT=RENT
*XDIM_MEMBERSET CATEGORY=ACTUAL,PLAN
*XDIM_MEMBERSET ENTITY=ASA,BAS(RASA)
//Create total rent data to be allocated.

*WHEN ENTITY
*IS "ASA"
*REC (EXPRESSION=50000,TIME=2009.JAN,CATEGORY=PLAN)
*ENDWHEN
*COMMIT
//Allocate to base countries.

*RUNALLOCATION
*FACTOR=USING/TOTAL
*DIM P_ACCT WHAT=RENT; WHERE=<<<; USING=<<<; TOTAL=<<<
10/21/2020
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<< TOTAL=<<<
*DIM TIME WHAT=>>>; WHERE=2009.JAN; USING=2008.JAN; TOTAL=<<<
*DIM CATEGORY WHAT=>>>; WHERE=PLAN; USING=ACTUAL; TOTAL=<<<
*ENDALLOCATION
//Clear the total rent account.

*WHEN ENTITY
*IS "ASA"
*REC (EXPRESSION=0,TIME=2009.JAN,CATEGORY=PLAN)
*ENDWHEN
After Allocation
Entity CATEGORY 2009.JAN
Asia all PLAN 50,000.00
Asia PLAN 50,000.00
China PLAN 7,500.00
Japan PLAN 35,000.00
India PLAN 2,500.00
Rest of Asia PLAN 5,000.00
Planning Asia PLAN
2009.JAN is posted with rents for individual countries based upon their historical share.
Example 3
The sum of all ADVERTISING expenses incurred by all European operations must be reallocated to each European operation based on
their external SALES.
It uses the DOT({type}) keyword to identify the dimensions by type
It demonstrates the ability to perform aggregations in the WHAT region ( SALESEUROPE and ALL_INTCO are parent members)
It shows a many-to-one redirection of a dimension (it reads the sum of the Inter-company members and writes it in the
NON_INTERCO member of the INTCO dimension)
It shows a one-to-one redirection of a dimension (it reads the INPUT member and writes the results in the ALLOCATED member of
the DATASRC dimension)
Before Allocation
Source data - History data for External Sales:
Actual - Periodic 2008.JAN
Planning Asia
China 500,000
Japan 600,000
India 200,000
Rest of Asia 800,000
Asia 2,100,000
10/21/2020
Asia all 2,100,000
Data to be allocated ( ADVERTISING):
Plan - Periodic 2009.JAN
Planning Asia 500,000
China
Japan
India
Rest of Asia
Asia
Asia all 500,000
Factor: USING/TOTAL
APP or (Dim) or VALUE WHAT WHERE USING TOTAL
DOT(A) ADVERTISING <<< EXTSALES <<<
DOT(E) SALESEUROPE BAS(SALESEUROPE) <<< <<<
DOT(I) ALL_INTERCO NON_INTERCO >>> BAS(ALL_INTERCO)
DATASRC INPUT ALLOCATED INPUT <<<
*RUNALLOCATION
*FACTOR =USING/TOTAL
*DIM P_ACCT WHAT=ADVERTISING; WHERE=<<<; USING=EXTSALES; TOTAL=<<<
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<<; TOTAL=<<<
*DIM INTERCO WHAT=WORLD_INTERCO; WHERE=I_NONE; USING=>>>; TOTAL=BAS(World_
*DIM P_DATASRC WHAT=MANUAL; WHERE=ALLOCATED; USING=MANUAL; TOTAL=<<<
*DIM TIME WHAT=2009.JAN; WHERE=2009.JAN; USING=2008.JAN; TOTAL=<<<
*ENDALLOCATION
After Allocation
Planning Asia
China 119,048
Japan 142,857
India 47,619
Asia 500,000
Asia all 500,000
Example 4
10/21/2020
This example implements the same scenario as example 3, but using a system variable for year. (%YEAR%). This returns current calendar
year. Assume that the script is for year 2009.
Before Allocation
Source data - History data for External Sales:
Planning Asia
China 500,000
Japan 600,000
India 200,000
Asia 2,100,000
Asia all 2,100,000
Data to be allocated ( ADVERTISING):
Planning Asia 500,000
China
Japan
India
Rest of Asia
Asia
Asia all 500,000
Factor: USING/TOTAL
APP or (Dim) or VALUE WHAT WHERE USING TOTAL
DOT(A) ADVERTISING <<< EXTSALES <<<
DOT(E) SALESEUROPE BAS(SALESEUROPE) <<< <<<
DOT(I) ALL_INTERCO NON_INTERCO >>> BAS(ALL_INTERCO)
DATASRC INPUT ALLOCATED INPUT <<<
*RUNALLOCATION
*FACTOR =USING/TOTAL
*DIM P_ACCT WHAT=ADVERTISING; WHERE=<<<; USING=EXTSALES; TOTAL=<<<
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<<; TOTAL=<<<
*DIM INTERCO WHAT=WORLD_INTERCO; WHERE=I_NONE; USING=>>>; TOTAL=BAS(World_
*DIM P_DATASRC WHAT=MANUAL; WHERE=ALLOCATED; USING=MANUAL; TOTAL=<<<
*DIM TIME WHAT=%YEAR%.JAN; WHERE=%YEAR%.JAN; USING=%YEAR%(-1).JAN; TOTAL=<
*ENDALLOCATION
After Allocation
10/21/2020
Planning Asia
China 119,048
Japan 142,857
India 47,619
Asia 500,000
Asia all 500,000
Example 5
All accounts in the pro t and loss of category ACTUAL, for the three entities ITALY, FRANCE and UK, are copied into the corresponding
accounts of the entity GLOBALOPS for category BUDGET. This allocation is basically an example of a simple copy action, which does not
use FACTOR at all. In this example the engine performs a one-to-one copy ( ACTUAL into BUDGET) and a many-to-one copy ( ITALY,
FRANCE and UK are added up and copied into GLOBALOPS).
Before Allocation
Actual - Periodic 2007.DEC
UK (Great Britain) 30,000
Italy 10,000
France 10,000
Budget - Periodic 2008.FEB
Global Operations
Factor:
APP or (Dim) or VALUE WHAT WHERE
ACCOUNT [GROUP] = "profit & loss" <<<
CATEGORY ACTUAL BUDGET
ENTITY SALESITALY; SALESFRANCE; SALESUK GLOBALOPS
DOT(R) LC <<<
A property not supported in ALLOCATION is replaced by a variable using a *SELECT statement. Ensure that the *SELECT statement
selects only base members.
*XDIM_MEMBERSET ACCOUNT=ADVERTISING,EXTSALES
*XDIM_MEMBERSET ENTITY=UK,ITALY,FRANCE,GLOBAL
*XDIM_MEMBERSET P_DATASRC = INPUT
*XDIM_MEMBERSET TIME = 2007.DEC,2008.JAN
*XDIM_MEMBERSET CATEGORY = ACTUAL,BUDGET
*XDIM_MEMBERSET INTCO= I_NONE
*XDIM_MEMBERSET RPTCURRENCY = LC
*SELECT(%ACCT%, "[ID]",ACCOUNT,"[CALC]='N'","[GROUP]='PL'")
*RUNALLOCATION
*FACTOR=
*DIM ACCOUNT WHAT=[GROUP]="PL" AND [CALC]="N"; WHERE=<<<
10/21/2020
*DIM CATEGORY WHAT=ACTUAL; WHERE=BUDGET
*DIM ENTITY WHAT=UK,ITALY,FRANCE; WHERE=GLOBAL
*DIM DOT(R) WHAT=LC; WHERE=<<<
*DIM TIME WHAT=2007.DEC; WHERE=2008.FEB
*ENDALLOCATION
After Allocation
Budget - Periodic 2008.FEB
Global Operations 50,000
*SELECT
The special instruction *SELECT allows you to retrieve a list of elements from a dimension and save it in a user-de ned variable for use
somewhere else in the logic.
*SELECT ({variable}, {[What]}, {From dimension}, {Where})
 Example
With the following instruction, the user can retrieve the ID of all members in the CURRENCY dimension where the property CURRENCY
TYPE has the value R.
*SELECT(%CURRSET%, "[ID]", RPTCURRENCY, "[REPORTING]='Y'")*XDIM_MEMBERSET RPTCURRENCY = %CURRSE
The *SELECT statement lls the variable %CURRSET% with the list of reporting currencies de ned in the current model. The content of
the resulting variable is then used in the XDIM_MEMBERSET statment.
The SELECT instruction is not speci c to a given logic section, but it can be written once anywhere in the logic and used across multiple
commit sections.
The SELECT statement is fairly limited, as it only supports the equal sign (=) , not equal to (<>) and cannot be used to combine multiple
lter criteria with AND or OR keywords.
To write formulas containing several nested IIF( ) statements, use the following syntax:
*SELECTCASE {expression}
*CASE {value1}[,{value2},…]
{formulas}
[*CASE {value1}[,{value2},…]
10/21/2020
{formulas}
[*CASEELSE]
{formulas}
*ENDSELECT
where
{expression} is the condition to be evaluated
{value1},.. is the range of comma-delimited results that satisfy the condition for the current case
With such a structure, the readability of a logic statement can be signi cantly improved.
 Example
*BEGIN
#A = IIF([ACCOUNT].[E]=1 OR [ACCOUNT].[E]=2,X+Y,
IIF([ACCOUNT].[E]=3 OR [ACCOUNT].[E]=4,X-Y,X*Y))
*END
#C = IIF([ACCOUNT].[E]=1 OR [ACCOUNT].[E]=2,W+Z,null)
#B = IIF([ACCOUNT].[E]=3 OR [ACCOUNT].[E]=4,W*Z,null)
The following formulas could be written as follows:
*SELECTCASE [ACCOUNT].[E]
*CASE 1,2
#A=X+Y
#C=W+Z
*CASE 3,4
#A=X-Y
#B=W*Z
*CASEELSE
#A=X*Y
*ENDSELECT
 Note
SELECTCASE structures currently CANNOT be nested.
10/21/2020
*SUB( ) / *ENDSUB
A SUB structure allows the user to de ne reusable logic sections anywhere in the body of the logic to make the logic easier to read and
maintain.
A *SUB( ) structure is declared like a multi-line *FUNCTION( ) structure with the following syntax:
*SUB {SubName}({Param1,[,{Param2}…])
{body text}
{body text}
{body text}
[…]
*ENDSUB
When a SUB is then used somewhere else in the logic, its body lines are inserted in the logic with all the values passed to its parameters
appropriately replaced.
A SUB behaves similarly to included les, to which any number of parameters can be passed. When the logic is validated, the subs are
inserted in the body of the logic as if they were included with an *INCLUDE instruction. However, to use a SUB structure, no special
keyword is required. A SUB is called by inserting a line with the name of the SUB, followed by the values assigned to its parameter enclosed
in brackets. The other important difference from included les is that a SUB does not need to be written in a le of its own, but can be
written in any part of the logic, more similarly to a FUNCTION.
 Example
Here the sub is de ned:
*SUB MYSUB(Param1,Param2,Param3,Param4)
[%ACCOUNT_DIM%].[#Param1]=[%ACCOUNT_DIM%].[Param2]+[%ACCOUNT_DIM%].[Param3]
[%ACCOUNT_DIM%].[#Param4]=[%ACCOUNT_DIM%].[#Param1]*[%ACCOUNT_DIM%].[Factor_Param4]
*ENDSUB
Here the sub is used:
MySub(A1,B1,C1,D1)
MySub(A2,B2,C2,D2)
MySub(A3,B3,C3,D3)
Similarly to a FUNCTION, a SUB is not position sensitive, and can be de ned anywhere in a logic, as well as, if so desired, stored in separate
library les that must then be merged with the logic using an INCLUDE instruction.
A SUB can be used in any commit section of the logic without the need to be rede ned in each section. However, if a SUB is rede ned in a
logic le, its new de nition applies to all lines following the rede nition.
A SUB without parameters is supported, but they must always be followed by brackets.
10/21/2020
*WHEN / *ENDWHEN
A WHEN / ENDWHEN structure works in the same way as the SELECTCASE / ENDSELECT structure, with *REC( ) statements that
generate new records.
The syntax is the following:
*WHEN {criteria}
*IS [=]{value1}[,{value2},…] | <>{value}
*REC(FACTOR={Real number}|EXPRESSION={Expression}[,{dim1}={member},{dim2}=…])
[ *REC(FACTOR={Real number}|EXPRESSION={Expression}[,{dim1}={member},{dim2}=…])]
[*ELSE]
*ENDWHEN
where
{criteria} is what to test. Typically, this is a property of the current member of a dimension. The syntax is
DimensionName.Property | DimensionName, such as *WHEN ACCOUNT.RATETYPE. If Property is not speci ed, the ID
property is assumed. For example, *WHEN ACCOUNT equals to *WHEN ACCOUNT.ID.
{ValidCondition} is one or more values that meet the criteria. You can enclose them in double quotes to treat them as strings. Omit
the quotes if they represent numeric values. For example:
*IS "AVG","END"
*IS 10,20,30
If no operator is speci ed, the *IS clause assumes the presence of an equal sign (*IS = "AVG", "END").
The {value} must be literals only, not variables. Therefore, the following sample is not supported:
*IS dimension.property
 Note
There should be no space between the two characters of the unequal sign operator (<>). You can insert one or more blanks between the
operators and the value.
If an unequal sign (<>) is used, you can pass only one value. Therefore, the syntax *IS <> 2,3,4 is invalid.
Other relational operators like AND, OR and NOT are not currently supported.
Nesting of WHEN / ENDWHEN
WHEN / ENDWHEN structures can be nested by as many levels as desired and in any sequence, as shown in the following sample:
*WHEN xxx
10/21/2020
*IS "A"
*REC(…)
*REC(…)
*IS "B"
*REC(…)
*WHEN yyy
*IS "C","D","E"
*REC(…)
*ELSE
*REC(…)
*ENDWHEN
*ENDWHEN
Related Information
*REC
*XDIM_MEMBERSET
*XDIM_MEMBERSET de nes the scope of the data in which subsequent business logic will be applied.
Syntax
*XDIM_MEMBERSET {Dimension name} = {Members Set}
* XDIM_MEMBERSET {Dimension}<>{MemberSet}
 Example
*XDIM_MEMBERSET TIME = 2006.DEC
*XDIM_MEMBERSET P_ACCT = bas(CE0004000)
[TIME].[#2009.DEC] = [TIME].[2006.DEC] * 1.1
*COMMIT
This example rst reads all children of CE0004000 in the 2006.DEC period, increases them by 10%, and then copies them to the
2009.DEC period.
Other valid use cases:
10/21/2020
*XDIM_MEMBERSET P_ACCT = CE0004010, CE0004020, CE0004030
*XDIM_MEMBERSET P_ACCT = CE0004000, where all children values are summarized to one parent record.
*XDIM_MEMBERSET P_ACCT = BAS(CE0004010, CE0004210) The scope is de ned by the base members of both
CE0004010 and CE0004210. The string inside the parentheses () can also be replaced by a variable de ned in the Data Manager
prompt.
*XDIM_MEMBERSET P_ACCT = DEP(CE0004010) All direct children of CE0004010.
*XDIM_MEMBERSET P_ACCT = ALL(CE0004010) All children of CE0004010.
*XDIM_MEMBERSET P_ACCT <> CE0004010
You cannot combine bas() with any other member set.
*XDIM_MEMBERSET P_ACCT = bas(CE0004000), CE0004210 This is not a valid use case.
Use *XDIM_ADDMEMBERSET to add more members to the scope of the member set de ned by bas().
Forcing a dimension to read all members without member formulas
Using the <ALL> keyword, you can force a dimension to read all base members without member formulas.
Example
*XDIM_MEMBERSET P_ACCT = <ALL>
*XDIM_MEMBERSET TIME = 2006.DEC
[P_ACCT].[#CE0661000] = [P_ACCT].[CE0004000] / [P_ACCT].[CE0652000]
*XDIM_ADDMEMBERSET
With the keyword XDIM_ADDMEMBERSET, the logic can merge a speci c set of members with the members passed in the region for which
the logic should be executed.
This instruction is similar to the instruction *XDIM_MEMBERSET. The difference is that, while XDIM_MEMBERSET rede nes the region
passed by the user, XDIM_ADDMEMBERSET adds the de ned set to the passed region.
*XDIM_ADDMEMBERSET {dimension} = {members set}
 Example
*XDIM_MEMBERSET P_ACCT = bas(CE0004000)
*XDIM_ADDMEMBERSET P_ACCT = CE0004210
[TIME].[#2009.DEC] = [TIME].[2006.DEC] * 1.1
*COMMIT
In the above example, CE0004210 is scoped along with all children of CE0004000.
10/21/2020
*XDIM_MAXMEMBERS
When the number of records being processed is too large, performance can deteriorate signi cantly. Also, processing too much data in the
memory will slow down the system for other uses and eventually run out of memory. For example, an TSV_TNEW_PAGE_ALLOC_FAILED
ABAP dump can occur even with high Roll memory settings. In this case, you can break the action into multiple packets and execute them
sequentially using the following syntax:
*XDIM_MAXMEMBERS {dimension} = {max number of members}
 Example
*XDIM_MEMBERSET TIME = 2009.JAN
*XDIM_MEMBERSET CATEGORY = FCST_LOAD
*XDIM_MAXMEMBERS P_ACCT = 5
*RUNALLOCATION
*FACTOR=1/12
*DIM TIME WHAT = 2009.JAN; WHERE = BAS(2009.TOTAL);
*DIM CATEGORY WHAT = FCST_LOAD; WHERE = FORECAST;
*ENDALLOCATION
Assuming the whole year's forecast initially loaded 2009.JAN and FCST_LOAD, the above script allocates the data equally to each
period in 2009. The script logic engine reads the data in packages split by P_ACCT members, with each package containing a maximum
of ve P_ACCT members, until it reaches the end in P_ACCT dimension members.
*XDIM_PACKAGEBY
De nes the dimension for which to partition packages during script logic execution. Packages start in parallel mode for better
performance.
You can specify the server group using a parameter in IMG. Run transaction SPRO, then choose Business Planning and
Consolidation Global setting PARALLEL_SERVER_GROUP .
*XDIM_PACKAGEBY {Dimension name} [ = {Package number} ]
Package number is an optional parameter having a default value of 2.
 Example
*XDIM_PACKAGEBY ENTITY
10/21/2020
In the example above, two packages are created and partitioned by the dimension ENTITY.
 Example
*XDIM_PACKAGEBY ACCOUNT = 4
Four packages are created are partitioned by the dimension ACCOUNT.
 Note
You can use the *XDIM_PACKAGEBY keyword only once in each script.
Parallel mode is triggered ONLY when the member number for the dimension that is de ned with *XDIM_PACKAGEBY is greater
than 1.
The following keywords do not support PACKAGEBY: *RUN_PROGRAM, *RUNALLOCATION, *CALL_CUSTOM_LOGIC, and
*START_BADI.
*XDIM_FILTER
XDIM_FILTER brings all members when the speci ed condition is met. This keyword returns only base members.
 Example
*XDIM_MEMBERSET Category = PLAN
*XDIM_MEMBERSET Entity = C3000
*XDIM_MEMBERSET P_DataSrc = MANUAL
*XDIM_MEMBERSET RptCurrency = LC
*XDIM_MEMBERSET P_Activity = EMPL1
*XDIM_MEMBERSET P_ACCT = CE0004220
*XDIM_FILTER Time = [Time].properties("MONTHNUM") = "2"
*WHEN P_ACCT
*IS CE0004220
*REC (EXPRESSION = 888)
*ENDWHEN
*COMMIT
The code in this example writes only FEB records for CE0004220.
*COMMIT
10/21/2020
A logic le can contain formulas that depend on the result of calculations performed by the model, and these calculations in turn depend
on the results of other formulas in the same logic.
 Example
[P_ACCT].[#CE0004030] = ( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] ) * 0.15
[P_ACCT].[#CE0661000] =
( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[#CE0004030] ) / [P_ACCT].[CE0652000]
In this example, CE0661000 depends on the rst calculation, and this calculation in turn depends on the calculation of CE0004030.
The logic, if written in the above format, does not work correctly, because CE0004030 cannot be retrieved from the model until its result
has been posted to the model. To get the right results, CE0004030 must be calculated AND stored in the model. THEN, the calculated
result can be retrieved from the model and be used to calculate CE0661000.
To force a write back of the result of the calculation of CE0004030 into the model before the calculation of CE0661000, you can insert the
instruction *COMMIT between the two calculations. The logic then works when written as follows:
 Example
[P_ACCT].[#CE0004030] = ( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] ) * 0.15
*COMMIT
[P_ACCT].[#CE0661000] =
( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[CE0004030] ) / [P_ACCT].[CE0652000]
In this case CE0004030 in the second formula does not have the pound sign (#), because it is a stored amount read from the model.
 Note
Any number of commit instructions can be entered in a logic le. However, the number of commit instructions should be kept to the
minimum, because they have a negative impact on the overall performance of the logic execution due to increased communication
between the database and script logic engine. The ideal case is to have one commit at the end.
Special Keywords
The following are special keywords.
SET
An implied keyword is available for each dimension, which holds the set of members passed to the logic engine for a given dimension. This
keyword can be used as a replacement string anywhere in the logic.
%{DimName}_SET%
{DimName} is the name of a valid dimension in the model. For example the keyword %INTCO_SET% contains the set of members passed
to the logic for the dimension INTCO.
This keyword can be used anywhere in the logic and not just within some speci c statement like XDIM_MEMBERSET.
10/21/2020
This keyword is not modi ed by the XDIM_MEMBERSET instruction, as it always returns the original set passed to the logic.
This keyword does not return a default set if no set is passed. Its default is an empty set.
DIM
Another type of implied keywords is available for each non-user-de ned dimension. This keyword holds the actual name of a dimension of
a given type, and can be used as a replacement string to use anywhere in the logic.
%{DimType}_DIM%
{DimType} is the type of dimension.
 Example
If, in a model, the category dimension is called SCENARIO, the keyword %CATEGORY_DIM% returns the word SCENARIO.
Valid types are:
ACCOUNT
CATEGORY
TIME
ENTITY
INTCO
CURRENCY
DATASRC
Using Data Manager Prompts
In most of the script executions, you need to get user selection and use that value inside the logic script. For this purpose, you can use Data
Manager prompts inside the logic.
Syntax
$DM_PROMPT$...
 Example
*XDIM_MEMBERSET P_ACCT= CE0004020, CE0004010
*XDIM_MEMBERSET CATEGORY = ACTUAL
*XDIM_MEMBERSET TIME=2006.SEP
*XDIM_MEMBERSET ENTITY= C9000
*XDIM_MEMBERSET P_ACTIVITY=NONE
*XDIM_MEMBERSET P_DATASRC=UPLOAD
// Increase Wage and Salary, and Personnel Expense by entered percentage
[P_ACCT].[#CE0004020] = [P_ACCT].[CE0004020] * ( 1 + $WS_PERCT$ / 100)

[P_ACCT].[#CE0004010] = [P_ACCT].[CE0004010] * ( 1 + $EXP_PERCT$ / 100)
10/21/2020
The percentage to be increased for the above two accounts is provided by the user.
 Note
Additional con guration is required in the Data Manager to pass these parameters to script logic. In transaction RSPC in the ABAP layer,
the corresponding process chain's BPC:Run Logic step, Process Variant, needs to be maintained with additional parameters like TAB,
SUSER, and REPLACEPARAM.
Then, the dynamic script of Data Manager needs to be adjusted to accept the prompts.
PROMPT(SELECTINPUT,,,,"%ENTITY_DIM%,%CATEGORY_DIM%,%CURRENCY_DIM%,%TIME_DIM%")
PROMPT(TEXT,%WS_PERCT%,"Input W/S Percent in decimals",)
PROMPT(TEXT,%EXP_PERCT%,"Input Exp. Percent in decimals",)
INFO(%EQU%,=)
INFO(%TAB%,;)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,TAB,%TAB%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,EQU,%EQU%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SUSER,%USER%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SAPPSET,%APPSET%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SAPP,%APP%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SELECTION,%SELECTION%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,LOGICFILENAME,TESTING0123.LGF)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,REPLACEPARAM,WS_PERCT%EQU%%WS_PERCT%%TAB%EXP_PERCT%EQU%%EXP_PERCT%)
 Note
Read the restriction around Validation when DM prompts are used in your script in OSS note 1334695.
Script Logic System Variables
%USER% - Returns the current Business Planning and Consolidation user
%APPSET% - Returns the current Business Planning and Consolidation environment
%APPLICATION% - Returns the current Business Planning and Consolidation model
%YEAR% - Returns the current calendar year
You can use %YEAR% to derive the member values. For example, %YEAR%.TOTAL, and %YEAR%.Q1. You can also use to offset years like
%YEAR%(-2).TOTAL.
10/21/2020
TMVL Parameter
This optional parameter returns a time value after taking into consideration an offset value from a given time period.
Prerequisites
This function works only with base member values.
Activities
The format for this parameter is TMVL(offset, base_period). Utilize this parameter following these guidelines:
Offset can be either negative or positive. Only integers are allowed.
The base period can be a hardcoded value such as 2009.MAY, a Time script variable such as %TIME_SET%, or a Data Manager
Prompt variable such as $CURPER$.
 Note
Nested TMVL parameters such as TMVL(-1, TMVL(-3, 2009.JAN)) ) are not supported.
You can use TMVL in:
FACTOR/EXPRESSION within REC
FOR/NEXT loops
IS conditions inside WHEN/ENDWHEN.
variables, like %TIME_SET%
The rst period of the TIME_SET is used as the base period for a negative offset and the last period of the TIME_SET is used as
the base period for a positive offset.
scope statements
Multiple separate (not nested) TMVLs can be used in one scope statement.
When 0 is used as offset, no offset will be done for the provided time member.
 Example
In this example, Actual data records are copied over to the same period in the following year with a 10 percent increase. The existing
data is shown in the following table:
Category Entity P_ACCT P_Activity P_DataSrc RptCurrency Time SignData
ACTUAL C9000 CE0004010 NONE UPLOAD LC 2006.APR 100,891.26
The script used is the following:
*XDIM_MEMBERSET P_ACCT= CE0004010, CE0004020, CE0004210
*XDIM_MEMBERSET CATEGORY = ACTUAL
*XDIM_MEMBERSET ENTITY= C9000
10/21/2020
*XDIM_MEMBERSET P_ACTIVITY=NONE
*XDIM_MEMBERSET P_DATASRC=UPLOAD
*XDIM_MEMBERSET TIME = 2006.APR
*WHEN CATEGORY
*IS ACTUAL
*REC(FACTOR=1.1, TIME=TMVL(12,2006.APR))
*ENDWHEN
The data that results from running the logic script is shown in the following table:
Category Entity P_ACCT P_Activity P_DataSrc RptCurrency Time SignData
US Eliminations as Script Logic

You use this to control where the results of eliminations are stored in an Entity dimension.
Activities
The intercompany eliminations process is handled by a program called US_ELIM. This program is launched using the following logic
statement:
*RUN_PROGRAM US_ELIM( <parameters list>)
Example
*RUN_PROGRAM US_ELIM
CATEGORY = %C_CATEGORY_SET%
GROUP = %GROUPS_SET%
TID_RA = %TIME_SET%
OTHER = [ENTITY=%ENTITY_SET%]
*ENDRUN_PROGRAM
10/21/2020
Related Information
US Eliminations Rule
Carry-Forward as Script Logic

You use this program to initialize a new reporting period with the closing balances of the last period from the previous year into the opening
balances of the current period.
Activities
The copy-opening process is handled by a class called CL_UJP_COPYOPENING. This program is launched using the following logic
statement:
*RUN_PROGRAM COPYOPENING( <parameters list>)
Example
*RUN_PROGRAM COPYOPENING
CURRENCY = %GROUPS_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
Related Information
Carry-Forward Rule
Intercompany Booking as Script Logic

You use this to run Intercompany booking as well as difference posting.
Activities
Intercompany reconciliations processes are handled by a program called ICBOOKING.
Running the following in an ICDATA.LGF logic le runs Intercompany reconciliation:
*RUN_PROGRAM ICBOOKING ( <parameters list>)
 Example
*RUN_PROGRAM ICBOOKING
10/21/2020
CATEGORY = %CATEGORY_SET%
CURRENCY = %GROUPS_SET%
DATASRC = INPUT// value of datasrc dimension member that represents the input datasrc
TID_RA = %TIME_SET%
ENTITY = %ENTITY_SET%
ACCOUNT = %ACCOUNT_SET%
FLOW = %FLOW_SET%
TYPE = I
*ENDRUN_PROGRAM
Running the following in an ICBOOKING.LGF logic le runs Intercompany reconciliation and difference posting:
*RUN_PROGRAM ICBOOKING ( <parameters list>)
 Example
*RUN_PROGRAM ICBOOKING
GROUP = %CATEGORY_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
Related Information
Intercompany Booking Rule
Eliminations and Adjustments Rule for Legal Consolidation
Currency Conversion as Script Logic

You use this to run a new logic le currency conversion. Currency conversion typically runs by default when default logic runs.
Activities
Currency conversion is handled by a program called CURR_CONVERSION. This program is launched using the following logic statement:
*RUN_PROGRAM CURR_CONVERSION( <parameters list>)
You must also set up the following list of attributes for relevant dimensions in addition to the required attributes:
10/21/2020
Dimension Attribute
ACCOUNT RATETYPE
DATASRC DATASRC_TYPE (I, M, A, or L)
IS_CONVERTED (Y, G, or N)
ENTITY CURRENCY (local currency)
FLOW FLOW_TYPE (used to nd the closing ow)
CURRENCY CURRENCY_TYPE (currency type - Reporting, Local, or group)
TIMEID YEAR
PERIOD
TIMEID
MONTHNUM
INPUTCURRENCY (with Rate InfoProvider) MD (indicator of multiple or divide)
The Datasrc dimension is not mandatory for planning, and currency translation can be run without this dimension. If you choose to include
a Datasrc dimension in a planning InfoProvider, the attributes must be set up as they are checked in the currency conversion program.
In addition, the Flow dimension is not mandatory for planning, and currency translation can be run without this dimension. If you choose to
include a Flow dimension in a planning InfoProvider, the attribute needs to exist in the ow-type dimension to enable currency conversion.
Example
*RUN_PROGRAM CURR_CONVERSION
CATEGORY = %C_Category_SET%
GROUP = %GROUPS_SET%
TID_RA = %TIME_SET%
RATEENTITY = Global
*ENDRUN_PROGRAM
 Note
Global should be the valid member ID that is set in the RATEENTITY dimension.
The example shown above contains the line OTHER = [ENTITY=%ENTITY_SET%]. The Other lter supports the dimensions ENTITY,
DATASOURCE, and AUDIT. The OTHER lter does not support user-de ned dimensions.
Related Information
Currency Translation Rule
10/21/2020
Account-based Calculations as Script Logic

You use this to run an account-based calculation rule.
Activities
You run this program using the following logic statement:
*RUN_PROGRAM CALC_ACCOUNT( <parameters list>)
Example
*RUN_PROGRAM CALC_ACCOUNT
CURRENCY = %CURRENCY_SET%
TID_RA = %TIME_SET%
CALC=A
OTHER = [ENTITY=%ENTITY_SET%]// or OTHER=[ENTITY=C1000] or

[ENTITY=%ENTITY_SET%;INTCO=%INTCO_SET%...]
*ENDRUN_PROGRAM
 Note
If there is no other scope against which you need to run the program, delete the OTHER line in the script.
Related Information
Account-based Calculation Rule
Business Rules Management

Business rules are parameter-driven functions within SAP Business Planning and Consolidation models for calculating and posting
monetary amounts in support of common accounting activities, such as intercompany booking, currency translation, and eliminations and
adjustments.
To manage business rules in SAP Business Planning and Consolidation, select Planning and Consolidation
Administration Rules Business Rules .
Features
Adding Business Rules to Models
When you create or modify a model, you can add business rules to it. You can add the following types of business rules:
Account-based calculation
10/21/2020
Currency translation
Intercompany booking to match intercompany transactions
Carry-forward processing to initialize beginning balances when a new scal cycle starts
US eliminations
Eliminations and adjustments when generating consolidation entries for a group of entities, such as eliminations, adjustments,
reclassi cations, and minority calculations
After adding a business rule type to a model, you must customize it to meet your needs by specifying parameter values. For example, in
Eliminations and Adjustments, you can indicate which balances to read before calculating an amount, or under which account and audit
member to post the calculated amount. In addition to customizing default business rules, delivered with the IFRS starter kit for instance,
you can de ne new rules for various types of business processes and add them to a model.
Editing Business Rules
You can edit the list of available rules for a selected type of business rule within a model. You can then edit a speci c rule in the list. You can
use standard Microsoft Excel functionality to perform the following actions:
Select multiple detail record rows
Copy, paste, and delete detail records by row
Copy and paste within a cell by right-clicking and selecting a context menu option or using CTRL + C and CTRL + V
Copy rows
You can look up members within the cells of a rule by clicking the Lookup icon that appears when you place the cursor within that cell.
Validating Business Rules
You can verify the detail records of a business rule after modifying it by clicking Validate in the <Rule Name> page. A message appears
displaying a successful status or any errors encountered.
Activities
You can run a business rule as follows:
Perform a data send.
When you send data using SAP BusinessObjects Analysis, Edition for Microsoft Office, the system runs the default logic indicated in
default.lgf. For example, the default logic can execute the currency translation business rules. While you can add any logic or
business rule execution to the default script, it is not recommended, as performance may decrease when sending data.
Run a Data Manager package that contains a reference to a logic le (*.LGF).
Logic can be applied to a speci ed region of data that is stored in the database using any type of logic. You can create new logic les
or modify existing ones. For example, an Import package runs against the default logic unless the Import package is modi ed to
include other logic les. Each logic le contains one or more ABAP programs that run a speci c set of logic commands. Business
rules execution can be triggered in any logic le.
Post a journal entry.
Upon posting a journal, the system runs logic that is speci c to journal processes. To overwrite the default journal logic, you can
create a new script logic le called Journal.lgf. Business rules execution can be triggered in the journal logic le.
In SAP Business Planning and Consolidation, currency translation and consolidation processes can also be executed from the
Consolidation Monitor.
Related Information
10/21/2020
Carry-Forward Rule
Eliminations and Adjustments Rule for Legal Consolidation
Consolidation Monitor

Account-based calculations read and aggregate the values posted to speci c combinations of accounts, ow types, and audit members in
order to post the aggregated amount under an alternate destination account, ow and audit member combination.
Features
The following dimensions can be speci ed in order to de ne source and target members in the calculation:
Category (C-type dimension)
Account (A-type dimension)
Flow (S-type dimension)
Datasource (D-type dimension)
The account-based calculations business rule can invert the sign when posting calculated amounts when appropriate, which alternates
debit and credit amounts.
This rule can also use reference data in other periods and years to determine amounts to post.
This rule also supports year-to-date calculations in period-based models.
You can utilize account-based calculations in both nancial and legal consolidation models.
Example
You can use this business rule to calculate and post values that you need for cash ow reporting.
Related Information
Account-based Calculations as Script Logic

You use this to convert local currency values into one or more reporting or group currencies in accordance with major Generally Accepted
Accounting Principles.
Currency translation rules are executed as a separate task using a Data Manager package. They can also be executed from the
Consolidation Monitor in the Consolidation Central area.
Prerequisites
Currency translation applies to both nancial and legal consolidation models to which a corresponding rate model has been referenced.
When performing currency translation, different exchange rates such as average and period end rates, as well as formulas, are applied. A
currency translation rule contains the necessary rates and logic for a unique account rate type. The account rate type must exist in the
Account dimension in order to be triggered. However, you can create and name the currency translation rule rst, and then assign the
10/21/2020
RATE_TYPE in the account dimension to the accounts to which it relates. When currency translation runs, it translates each account in
accordance with the rules de ned for the account rate type which has been assigned to that particular account.
If you need to store data in the local currency of the entity and also convert it to one or more reporting or group currencies, a currency type
dimension must exist. In addition, the system must access a rate model that stores the exchange rates used for the automatic translation.
The following list provides a summary of the environment requirements to support currency translation:
The environment must include a rate model where exchange rates are stored. You must assign this rate model to any model that
utilizes it.
The model itself must include a currency type dimension and possibly a Group dimension.
The Currency (R type) dimension must include the properties:
REPORTING, whose values are Y or blank
CURRENCY_TYPE, whose values are R for Reporting Currencies, T for transaction currency, or L for local currency. The
value G for group currency is used only if the currency dimension is also used to manage groups. This value is only relevant
for models migrated from a previous version of SAP Business Planning and Consolidation.
For Consolidation type models, the Group (G) dimension must include the following properties:
GROUP_CURRENCY, whose values are valid currencies in the previously mentioned Currency dimension
CURRENCY_TYPE, whose values are G for group currency or N for Non-Group related data, meaning local data
The Entity (E type) dimension must include the property CURRENCY, whose values are valid Input_Currencies. Input
currencies are listed in the currency dimension of the Rate model.
The Account (A type) dimension must include the property RATETYPE, values of the RATETYPE property should be names of
corresponding currency translation rules.
The Time (T type) dimension must include the properties YEAR, PERIOD, TIMEID, and MONTHNUM.
The Audit dimension is not mandatory for currency translation, but if you include it, the dimension must include the following
properties:
DATASRC_TYPE, whose values include the following:
I - Input
M - Manual Adjustment
A - Eliminations and Adjustments
L - Audit level (use only for consolidation)
IS_CONVERTED, whose values include the following:
N - these members are ignored in the conversion
Y (or blank) - these members are converted from LC into the desired currency unless the members are agged as
requiring manual adjustment; these members have their currency conversions entered manually
G - these members are copied from the reporting currency of the group that is being translated into the currency
member corresponding to the given group
The Flow (S type) dimension is not mandatory for currency translation, but if you include it, the dimension must include the
property FLOW_TYPE.
The InputCurrency dimension within the applicable rate model must include the property MD, whose values are M for multiply rates
or D for divide rates.
The appropriate FXTRANS logic must be available.
The default translation reads all values in local currency where currency = LC, applies the correct exchange rate according to the applicable
rate model, and writes the results in the appropriate reporting currency (USD, EURO, and so on).
10/21/2020
Rate selection
For the selection of the correct rate, the following rules apply:
The source currency is derived from the property CURRENCY of the entity being translated.
The rate to be applied during translation, such as Endflow, Histrate, and so on, is derived from the property RATETYPE of the
account being translated.
The valid rates are those corresponding to an account of the rate model for which the value of the GROUP property is FX rate.
The system does not convert any accounts with a rate type that is not a part of the currency translation business rules and converts
all accounts with a blank rate type with a factor 1.
The default currency translation supplied with the product for multi-currency models performs a cross-rate translation; it multiplies the
amount in local currency by the ratio between the rate of the destination currency and the rate of the source currency. This allows the
model to use only one table of rates for translating any source currency into any destination currency.
Other types of translations can be de ned by using the currency translation business rules tables and the relevant properties in the
Currency and InputCurrency dimensions to support:
the ability to use different tables of rates by reporting (destination) currency
the ability to distinguish between Multiply currencies and Divide currencies
Conditions for Running Currency Translation
Currency translation can run in the following two modes:
Reporting currency mode
Reporting currency mode converts transaction data recorded in a local currency to the speci ed reporting currency. For this mode,
make sure the script is similar to the following:
CURRENCY = %RPTCURRENCY_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
......
*ENDRUN_PROGRAM
Pay attention to the keyword CURRENCY. If running currency translation for the reporting currency, the keyword on the left side
should be CURRENCY. If running currency translation for a group, use the keyword GROUP.
Group mode
Group mode converts subsidiaries' data to a group's currency. This is mainly used before consolidation.
Whatever mode the currency translation runs in, the following conditions must be satis ed:
The model must contain only one Currency (type R) dimension.
The model must contain only one Group (G type) dimension if the model is a Consolidation model.
For consolidation models migrated from previous versions of SAP Business Planning and Consolidation, this dimension is not
mandatory, in order to ensure compatibility with the current version.
The reporting model must reference the RATE model.
10/21/2020
Some dimensions, such as Account, Entity, and Currency, must contain appropriate properties as noted in the following table:
Model Dimension Property Description
Main Account RATETYPE The value of the RATETYPE

property must be the name of a
currency translation rule, such
as AVG, END, and ENDFLOW.
Main Entity CURRENCY The CURRENCY property

denotes the local currency for
the current entity. For example,
for entity US, the currency is
USD; for FRANCE, the currency
is EUR. The value of this
property must be a valid
member of the InputCurrency
dimension.
Main Currency CURRENCY_TYPE The CURRENCY_TYPE property

speci es the currency type, and
it should take the following
values:
L (local currency)
R (reporting currency)
G (group, for
compatibility on
migrated models only)
Main Group CURRENCY_TYPE The CURRENCY_TYPE property

speci es if the member is a
group/sub-group or is used to
enter local data:
G (Group)
N (Non-Group, used for

data input)
Main Time YEAR The YEAR property contains the

year information of the ID. For
example, if the ID is 2016.AUG,
YEAR is 2016.
Main Time PERIOD The PERIOD property denotes

the period to which the current
time belongs. For example, if the
ID is 2016.AUG, PERIOD is AUG.
Main Time PERIOD The TIMEID property is a

numerical value for the current
time. For example, for 2016.AUG,
the TIMEID is 20160800.
10/21/2020
Model Dimension Property Description
Main Time MONTHNUM The MONTHNUM is de ned to

identify the closing period of a
year. It's a number that stands
for the chronological sequence
of the base member in a Time
dimension hierarchy during the
same year. For example, for
2016.AUG, the MONTHNUM is 8.
The base member can be either

a month or a day, depending on
your co guration.
When optional dimensions such as Audit and Flow (S type dimension) do not exist, currency translation still runs successfully. However, if
they do exist, they impact the translation process. In this case, the following properties in these dimensions are mandatory:
Dimension Property Description
Audit DATASRC_TYPE The DATASRC_TYPE property signi es the

audit member type. The following four values
are available:
I (input)
M (manual adjustment)
L ( audit level, for consolidation only)
A (eliminations and adjustments)
Audit IS_CONVERTED When the IS_CONVERTED property is set to N

or blank, members are ignored in the
conversion. When set to Y, members are
converted from the local currency to the
desired currency.
Flow FLOW_TYPE The FLOW_TYPE property can take many

values, but the most important is the value
CLOSING. The rule of currency translation with
FORCE_CLOSING = Y makes use of it.
To run currency translation in reporting currency mode, the mandatory condition mentioned previously should be satis ed. If optional
dimensions such as Audit and Flow (S type dimension) exist, the condition of the optional dimension is also necessary.
To run currency translation in group mode, beside the same requirement as reporting currency mode, the following additional conditions
are mandatory:
The Ownership model must be set up and referenced.
In migrated consolidation models only, Group information must be maintained in a separate Group dimension (except for models
migrated from previous versions, where Groups can be maintained in a Currency dimension).
When using the Currency dimension, Currency and Group information resides in the same dimension. The following properties are
needed in Currency dimension:
The ENTITY property can be blank or a valid Entity ID. It is used to de ne the link between the group and the entity and to
indicate the entity where the aggregation should be stored. (Refer to the STORE_ENTITY property below.)
The GROUP_CURRENCY property can be used only on CURRENCY members with the property CURRENCY_TYPE= G. It
must contain a valid ID from the Currency dimension with the property CURRENCY_TYPE = R.
10/21/2020
The STAGE_ONLY property controls the way the converted values must be saved in case of a multilevel conversion of
groups. This property can have the three values Y, E, or N (blank).
The STORE_ENTITY property can have the values Y or blank. It indicates whether the system copies the results of the
currency translation for the current group into the entity speci ed in ENTITY property.
The STORE_GROUP_CURR property can have the values Y or blank. It indicates whether the system stores the currency
translation result in the group currency. Otherwise, the system stores the result only in gGoup, not in currency.
The PARENT_GROUP property de nes the group hierarchy. The value of this property should be a valid Group ID in the
dimension.
When currency and group reside in one dimension, make sure the script le is similar to the following before running currency
translation for the group:
GROUP= %GROUPS_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
......
*ENDRUN_PROGRAM
Pay attention to the keyword GROUP. If running currency translation in group mode, the keyword GROUP should be used instead of
CURRENCY.
In SAP Business Planning and Consolidation, when building a consolidation, both a group dimension and a currency dimension are
required. Therefore, consolidation group members and currency members are held separately.
A new dedicated dimension, for example, Group, should be type G.
When maintaining time properties, note that consolidation-related programs are allowed to run against base members in the same year
only. The four properties of 'TIMEID', 'YEAR', 'PERIOD' and 'MONTHNUM' of base members affect those programs.
Properties of parent nodes have no effect on those programs, and the value for these 4 properties should not be empty.
The value for 'TIMEID' should be unique for each base member.
The value for 'YEAR' should be a four digit number for each base member.
The value for 'PERIOD' should be unique for each base member in the same 'YEAR'. SAP suggests that 'JAN', 'FEB', and so on are
used for Month members and that 'week01' or 'W01' for are used for week members.
The value for 'MONTHNUM' should be unique for each base member in the same 'YEAR'. It should be a number that stands for the
chronological sequence during the same year.
Example for DAY members:
ID Period TIMEID MONTHNUM PARENTH1
2016.TOTAL TOTAL 365
2016.Q1 Q1 90 2016.TOTAL
2016.JAN JAN 031 2016.Q1
2016.08.01 DAY1 20160801 213 2016.AUG
2016.08.20 DAY20 20160820 232 2016.AUG
In addition, the following is an example of a time dimension for Jan 12th 2016:
10/21/2020
ID TIMEID Year Period MONTHNUM Base Period
2016.1.12 20160112 2016 D12 012 012
Related Information
Currency Conversion as Script Logic

The Intercompany Booking function supports the overall intercompany reconciliation process.
Prerequisites
The following are required to perform intercompany eliminations within a model:
Five additional data sources must be de ned for the Data Source dimension in the IC_ORIGIN attribute. These data source
members are used for IC data calculation, which is a preliminary step for intercompany bookings:
I – Source data source to be used in IC data
D1 – (user-de ned description)
D2 – (user-de ned description)
C1 – (user-de ned description)
C2 – (user-de ned description)
You must con gure the IC Booking business rule in order to set up the business rule table.
The Account dimension must de ne a dedicated hierarchy to include all accounts for intercompany booking.
This con guration not only allows intercompany details to be entered for any account, but supports automatic elimination by level for all
desired accounts.
 Note
Although not mandatory, intercompany reconciliation is normally performed in a separate Intercompany matching application apart
from the actual Consolidation application.
Features
Intercompany booking records the declarations and reported balances by other entities against a particular entity. This allows business
users within each reporting entity to run a report that matches all of its declarations and reported balances against the balances of the rest
of the entities, without having to assign to each owner read-access for other entities. Bookings that make the Intercompany declarations
match can be automatically generated, and details can be posted to the consolidation model.
You use the Intercompany Booking business rule table to de ne the posting rules the system uses to generate the entries to match the
intercompany balances and declarations.
The consolidation engine supports a mechanism to perform the matching of intercompany declarations among the entities of a group. This
mechanism is split into two independent procedures as follows:
ICDATA: This procedure can be used to copy the declarations of all entities versus a given entity by intercompany account. It
concentrates into each single entity the declarations of all other entities versus each entity. This mechanism allows the owners of
an entity to run a report matching all of its declarations to those declared against it, without the need to assign to each owner Read
permission into other entities.
10/21/2020
Intercompany Booking: This procedure can be used to automatically generate the bookings that make the intercompany
declarations match.
By de ning Seller, Buyer, or Greater in the business rule booking type, the system can automatically book the difference by assuming the
correct value is Seller, Buyer, or the one with the greater booking value.
By con guring the Maximum Booking amount, you can set up the maximum threshold for automatic booking. Any differences bigger than
this maximum value are kept for manual adjustment later.
Intercompany bookings are executed from the Consolidation Monitor in the Consolidation Central area.
Related Information
Intercompany Booking as Script Logic
Carry-Forward Rule
Carry-forward populates the opening balances for the current year with the closing balances of the last period of the prior year.
Features
Carry-forward rules enable you to generate the Opening Balance of any category based on the following properties:
Flow_Type in the Flow dimension: the value of this property should be OPENING on the relevant Opening ow and CLOSING in
the relevant Closing ow.
Category_for_ope, Opening_year, Opening_period in the Category dimension
Carry-Forward rules can be used to initialize a new reporting period with the closing balances of the last period from the previous
year into the opening balances of the current period. It can also copy closing balances from a designated year ( Opening_year
property) and period ( Opening_period property) to the current period. The designated year and period can be an absolute or
relative number. You can also specify a Category in which to store the closing data using the Category_for_ope property. For
example, you may need to create opening data in a Budget category using data from a Forecast category.
DataSrc_Type, Opening_Datasrc, Copyopening in the Audit dimension
Currently this procedure is limited to copying the opening balances as found in the Audit dimension members agged as I and M in
the DATASRC_TYPE property. The procedure copies only the input balances and their related manual adjustments. The balances
generated automatically by the consolidation procedure ( Audit members agged as A) are taken into account during the
consolidation process by the consolidation procedure itself.
The Copyopening property enables you to identify the members on which the carry-forward rule should be executed.
The Opening_Datasrc property enables you to post data on a speci c datasource when running the Carry-Forward rules.
Within a carry-forward rule, the eld Account speci es the Destination account. The property Same_period enables you to copy
the same period balances to the current period. The YTD property enables you to sum up the balances of YTD to the current period.
In a legal consolidation model, such ows are often identi ed as members of a dedicated dimension. In simpler models, however, it is also
possible to store them as additional accounts in the Account dimension.
Related Information
Carry-Forward as Script Logic
US eliminations functionality addresses the posting of Intercompany US eliminations in scenarios where a full legal consolidation model is
not required, such as within a standard nancial model.
10/21/2020
Prerequisites
The following are required to perform Intercompany eliminations within a model:
The model must include a dimension of type I, Intercompany.
The Intercompany dimension must include the property ENTITY, whose values are entity names.
The account dimension must include the property ELIMACC, whose values are account names.
The entity dimension must include the property ELIM, whose values are Y or blank.
The appropriate business rule table must be set up.
A Data Manager package executing the Intercompany logic must be available. This con guration not only allows Intercompany
details to be entered for any account, but it also supports an automatic elimination-by-level for all desired accounts.
Features
When reporting the nancial results of a group of entities, you may want to see the results for the group net all Intercompany activity within
the group. Therefore, the system identi es Intercompany activities and balances and posts entries so these activities and balances are fully
eliminated when looking at the overall results for the group.
US eliminations functionality addresses the posting of Intercompany eliminations in scenarios where a full legal consolidation model is not
required, such as within a standard nancial model. When utilizing a legal consolidation model, Intercompany eliminations are normally
handled as part of an eliminations and adjustments function.
However, in some cases you might want to leverage the same legal consolidation model to carry out activities for both US eliminations as
well as eliminiations and adjustments , which is generally called Matrix Consolidation. In this model, you can maintain different sets of
Entity and Interco dimensions respectively for US eliminations and elimination and adjustments. Then, if you enable the IMG
parameter ENABLE_MATRIX_US_ELIM and set its value to X for this model using Tcode SPRO, you can specify Entity and Interco
(Trading Partner) dimensions when setting the US Eliminination rule later.
Intercompany elimination entries should be re ected only in groups in which both the entity and the partner entity are part of the group. To
address this, US eliminations uses a concept known as posting at rst common parent.
Excepect in the case of matrix consolidation, US eliminations are generally used in nancial models as opposed to legal consolidation
models.
The US eliminations business rules de ne the audit members to eliminate. For each of these audit members you then de ne the
corresponding destination audit member under which the system should post the elimination postings.
The values entered in the following properties determine default elimination logic:
Dimension Property Length in Characters Content
Account ELIMACC 20 A valid account against which the

actual Intercompany account to be
eliminated should be offset
Entity ELIM 1 Y or blank
Intercompany ENTITY 20 The entity ID corresponding to this

Intercompany member
Currency REPORTING 1 Y or blank
The default elimination logic does the following:
Scans all base level non-elimination entities (entities having the property ELIM <> Y).
10/21/2020
In case the model has a currency dimension, restricts its action to all reporting currencies only (currencies having the property
REPORTING=Y). Data in local currency cannot be eliminated because it is in different currencies.
Eliminates all values of the accounts to be eliminated (accounts having property ELIMACC<>blank) into the desired plug account
(the account speci ed by the ELIMACC property itself).
The elimination is posted to the elimination entity immediately below the rst common parent. The common parent is derived as
follows:
For a particular record the system identi es the two entities for which a common parent must be found. The rst entity is the
current entity member and the second entity is the entity corresponding to the current Intercompany member. This entity is
obtained reading the content of the property ENTITY of the current Intercompany member.
The system searches in a selected entity hierarchy for the rst member that has both entities as descendants. This is the
common parent.
Then the system searches in the immediate descendants of the common parent for a valid elimination entity (an entity
having the property ELIM=Y). This is the entity where the results of the elimination are stored.
The default elimination logic does its searches in the rst organizational structure (hierarchy) of the entity dimension. This can be
modi ed to have the elimination performed in all hierarchies existing in the entity dimension. If no common parent is found, no
elimination occurs. If no elimination entity is found below the rst common parent, the next common parent is searched.
More Information
For the execution of the US Elimination rule, refer to:
US Eliminations as Script Logic
Execute Consolidation Task
Eliminations and Adjustments Rule for Legal

Consolidation
You use this type of business rule when performing a legal consolidation process to generate adjustments and postings that integrate
results from subsidiary reporting entities into consolidated nancial statements in accordance with Generally Accepted Accounting
Principles.
Eliminations and adjustments are executed as a separate task using a Data Manager package. They can also be executed from the
Consolidation Monitor in the Consolidation Central area.
Prerequisites
Before executing eliminations and adjustments, do the following:
Enter any ownership changes into the ownership InfoProvider, such as the acquisition of a new company, the sale or transfer of
shares, and divestitures.
Update consolidation methods and accounting methods as necessary.
Update percent ownership and percent control within the group.
 Note
Ownership calculations can be run to calculate the overall ownership within each group. Consolidation parameters assigned to each
entity within each group then need to be validated within the ownership InfoProvider.
You must have the following items in your environment before performing the eliminations and adjustments:
10/21/2020
Ownership Model
Stores the overall ownership and percentage control of each entity by group on a category and time dependent basis as well as the
corresponding method of consolidation to apply
Group dimension
Provides the ability to store consolidated results by the group to which they relate
Currency dimension
Provides the ability to store consolidated results in the currencies speci ed for each group
 Note
You can use a common dimension for both currency and group ONLY in models migrated from version 7.5. In this version of SAP
Business Planning and Consolidation, you must use two separate dimensions - one for group and one for currency.
Method-based multipliers
De ne the formulas to use in calculating the amounts to post
Eliminations and Adjustments rules
De ne the balances upon which eliminations and adjustments are made and the items such as accounts and ow to which
calculated amounts are posted
Features
The most important of the necessary adjustments for legal consolidation relate to the elimination of intercompany activity between the
various reporting units, and reclassi cations and supporting the model of the applicable rules for the accounting of long-term investments.
Eliminations and adjustments rules support the calculation and generation of these postings.
Eliminations and adjustments rules are applicable only to a legal consolidation model to which you attach a corresponding ownership
model.
When eliminations and adjustments rules are executed for a given group, the system performs the following:
Reads from the ownership model which entities make up the group, the applicable consolidation method, and the ownership and
consolidation percentages.
Determines for each elimination and adjustment de ned in the business rules the base amount upon which the elimination and
adjustment is to be calculated based on the source data.
Identi es for each elimination and adjustment the corresponding method-based multiplier from the business rules.
Based on the identi ed method-based multiplier and the method of consolidation assigned to a given entity, determines the
formulas to apply in calculating the amounts to post. Ownership and consolidation percentages can be applied in the calculations.
Posts the calculated amounts based upon the posting rules de ned in the Eliminations and Adjustments business rules tables.
The following information describes the elds of the General tab in the Business Rules interface of Eliminations and Adjustments:
Source Audit ID: Restricts the type of transaction data to which the rule applies. This can be a member of the audit dimension, or a
DIMLIST in the audit dimension. This eld can also be blank to represent all audit members with an audit type of I or M. (You can use
Adjustment Level to apply further restriction.)
Destination Audit ID: Indicates the kind of data the rule generates. This should be one base member with an audit type of A.
Group Type Filter: Restricts the rule to speci c group or scope members.
Entity Property Filter: Similar to Group Type Filter, this restricts the rule to speci c entity members.
Adjustment Type: De nes the rule type. Possible values are the following entries:
Blank: generic rule type
10/21/2020
N: for new entities in the group/scope; similar to a generic rule
P: for proportional entities
E: for equity entities
D: for entities that leave the group/scope in the middle of the year
L: for entities that leave the group/scope in the beginning of the year
I: for integration consolidation, which deals with the inconsistencies that occur when some consolidation rules are de ned
using periodic mode while the ownership hierarchy changes during the scal year. For more information, see Integration Rule
for Consolidation.
Adjustment Level: Indicates the execution sequence of all elimination rules. The system executes an elimination rule with an
adjustment level of 0 rst, then level 1, then 2, and so on. The result of an elimination rule with a lower adjustment level can be the
input of an elimination rule with a higher adjustment level. The source audit ID for an elimination rule with an adjustment level larger
than 0 has further restrictions.
Other Dimension Filter: A string in this eld indicates lters or special restrictions on other dimensions. For example, if you have a
user-de ned dimension called Product and you want to run an elimination for only one of its members called Pro1, you would enter
Product = Pro1.
Force Destination Member: When lled, indicates the value to which the system should force the elimination result. For example, if
you enter Product = ALL, then for the generated elimination result, the system populates the dimension Product to ALL, no
matter what the original value was.
Ownership Filter: Filters the ownership value. For example, to apply a rule to only those entities whose ownership percentage in a
group or scope is larger than 70%, you enter POWN > 0.7.
Related Information
Method-based Multipliers and Consolidation Methods
Method-based Multipliers and Consolidation

Methods
You can set up global business rules at the environment level. Once the headers, methods, and rules are de ned, they can be used in all
related business rule tables within an environment.
Features
You populate the following two global de nitions:
Consolidation methods
Global De nitions
You can add a new Global De nition in Planning and Consolidation Administration by:
Selecting the type of Global De nition (Method or Method-based Multiplier)
Entering the required elds
Saving or validating the Method or Method-based Multiplier
Once de ned, the rule can be used in any model in the environment.
10/21/2020
Consolidation methods
The Consolidation Method list describes the accounting methods available for consolidating each entity.
Field Name Description
Method code
The unique method code. The value must be an integer between 1 and 98
99 - a reserved value and means any method, consequently it cannot be

assigned to any entity
Method name The name of this method.
 Example
Leaving, Equity, Proportional, Global, Holding.
Method type The Entity method type.
Available types: New, Holding, Global, Proportionate, Equity, Leaving (During the
Year), Disposed at last year-end
Method-based Multipliers control how the amounts or the destination accounts should be calculated.
You de ne a name (ID), a description, and a type as noted in the following table. The consolidation method de ned in the Type eld limits
the use of the rule to the speci ed type of consolidation method.
The calculation of consolidated data is controlled by the multiplier being used, the consolidation method assigned to the current entity,
and its Intercompany partner, if applicable.
The following elds can be de ned:
ID The identi er of the rule.
 Example
RULE01
Description A description of the rule.
 Example
Equity, 100% Minority part, Dividends, Stock Holder Equities, Intercompany
elimination
Type The consolidation method using the method-based multiplier can be restricted to:
Proportional
Equity
Leaving
Disposed
New
or blank
Entity Method A valid entity method, as de ned in the Consolidation Methods list, or a list of entity
methods separated by commas to which the multiplier applies.
10/21/2020
IntCo Method A valid entity method, as de ned in the Consolidation Methods list, a list of entity
methods separated by commas, or 99 for all methods. For the Intercompany
dimension, this is the entity value to which the multiplier applies.
ALL Formula An expression that represents the percentage (or formula) to apply to the Destination
All account property from the Eliminations and Adjustments business rule.
The value can be an arithmetic expression combining any de ned percentage in the
account dimension of the ownership model. All percentages where the property
IS_INPUT is equal to Y can be used. Note the following guidelines:
The members must be enclosed in square brackets.
 Example
[POWN], [PCTRL], [POWN]
Add the pre x P to the percentage to use the Prior value.
 Example
[PPOWN], [PPVOTE]
Add the pre x I_ to the percentage to add the Intercompany value.
 Example
[I_POWN]
The syntax of the prior value can be combined with the syntax of the INTCO
value.
 Example
[I_PPOWN]
 Note
The calculation of POWN by both direct share method and group share method is
supported.
We also support the calculation of PCTRL (calculation of ultimate control %) in the

business rule tables.
There are two options for obtaining results: system calculations and manual
updates. There is also an option to change from system to manual while
calculating. This gives you the means to manage security by protecting system
calculations that cannot be overwritten by manual updates.
To support this, we also provide the O_ACCT dimension in EnvironmentShell by

adding a set of members that store only system calculations. The members are
POWN_SYS, PCTRL_SYS, and METHOD_SYS.
Group formula An expression that represents the percentage (or formula) to apply to the Destination
Group account from the Eliminations and Adjustments business rule. The value can
be an arithmetic expression combining any de ned percentage as de ned by the
Account dimension of the Ownership model. All percentages where the property
IS_INPUT is equal to Y can be used. The percentage must be enclosed in square
brackets. See the All formula eld above for further details.
Minority formula An expression that represents the percentage (or formula) to apply to the Destination
Minority account from the Eliminations and Adjustments business rule. An arithmetic
expression combining any de ned percentage as de ned by the Account dimension
of the Ownership model. All percentages where the property IS_INPUT is equal to Y
can be used. The percentage must be enclosed in square brackets. See the All
formula eld above for further details.
10/21/2020
Remark Text for this rule.
Integration Rule for Consolidation

Integration consolidation deals with the inconsistencies that occur when some consolidation rules are de ned using periodic mode while
the ownership hierarchy changes during the scal year.
Context
When you save or validate the I type rule in in the business rules user interface of Eliminations and Adjustment, the validation checks the
following elds:
Destination Audit Member must be blank.
Entity Property Filter must be blank.
Other Dimensions Filter must be blank.
Force Destination Members must be blank.
In the rule details, Force interco member and Swap entity interco cannot be selected.
In the rule details, Source Flow and Destination Flow cannot both be empty.
In the rule details, method-based multipliers must be used. Also, the integration rule must be 99 as the intercompany method. However,
rule validation does not check this.
How the integration rules work
When the integration mode is enabled for a model, the currency translation does not generate results on the group level.
You can nd a new type of consolidation rule with rule type I. The de nition of the consolidation rule with type I is similar to the generic
consolidation rule. The main difference is that for the integration rule, you do not have to de ne the destination audit ID because the
integration rule keeps the audit ID unchanged.
When using the integration rule, you can customize how the translated results in the reporting currency are posted to the consolidated
results to a speci c group. When integration mode is enabled, you do not have to de ne consolidation rules with types E, P, D, and L
because these types of rules can be replaced by integration rules. After integration mode is enabled, the previously de ned rules with types
E, P, D, and L are hidden from the user interface and are used in the consolidation calculation. You cannot create new rules with types E, P,
D, and L after integration mode has been enabled.
To enable the integration rule in consolidation, perform these steps:
Procedure
1. On the navigation panel, go to Administration Modeling Models .
2. Choose the model for which you want to enable integration mode. Only a Consolidation-type model can enable integration mode.
3. Edit this model by checking the Consolidation-Use Integration Rules option.
4. Save the change.

Script Logic

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Script Logic

Încărcat de

Drepturi de autor:

Formate disponibile

10/21/2020

Application Help - SAP Business Planning

Original content: https://help.sap.com/viewer/d1711b4a86b447c38415629229003c02/11.0.4/en-US

For more information, please visit the https://help.sap.com/viewer/disclaimer.

Allocation.lgf: runs an allocation

Consolidation.lgf: used to run a Legal Consolidation business rule

Copy_Opening.lgf: used to run a Balance Carry Forward business rule

FX_Trans.lgf: used to run currency conversion

ICBooking.lgf: used for running Intercompany reconciliation and diﬀerence posting

ICData.lgf: used to run Intercompany reconciliation

ICElim.lgf: used to run Intercompany reconciliation

MDXlib.lgf: library of MDX nancial functions

System_Library.lgf: includes basic examples of a set of keywords

Validation.lgf: used for running a Validation rule

The system constants le is located in the \\root\Webfolders\ <Environment>\systemlibrary\logiclibrary folder. You

Running Script Logic

Keywords display in blue

Constant values display in green

Comments display in grey

Library of MDX Functions

MDX Function Description Parameters

Ancestor Returns the ancestor of a member at a speci ed level <Member>, <Level>

Default Member Returns the default member of a dimension (none)

FirstChild Returns the rst child of a member (none)

FirstSibling Returns the rst child of the parent of a member (none)

IsEmpty Determines if an expression evaluates to the empty cell value <Expression>

Item Returns a member from a tuple <Numeric Expression>

LastChild Returns the last child of a member (none)

LastSibling Returns the last child of the parent of a member (none)

Members Returns the member whose name is speci ed by a string (none)

Parent Returns the parent of a member (none)

CoalesceEmpty Coalesces an empty cell value to a number <Numeric Expression>[, <Numeric

MDX Function Description Parameters

Custom Logic and BADI

Custom logic example

DATA: ls_param TYPE ujk_s_script_logic_hashentry,

l_log TYPE string,

lo_model TYPE REF TO if_uj_model,

lo_dim TYPE REF TO if_uja_dim_data,

ls_dim TYPE uja_s_dim,

lr_rec TYPE REF TO data,

lr_result_rec TYPE REF TO data,

l_intermediate_value TYPE uj_sdata,

lt_final TYPE REF TO data.

FIELD-SYMBOLS: <ls_rec> TYPE ANY,

<ls_result_rec> TYPE ANY,

<ls_time> TYPE ANY,

<ls_signed.data> TYPE ANY,

<lt_final> TYPE STANDARD TABLE

* Make sure all the parameters are passed.

READ TABLE it_param WITH KEY hashkey = 'YEAR' INTO ls_param.

cl_ujk_logger=>log( i_object = l_log ).

RAISE EXCEPTION TYPE cx_uj_custom_logic.

READ TABLE it_param WITH KEY hashkey = 'PERCENTAGE' INTO ls_param.

cl_ujk_logger=>log( i_object = l_log ).

RAISE EXCEPTION TYPE cx_uj_custom_logic.

* Get name of the account dim

RECEIVING ro_model = lo_model ).

CALL METHOD lo_model->get_dim_data_by_type

CALL METHOD lo_dim->get_info

time_dim = ls_dim-dimension. TRANSLATE time_dim TO UPPER CASE.

CREATE DATA lt_final LIKE ct_data.

* Loop through incoming data and create a result set

IS ACTUAL REC(FACTOR = 1.1, CATEGORY="FORECAST")