Logic Design & Troubleshooting in

SAP Business Planning and Consolidation

(4.x and 5.x)

Craig Bodington
Product Support
April 21, 2008

Agenda

Understanding logic in BPC

Logic Syntax

Troubleshooting Logic

Understanding logic in BPC

Topics

The types of logic used in BPC

When is each type of logic used

How and when is logic executed

Pros and Cons of each type

Who typically writes logic and when

Types of logic in BPC

Spreadsheet Logic
Formulas
Formula

exists only in the spreadsheets

Created

and maintained within individual workbooks and worksheets

Can

written in native Excel

reference multiple Applications

Dimension Logic

Formulas written in member sheets in the FORMULAHx property

Can be in any dimension but typically in the A{ccount} type dimension

The executed formula exists in the analysis services cubes

Created and maintained through manage members process in BPC

Administration

Specific to the applications the dimension resides in

Types of logic in BPC

Business Rules (aka table based logic)

Encrypted
Written

SQL Stored procedures that are shipped with the product

by product development and cannot be modified by users

Parameters

are defined in BPC Administration and then executed through

scripting logic

Parameters

are application specific but procedures are in all applications

Scripting logic (aka modeling logic, advanced logic, SQL logic)

Proprietary language written for BPC by product development

Two forms of the language (SQL and MDX) that perform the same function

Formulas are stored in one or more script files

Created and maintained through BPC Administration

Can reference multiple applications but code resides in one application

When is each type used

Spreadsheet
Logic

Dimension
Logic

Business
Rules

Modeling
Logic

Reporting Values

Yes

Yes

Yes

Yes

Creating Records

Yes

No

Yes

Yes

Moving Data

Yes

No

Yes

Yes

Calculations on base
records

Yes

Yes(1)

Yes

Yes

Calculations on
parent levels

Yes

Yes(1)

Yes(2)

Yes(3)

Uses

Only used when same formula applies at all levels of the application. This is for
performance reasons not an Analysis Services limitation.
(2) Calculations involving aggregated values are derived within the logic not referenced
from the cube.
(3) You can reference aggregations from the cube using the MDX form of the syntax but it
should NOT be done for performance reasons. There are alternate methods to derive
the values.
(1)

SAP 2007 / Page 7

When is each type of logic used

Spreadsheet logic

Reporting
For

reporting purpose use as needed.

Best

practice is to define the calculations in the database if you repeatedly use the same data on lots
of reports.

Budgeting/Forecasting
Limit

to templates that contain all the required values as inputs on that template.

If

the values the formula depends on can be changed in multiple templates, then its best to use logic
that calculates on the database.

Dimension logic

In SQL 2005 the general recommendation is not to use dimension logic.

ONLY used when the same rule applies at all levels

Can have a DRAMATIC impact on application performance if not used carefully.

Do not use if the values calculated need to be available for exporting out of the application.

Be careful of recursive calculations. Incorrect solve order can cause problems. Remember
EVERY number that is displayed in the application is a calculated value

When is each type of logic used

Business Rules
Use

when calculations MUST occur on base level members and then aggregate.

Application

of logic is limited to the business rules (stored procedures) that have been

written:

Allocations Performs allocation calculations

RunSummarize Performs addition and subtraction on accounts based on a formula property in the dimension

RUNCalcAccount Performs a straight summarization of a group of accounts

RUNCopyOpening Summarizes a group of activity accounts and copies the value into an opening balance account

RUNFX Performs standard currency translation.

RUNAutoElim Performs intercompany eliminations.

Script

logic

Use

when calculations MUST occur on base level members and then aggregate.

Use

when underlying data can be changed by multiple users and/or from multiple
templates.

Use

for complex calculations involving large data sets.

Use

for calculations that need to occur during scheduled or batch process without user
interaction.

Use

when calculations should automatically occur when values in the database are
changed.

How and when is logic executed

Spreadsheet Logic
Executes

when the workbook is opened and normal excel formulas calculate.

If

the workbook is an input template, the calculated values will only update the database
when the user performs a send to the database

Dimension

Logic

Executes

when the user queries the application through a template or schedule. If a user
has access to the SQL Server management studio, the value can be seen directly in the
cube.

Calculated
Values
Business

values only exist virtually in the AS cube.

are always based on the data in the cube when the query is executed by AS

Rules

Executed

by using the *RUN_STORED_PROCEDURE script logic command in a script

logic file.
Business

rule is executed when the script file is executed

How and when is logic executed

Scripting

Logic

Can be executed whenever data is changed by including the script in Default.lgf system
script file.

This is automatic when user changes data through an input schedule.

It

is selectable when importing data through Data Manager packages.

It

will NOT occur if data is directly manipulated in the fact tables by SQL queries or direct
SQL imports.

Default

logic executes based on the commands in the script file NOT based on the user
security profile.

Can be executed on demand by running a Data Manager package that is setup to reference
the script file. The code executes based on the script not user security but the user must
have a task profile that allows them to execute DM packages.

Can be executed through custom DTS/SSIS packages by including a step to run the scripts
files.

Script logic files can include (*INCLUDE) references to other logic files. If this is used, then
the included file is executed when the script file that contains the include is executed. The
included code is executed at the point that it is included relative to other code in the main
script file.

Pros and Cons of each type of logic

Spreadsheet Logic

Pros
Simple.its
Only

limited to what you can do in Excel.

Cons
Formulas
Can

only execute when the spreadsheet is opened.

end up re-implementing Excel-hell.

Logic

Excel

is contained in individual workbook files.

Dimension formulas

Pros
Uses

standard MS-MDX

Executes

at query time so data is always current

Formulas

are centrally stored and maintained

Cons
Can

have significant performance impact.

Can

become very complex if multiple hierarchies exist

If

formula is over 255 characters long, the code must be written in a separate file and included in the
dimension on the OPTIONS tab of the member sheet.

Pros and Cons of each type of logic

Business Rules
Pros
Code

is centrally stored and parameters are maintained by the application administrator

Execution
Typically

can be setup to run on-demand or automatically

fastest execution because it works in the relational database using SQL Server memory

Cons
If

product development hasnt written it, it cannot be done with BR

Stored
Rules

procedures cannot be customized to fit unique client needs.

tables are not well documented and can be difficult to understand

Pros and Cons of each type of logic

Script Logic
Pros
SQL

logic executes fast.

Code

is specific to customer needs and can be created as needed.

Scripts
Code

are centrally stored and maintained by application administrators

can be configured to execute on-demand, automatically as data changes, or both.

Permission

to run on-demand (DM packages) is controlled through application security task

profiles.
Can

create function libraries and access pre-written libraries.

Cons
MDX

logic can be very slow

Proprietary

language so skills are not generally available without specific BPC training.

Code

that executes as part of default logic does impact input template send times so use with
caution.

No

interface for editing system libraries. You have to directly access the files on the file server
modify with a text editor.

Who typically writes logic and when

Spreadsheet logic
Implementation

consultants, application administrators, report writers, end users, just

about any system user.

During
Dimension

entire life cycle of system

Logic

Implementation
Typically

consultants, application administrators

during implementation but can be modified anytime reporting requirements

change.
Business

Rules

Implementation
Typically
Script

consultants, application administrators

during implementation but can be modified anytime business processes change.

Logic

Implementation
Typically

consultants (normally write), application administrators (modify)

during implementation but can be modified anytime business processes change.

Logic Syntax

Topics

Logic overview

Dimension Logic

Scope of Execution

Business Rules
RunAllocation
RunSummarize
RunCalcAccount

Scripting Logic

Logic Overview

Spreadsheet logic
SIMPLE..its
Uses

Excel.

normal Excel cell formulas

Calculated

values are written to the database by normal update

functions: EVDRE, EVSEN, EVSND

Dimension Logic
SIMPLE

(sort of)..its Microsoft MDX.

Standard

MDX statements are put in the member sheet in the formula

property(ies) to create the calculation.

Calculation

is processed at query time on the requested intersections of

the cube by AS and return to the client.

Value

only exists in memory not in fact tables

Logic Overview

Business Rules
Underlying

code is Microsoft T-SQL but you cannot see or modify the

code. You can only call the procedures.

The

syntax is the calls to the stored procedures from scripting logic

and setting the parameters in the business rules tables

Logic Overview

Scripting Logic
NOT

simple.but not too hard once you get use to it.

Proprietary
Two

language for scripting calculations in BPC.

forms of the syntax

MDX

(no its not the MDX language)

SQL (no its not the T-SQL language)
The

names refers to where the calculation engine gets the initial record
set for processing
MDX

form queries the AS cube to generate the initial record set

SQL form queries the relational fact tables to generate the initial record set.
Both forms write any generated records to the relational writeback table.

Logic Overview

Dimension Logic Syntax

Its all about the Solve Order

MDX

uses an optional parameter (Solve_Order) in MDX expressions to control

calculation order.

When

specifying a solve order, you use the parameter and give it a positive
integer value (e.g. Solve_Order = 4).

If

no solve order is provided then the default value is zero.

The

value itself is not important in a of itself. Its the value on a particual formula
relative to all other formulas. For example, Solve_Order = 5 and Solve_Order =
500 have no intrinsic meaning other than any formula with a lower solve order
will be processed by AS first.

So,

if formula A has a solve order of 4 and formula B has a solve order of 5.

Then formula A will be calculated before B. This becomes critical if one formula
references another. If formula A was dependent on the value from B, then the
solve orders above would result no value being returned by A even thought you
would see a value for B.

Dimension Logic Syntax

MDX

formulas are used two places in the application

Calculated

Measures (Periodic, MTD, QTD, YTD are standard)

Dimension

formulas (user defined)

Calculated

measures are put into the relational store (tblFormula) and create the
formulas in AS when the application is built.

If

a custom measure is defined (not too common), it must be written in tblFormula

and then the application has to be saved. In native AS you can create the
calculations in the cube but the formulas would be deleted when the application is
saved in BPC Administration.

Measures

and solve order

Parent

child aggregations (not a measure) are performed within AS during processing or a

query time depending on the aggregation settings. This is done natively by AS with an
implicit solve order of zero.

Periodic
MTD,

references the SignedData values performs sign-flips. Has a solve order of 3.

QTD, and YTD all reference Periodic and perform the appropriate time summation
based upon the levels in the time dimension. They all have a solve order of 4 because
they have to calculate after Periodic.

Scope of Execution

Its all about the SCOPE

In

script logic (and some business rules) most problems are scope
problems.

Scope

refers to the slice of data that the logic is executed on.

There

is a default scope which is based on what event caused the

logic to execute.

The

actual logic itself can contain scoping statements that can alter
(increase, decrease, completely change) the scope from the default.

Execution

from BPC for Office

In order to build the correct data selection, the logic module will rely on
all occurrences of ALL different combinations of dimension members
that are found in the posted data, including the currency dimension,
but not including the [A]ccount dimension

Scope of Execution

Execution

from Data Manager

The

DTS/SSIS package the is setup to run the specific code will

include a PROMPT command. This is used to request and receive the
desired scope from the user executing the package.

Any

dimension can be prompted for. Most standard package prompt

for entity, category, and time.

The

logic module will then run the selected logic only for the selected
members of the selected dimensions.

The

members of all other non-specified dimensions will be assumed

as all non-calculated

The

only exception to the rule is the currency dimension (if existing in

the cube). If no currency is selected, and a currency dimension is
used in the cube, the logic will be executed just for currency LC.

Scope of Execution

For example, lets assume that the user has entered data for six cells in the cube.
The corresponding records could be the following:
CATEGORY

TIME

ENTITY

CURRENCY

ACCOUNT

PRODUCT

PERIODIC

ACTUAL

2007.JAN

SALESITALY

LC

UNITS

PRODUCTA1

12,345

ACTUAL

2007.JAN

SALESITALY

LC

INPUTPRICE

PRODUCTA1

100

ACTUAL

2007.FEB

SALESITALY

LC

UNITS

PRODUCTA1

54,321

ACTUAL

2007.FEB

SALESITALY

LC

INPUTPRICE

PRODUCTA1

200

ACTUAL

2007.FEB

SALESITALY

LC

UNITS

PRODUCTA2

6,789

ACTUAL

2007.FEB

SALESITALY

LC

INPUTPRICE

PRODUCTA2

300

In this case, BPC for Excel will pass a selection containing the category ACTUAL, the time
periods 2007.JAN and 2007.FEB, the products PRODUCTA1 and PRODUCTA2,
the currency LC, and the entity SALESITALY.

Scope of Execution

The scope of execution can be altered within the code

*XDIM_MEMBERSET

Defines a specific range of dimension members and

ignores the members of the default scope
*XDIM_MEMBERSET

{Dimension name} = {Members Set}

*XDIM_MEMBERSET

{Dimension name}<> {Members Set}

*XDIM_MEMBERSET

{Dimension name} = <ALL>

*XDIM_ADDMEMBERSET

= Takes the default scope and adds the specified

dimension members to it.

*XDIM_ADDMEMBERSET

{dimension} = {members set}

*XDIM_FILTER

Does not alter the scope but filters the record set to members that
satisfy the filter criteria
*XDIM_FILTER

{Dimension name} = {Members Set}

Scope of Execution

*GET_MEMBERSET is used to create a dynamic member list based upon real data in the
cube.

*XDIM_GETMEMBERSET {dimension} [={member set}]

[*APP={application}] optional
[*XDIM_MEMBERSET {dimension} [={member set}] as many of these as needed
*CRITERIA {expression}
*ENDXDIM

Scope of Execution

Example:

*XDIM_GETMEMBERSET EMPLOYEE=[EMPLOYEE].[CY_NEWHIRES].Children
*XDIM_MEMBERSET HRCOSTELEMENT=NO_ELEMENT
*XDIM_MEMBERSET TIME=2008.INP
*CRITERIA [COSTCAT].[LOGIC_FLAG]<>1
*ENDXDIM
Explanation
We will search the children of CY_Newhires in the employee dimension
Where HRCOSTELEMENT is equal to NO_ELEMENT
And TIME is equal to 2008.INP
To find which CY_Newhire children have a value <> 1 in account Logic Flag.
*Note CostCat is a TYPE A account dimension

Scope of Execution

A simple

example would be to hard code a member:

*XDIM_Memberset Datasrc = Input

Or

just as simple, we could hard code muliple members:

*XDIM_Memberset COSTCAT =
PTO_DAYS,FLOAT_HOLIDAYS,STAN_DAYS,FIXED_HOLIDAYS
Expand

the default scope to include the USD currency

*XDIM_ADDMEMBERSET CURRENCY = USD

Dynamic

variables can also replace hard coded members:

*XDIM_MEMBERSET TIME = %Months2%,2008.INP

Scope of Execution

How

do you create dynamic variables?

MDX

approach *MEMBERSET({variable}, {member set in MDX format})

*MEMBERSET(%Months2%, "Descendants([TIME].[2008.Total],999,leaves))
SQL approach

*SELECT ({variable}, {What}, {From}, {Where})

*SELECT(%MONTHS2%, "[ID]", "TIME","[YEAR] = 2008' AND [LEVEL]=MONTH''")

Business Rules Syntax

Business Rules Syntax - RunAllocation

Allocation Engine Table Components
*RunAllocation initiates the allocation
Dimensions to include in the allocation
*DIM Account
Dimensions not defined in the allocation will default to scoping.
What Base member to be allocated
supports multiple members WHERE=AccountA,AccountB
Where Destination members where the allocation will be written
supports WHERE=BAS(ParentHX) syntax to define all base level members of a
parent.
supports use of properties WHERE=[STATUS]="FT" AND [EMP_CLASS]="Existing
Using (Optional) member storing an allocation factor, the amount of the driver.
Total (Optional) Sum of the driver or Using amounts. Very useful when calculating a percentage
Using/Total
Factor (Optional)
Omitted - factor will always default to 1, Using and Total columns are ignored
Numerical values such as 2 What x 2
Using What is multiplied by Using. Total column is ignored.
Using/Total What is multiplied by Using/Total
1/COUNT Divided evenly among 1/count of where members

Business Rules Syntax - RunAllocation

Example below takes data stored in Time=2008.INP, Account=Sales and

spreads that amount evenly to Account=Sales for all base time periods of
2008.Total
*RUNALLOCATION
*FACTOR =1/Count
*DIM Account
*DIM TIME

WHERE=<<<;

WHAT=2008.INP; WHERE=BAS(2008.TOTAL);

*ENDALLOCATION
*COMMIT

WHAT=SALES;

Business Rules Syntax - RunAllocation

Example below takes data stored in Time=2008.INP, Account=Sales and

spreads that amount evenly to Account=Sales for all base time periods of
2008.Total
*RUNALLOCATION
*FACTOR =1/Count
*DIM Account
*DIM TIME

WHERE=<<<;

WHAT=2008.INP; WHERE=BAS(2008.TOTAL);

*ENDALLOCATION
*COMMIT

WHAT=SALES;

Business Rules Syntax - RunSummarize

Business Rules Syntax - RunCalcAccount

Calculation

Rule Name - The name of the rule

NOTE:

The name you enter in this field is referenced in the subroutine and stored
procedure. For example, if you name the rule N, your subroutine call would be:
RunCalcAccount(ThisApp,%Category_Set%,N). This assumes that you want to run this
calculation on LC only.

The

name can be anything you want. Customers have used numbering schemes so that
they know what piece to run at each point.

Calculation
Source

Rule Description - The rule description.

Month

Blank:

the current month

Non-blank:

the month where to read the value to process. It can be an absolute or a

relative amount

Source

Year

Blank:

the current year

Non-blank:

amount

the year where to read the value to process. It can be an absolute or a relative

Business Rules Syntax - RunCalcAccount

Calculations Table Fields

Apply to YTD - In a PERIODIC application if this checked, the YTD value will be used in
the calculation
Invert Sign - If checked, the value of the amount is reversed.
Account - The source ACCOUNT
Source Account Member - The source DATASRC member
Source Subtable Member - The source subtable member
Destination Account - The destination ACCOUNT. If left blank, the value equals Account
Destination Account Member - The destination DATASRC member. If left blank, the value
equals Source Account Member.
Destination Subtable Member - The destination subtable member. If left blank, the value
equals Source Subtable Member

Script Logic Syntax

Logic can be broken down into 5 types of commands

Scoping

commands

Body/Code

What do I want to do with the scoped records?

*WHEN Statements
*REC statements
*GET statements
*FOR loops

Writing

the records to the fact table

*COMMIT

Performance

commands

*XDIM_NOSCAN
*XDIM_MAXMEMBERS

Special

purpose commands

*LOOKUP
# memory variables
*Calc_DummyOrg

Script Logic Syntax

*WHEN All SQL logic requires a when statement. If you do not see one,
the you are dealing with MDX logic.
*WHEN {criteria}
*IS {valid condition1}[,{valid condition2},] *REC[([FACTOR|EXPRESSION={Expression}[,
{dim1}={member},{dim2}=])]
[*ELSE]
*REC[([FACTOR|EXPRESSION={Expression}[,{dim1}={member},{dim2}=])]
*ENDWHEN

Script Logic Syntax

{criteria}

Example:

is what to test. Typically, its a property of the current member of a dimension. DimensionName.Property
*WHEN ACCOUNT.RATETYPE

The default property is ID

*WHEN ACCOUNT.ID is the same as *WHEN ACCOUNT

{ValidCondition}
Example 1: *IS "AVG","END
Example 2: *IS 10,20,30
If no operator is specified, the *IS clause assumes the presence of an equal sign (*IS = AVG, END).
*IS > 2,
*IS <= 7
*IS <>ABC

If any operator is used, only one value can be passed. (This syntax is invalid: *IS >2,3,4)

Script Logic Syntax

*REC The heart of SQL logic. Produces a new RECord in the fact table
*REC({FACTOR|EXPRESSION},[Dimension=member])
The first part of the command is the calculations rule. This produces the
numeric value of the new record.
The second part of the statement provides the destination of where to send
the data. If a dimension is omitted from the list, the value of the current
record is used for the dimension.

Script Logic Syntax

Factor means to multiply the value of the current record by some value.
*REC(FACTOR=1)
*REC(FACTOR=-1)
*REC(FACTOR=1/12)
*REC(FACTOR=(2+3))

Signeddata x1
Signeddata x -1
Signeddata/12
Signeddata x5

Expression is any valid algebraic expression using +,-,/,*

*REC(EXPRESSION=1) All posted records will equal 1. Ignores the signeddata amount
*REC(EXPRESSION=%VALUE%) %Value% is signedata, so this is equivalent to Factor=1
*REC(EXPRESSION=%VALUE%*10)

Signeddata *10, same as FACTOR=10

*REC(EXPRESSION=%VALUE%+10)

Signeddata +10

Script Logic Syntax

*GET used within a REC statement to retrieve the value of another

record that is in memory based upon the scope of exection.

GET({dimension}={member}[, {dimension}={member}])
Where:
{dimension} is a valid dimension name
{member} is a valid dimension member. This can be an explicit member name like ABC (in which case it
should be enclosed between double quotes), or it can be derived reading the property of the current
member of any dimension.
GET(ACCOUNT=ABC)
GET(ACCOUNT=ACCOUNT.MYPROPERTY)
GET(ACCOUNT=ACCOUNT.ELIMACC,ENTITY=INTCO.ENTITY

Script Logic Syntax

*FOR/*NEXT Loops Executes code for a specifc set of members. The

main difference in this code and the *WHEN statement is that the *FOR
loop will cycle through the members regardless of scope and regardless
of the absence of data.
*FOR {variable} = {set}
{text}
{text}

*NEXT

Script Logic Syntax

*WHEN TIME
*IS <>TOT.INP
*WHEN ACCOUNT
*IS PERCENT_ALLOC
*FOR %YEAR%=2003,2004,2005
*FOR %MONTH%=JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC
*REC(FACTOR=GET(ACCOUNT="TOT.OVRHEAD",TIME="TOT.INP")/100,TIME="%YEAR%.%MONTH%")
*NEXT
*NEXT
*ENDWHEN
*ENDWHEN

Script Logic Syntax

*COMMIT takes the produced records out of memory and writes them as
difference records to the writeback fact table.

A common problem with logic is forgetting to put in a commit statement. There is

an implied commit when the logic finishes executing of the current records in
memory. However, if the logic has several layers of calculations earlier values can
be dropped out of memory and lost if they are not committed till the end.

Also, many commands are commit block specific (e.g. *XDIM_MEMBERSET)

which means any changes made are reset at the point a commit is reached.

Script Logic Syntax

*XDIM_NOSCAN

Skips processing records through the logic

*XDIM_NOSCAN
Example:

{Dimension name} = {Members Set}

*XDIM_NOSCAN DATASRC=PRICE

Used in cases where records are needed in memory for calculation purposes but
the do not need to be processed through the main code.

Script Logic Syntax

*XDIM_MAXMEMBERS used to limit the number of records that are read

into memory at once. The default is to read all data into memory when
processing begins. However, for memory utilization reasons you may
need to limit this. There is a performance impact from cycling through the
blocks of records.

*XDIM_MAXMEMBERS {dimension}= {max number of members}

Example:

*XDIM_MAXMEMBERS Entity = 50

This instruction, in case the entities to process exceed the limit of 50 members, will
break the query into multiple queries of no more than 50 entities each.
Important: the maximum number of members can be specified for up to TWO
dimensions

Script Logic Syntax

LOOKUP Used to query for a value that is not currently in memory. Can
be used to query across applications.
*LOOKUP {App}
*DIM [{LookupID}:] {DimensionName}="Value" | {CallingDimensionName}[.{Property}]
[*DIM ]
*ENDLOOKUP

Where:
{App} is the name of the application from which the amounts are searched
{DimensionName} is a dimension in the lookup app
{CallingDimensionName} is a dimension in the current application
{LookupID} is an optional identifier of the looked-up amount. This is only required when multiple values
must be retrieved

Script Logic Syntax

*LOOKUP RATE
*DIM ENTITY2="DEFAULT"
*DIM SOURCECURR:INPUTCURRENCY=ENTITY.CURR
*DIM DESTCURR1:INPUTCURRENCY="USD"
*DIM DESTCURR2:INPUTCURRENCY="EURO"
*DIM RATE=ACCOUNT.RATETYPE
*ENDLOOKUP
In the above example, three different values are retrieved from the INPUTCURRENCY
dimension (the rate of the currency of the current entity, the rate of the currency EURO and
the rate of the currency USD). Each of these values has been assigned a specific identifier
(SOURCECURR, DESTCURR1 and DESTCURR2) that will be used somewhere in the
WHEN/ENDWHEN structure.

Script Logic Syntax

Memory variables (the # prefix)

It is now possible to create intermediate result and assign them to dummy members (like dummy accounts or
dummy members of any other dimension). These members can be used as placeholders to store
intermediate results that can be used as inputs for subsequent calculations. These values will be
automatically skipped at commit time. Dummy members must be identified with a leading pound (#)
sign.
Example:
*WHEN ACCOUNT.FLAG
*IS = Y
*REC(ACCOUNT=#TEMP)
*ENDWHEN
*GO
*WHEN ACCOUNT
*IS #TEMP
*REC(FACTOR=GET(ACCOUNT=MULTIPLIER),ACCOUNT=FINAL)
*ENDWHEN

Script Logic Syntax

*CALC_DUMMY_ORG used to calculate the values at parent levels of a

given hierarchy in memory without having to request the data from AS.
*CALC_DUMMY_ORG {DimensionName} = {OrgProperty}
Example
*CALC_DUMMY_ORG ACCOUNT=PARENTH1
This will calculate all levels of the main hierarchy in the account
dimension. Note, that all members must be in memory for the results to
be correct.

Script Logic Syntax

Moving data between applications

*DESTINATION_APP is used to designate the application where records will be moved to.

*SKIP_DIM is used to skip over dimensions that do not exist in the destination application.

*RENAME_DIM is used to rename a dimension to the target application dimension

*ADD_DIM is used to add destination dimension that does not exist in the source
application.

Script logic syntax

*DESTINATION_APP = OPERATIONS
*SKIP_DIM= EMPLOYEE
*SKIP_DIM= INTCOCOSTCTR
*RENAME_DIM HRCOSTELEMENT=OPSCOSTELEMENT
*ADD_DIM BACKLOG= No_Backlog
*ADD_DIM BILLTYPE= NO_BT
*ADD_DIM BUSINESSAREA= NO_BA
*ADD_DIM CONTRACT= NO_CLIN
*ADD_DIM CUSTOMER= NO_CUST
*WHEN *
*IS *
*REC(FACTOR=1, Datasrc="INPUT",)
*ENDWHEN
*COMMIT

Troubleshooting Logic

Topics

Spreadsheet logic troubleshooting

Dimension logic troubleshooting

Table based logic troubleshooting

Scripting logic troubleshooting

Spreadsheet logic troubleshooting

Typically

not coding issues. Remember.its just Excel

Be

careful of range names that are using in the BPC add-in (e.g.
Application)

Be

careful of using the same range name in different worksheets in the

same workbook.

If

they are using formulas in the worksheets that are used to derive
member names for use in the row or column keys, you can have cases
where the formulas do not resolve before the request gets passed to the
server. Typical symptom is the first refresh doesnt work but the second
refresh does.

Clients

that use comments and are migrating from 4.x to 5.x may run into
issues if they are using VBA to refresh data and comments. The comment
macros no longer exist. Also, comments refresh after data in 5.x

Dimension logic troubleshooting

Its
If

probably solve order

there are multiple hierarchies in the dimension (5.x specific) then there is
a change where there has to be a FormulaHx property for each hierarchy
and formulas must fully qualify out each hierarchy case.

Dimension logic troubleshooting

Suppose we want to define a formula as following in a dimension with 3 hierarchies:

#CF_ST_FIN_RATE= ((#IFRSTRATE/#WKSYR)*#WKSCURMTH)
Where IFRSTRATE, WKSYR and WKSCURMTH are base members of hierarchy H1 of Account dimension, and
CF_ST_FIN_RATE is a dimension formula in H1 of account dimension.
The correct formula for H1 is
IIF(Account.H2.CurrentMember is Account.H2.[All Account.H2] And Account.H3.CurrentMember is Account.H3.[All
Account.H3], (Account.H1.IFRSTRATE/Account.H1.WKSYR)*Account.H1.WKSCURMTH, NULL)
An example of this formula for H2:
IIF(Account.H1.CurrentMember is Account.H1.[All Account.H1] And Account.H3.CurrentMember is Account.H3.[All
Account.H3], (Account.H2.IFRSTRATE/Account.H2.WKSYR)*Account.H2.WKSCURMTH, NULL)
An example of this formula for H3:
IIF(Account.H1.CurrentMember is Account.H1.[All Account.H1] And Account.H2.CurrentMember is Account.H2.[All
Account.H2], (Account.H3.IFRSTRATE/Account.H3.WKSYR)*Account.H3.WKSCURMTH, NULL)

Business rules troubleshooting

Most likely issue is with the parameters in the table.

Make sure the name of the rule there calling is correct.

You might see cases where logic directly calls the stored procedure
(*RUN_STORED_PROCEDURE) directly rather than using the wrapper
function. The SP name can change so the best practice is to always call
the wrapper which stays the same.

Because the procedures are encrypted, there isnt anything you can do to
check for code errors.

Script logic troubleshooting

Its probably a scoping issue

The

code works some times especially if it doesnt work from input screens
but does if you run from DM.

Data

that impacts calculation comes from multiple input templates.

4.2
If

you are dealing with a 4.2 client, then you have the logic debugger available in
the product to help make code testing easier.

Be

careful with the debugger if there are multiple commits. The debugger does
not simulate posting records for subsequent commit blocks so values will not be
available unless you actually post the.

Script logic troubleshooting

4.x and 5.x

If

you see properties being used in the code, make sure they have values and
are correct for the current scenario.

User

log files on the file server in the private publication folder

Check

for scoping issues (e.g. not data found messages)

If

records are generated in the log make sure they are looking for data in the
correct locations

Get

the SQL from the log if youre seeing not records found and remove
restrictions from the WHERE clause to see where the data resides.

If

the client is looking at data directly in the writeback table and see records
but the values are wrong, make sure theyre looking at all the data (think
difference records).

If

the values in the cube are wrong but correct in the fact table, make sure
theyre not running SQL process to clear data without processing the cube.

Spreadsheet logic troubleshooting

Spreadsheet logic troubleshooting

Dimension logic troubleshooting

Table based logic troubleshooting

Scripting logic troubleshooting

Additional References

Dimension logic (MDX)

MDX Solutions comprehensive MDX syntax reference

http://www.amazon.com/MDX-Solutions-Microsoft-AnalysisServices/dp/0471400467

BPC Script Logic

The on-line help document provided with BPC is available from the
Administration client.
Select Using script logic > Rules keyword reference

Questions

SAP 2007 / Page 66