Tips and Tricks For

Tips and Tricks for
Implementing and
Optimizing Formulas in
SAP NetWeaver BI
Integrated Planning
Marc F. Bernard
Chief SAP NetWeaver Specialist
SAP NetWeaver RIG
2007-05-30
Prerequisites
Required Knowledge:
General understanding of BI Integrated Planning in

SAP NetWeaver 7.0
Recommended Knowledge:
Some experience with implementing formulas in BI Integrated

Planning or BW-BPS
SAP AG 2007, Tips and Tricks for Formulas in BI-IP / Marc F. Bernard / 2
Learning Objectives
Learn about planning functions in BI Integrated Planning and how

to decide which type of function you should use
Design formulas the right way
Understand how formulas are configured
Resolve performance problems or avoid them in the first place
Hear tips & tricks for implementing formulas
Planning Function Types
Designing Planning Functions
Configuring Formulas
Performance Tuning of Formulas

SAP NetWeaver BI Architecture for Business Planning
Enterprise Portal
Enterprise Reporting, Query and Analysis

Information Broadcasting
BEx Web BEx Analyzer
Pattern MS Excel
Web Analyzer Web Application Designer Report Designer Add-in
BEx Query Designer
Business Planning & Analytical Services
Analytical Engine Planning Modeler

OLAP services Planning specific
• Drill Down
Planning Functions &
services
• Currencies/Units Sequences
• Enqueue
• Calculations/Formulas • Distribute
• Validations
• Exceptions/Conditions • Data slices • Formulas (FOX) Focus for this webinar
• Variables • Characteristic relations • Copy
• Hierarchies • Revaluate
• Aggregation • Repost
• Sort • Forecast
•… • Custom defined
•…
Caching services Plan data cache
Enterprise Data Warehousing

Operational Architected Data Marts Master
Data Store Data Warehouse Layer Data
Various Business Requirements and Their Solutions
Predefined Types of
Distribute
planned revenue
Planning Functions
Copy data from to different
actual version to products Delete the data
plan version in one plan
version
Increase the planned
revenue by 10% Convert from Euro to
USD
Formulas
Quantity times
Price Calculation Scheme for
Contribution Margin
Calculate Revenue
depending on number of
Customer defined workdays in company
Type of Planning calendar
Function
Predefined Planning Function Types
Predefined Planning Function Types

Copy
Delete
Repost
Revalue
Distribution by Keys
Distribution by Reference Data
Currency Translation
Unit Conversion
Generate Combinations
Report to Valid Combinations
Deletion of Invalid Combinations
Tip
Try to use one of these types or a
combination of them first before
you implement formulas.
Formulas (FOX)
Definition:
Formulas define how the transaction data is to be processed in

order to generate plan data. Formula functions enable you to use
extended mathematical functions to calculate plan data.
In addition to different calculation functions, which you can use for

value assignment in formulas, there is also the possibility to model
complex flow structures with the formula language FOX (FOrmula
eXtensions).
Complexity vs. Functionality
Customer
Predefined Defined
Function Types Formulas (FOX) Function
Types
Complexity, Functionality
When to Use Formulas (FOX)
Create a formula if…
There is no predefined planning function type that does the job
The task cannot be done in one predefined planning function

type but several planning functions/sequence are needed
The customizing of a standard planning function type gets to

complicated
Performance
Many times it is faster to have one formula doing the job than a
number of planning functions
When to Use Customer Planning Function Types
Create a custom planning function type if…

The logic in FOX would be very complicated
You need several complex FOX formulas for doing the job
You need syntax elements that are not contained in FOX
You need the same planning function in different levels. You can use the
same function type in several places instead of copying a predefined or
formula function to the different aggregation levels.
Disadvantages
You need ABAP OO programming skills
Have to make sure there is someone in the project that can maintain the
planning function types (ABAP OO classes)

How to Design a Planning Function
The following holds for EVERY planning function:

Define the business scenario for the planning function.
Determine the proper level – i.e. the level of aggregation in the
InfoProvider that is needed for the business scenario. You have
to identify the proper characteristics and key figures.
Write down some sample records in that level.
Write down how the data records should look like after executing
the planning function.
Identify the fields in the data records that are changed or used
for calculation by the planning function. These are the “fields to
be changed” in the planning function.
Identify the type of planning function (predefined type, formula
(FOX), exit) and configure the planning function.
Example for a Planning Function
Business Scenario
You want to copy the amount for each product from the current year to
the next year.
Aggregation Level
We use an InfoProvider with 0PRODUCT and 0FISCYEAR as
characteristics and 0AMOUNT as key figure.
0PRODUCT 0FISCYEAR 0AMOUNT
0001 2007 100 Before

0002 2007 200
0001 2007 100

0001 2008 100
After
0002 2007 200
0002 2008 200
Field(s) to be changed
Planning Functions – Subsets
To make it easier to configure planning functions, the systems

packages the plan data into smaller subsets.
Packaging into subsets is based on what fields are changed by the
function
The more fields that can be change, the lower the number of subsets
– All fields can be changed = One subset with all data
– No fields can be changed = One subset per record
The plan data for each subset is processed separately
Planning Functions – Subsets: Example
Sample data
records: 0PRODUCT 0FISCYEAR 0AMOUNT
0001 2007 100
0001 2008 100

0002 2007 200
0002 2008 200
Fields to be changed Fields for grouping Number of calls/records

Empty All 4 calls,
one record per call
Year Product 2 calls,
records (1+2) and (3+4)
Product Year 2 calls,
records (1+3) and (2+4)
All Empty 1 call,
all records
Flowchart for Planning Functions
Start of Execution
Data Selection (based on Filter)
Build Subsets from Selected Data
Phase 1 Reference Data (based on Function)
Add Subsets for Reference Data
FOREACH Subset.
Phase 2 Execute Function
ENDFOR.
End of Execution
How to Test Planning Functions
Tips for Testing Planning Functions
Create filters for small packages of plan data (e.g. 2 records)
Create a test query for your filter

Put the fields to be changed in the rows, the key figure(s) in the
columns, and the remaining characteristics in the header (free
characteristics). As a result, the query output looks like the data
records that are processed by the formula.
Execute the planning function using the trace ("execute with

trace")
In formulas you can send messages with the relevant values to

the message log of the planning function

Configuring Formulas 1/3
1. Start the Planning Model and go to the Planning Function tab
2. Choose Create
3. Select the type Formula, enter technical name and

description, and pick the aggregation level
4. Choose Transfer
5. Select which fields should

be changed (mandatory) and
which fields should be used
for conditions (optional)
6. Enter the conditions
{SEMPS_003, Mango Juice} = {SEMPS_003, Apple Juice} + {SEMPS_003,

Orange Juice}.
7. For each condition, enter

the formula (FOX) in the
editor
Various forms of input help and

documentation of program
elements are available
Control display showing

which fields can be changed
in the formula.
Formula Syntax
Syntax for formulas (FOX)

A formula consists of one or many statements
Each statement needs to be concluded by a period "."
Among others a statement can contain…

one or several operands for reading data
one operand for changing data
various functions for calculations and information retrieval
various program elements
Choose Check button in the editor to verify syntax of formula.
Formula Elements
Calculations Information
Access Data Records
Retrieval (e.g.
Variable Values)
String
Operations Call External
Formulas Functions
(FOX)
Foreach and Do
Loops
Predefined
Conditional Mathematical
Branching Programming Functions
Variables
FOX = Formula Extensions

Access to Data Records
Operands
The following syntax is use to access data records
– {key figure, field to be changed 1, field to be changed 2, …, field t.b.c. n}
To read data use the operands on the right side of an equation
To change data use the operands on the left side of an equation
You can read and change only records that are included in the filter
You can use the input help for

entering operands into the editor
Note: In contrast to BW-BPS, for BI-Integrated Planning "key figure"

is always a field to be changed
Access to Data Records – Example
Example
Business Scenario
– Copy data for each product from the current year to the next year
Fields to be changed
– Key Figure, 0FISCYEAR
Formula
– {0AMOUNT, 2008} = {0AMOUNT, 2007}.
Explanation
Amount for year 2007 is read
Amount for year 2008 is changed
You do not have to care about the product because of the subsets.
There's an automatic FOREACH product done by the system.
Access to Reference Data
New Feature
Reference Characteristics in Operands

Business Scenario
– We are calculating the revenue from the planned quantities and the prices.
Revenue and quantity are stored in the plan version 1 whereas the prices
come from the actual version 0.
– Key Figure
Formula
– {0REVENUE} = {0QUANTITY} * {0PRICE | 0VERSION = 0}.
Explanation
Version does not have to be in the fields to be changed but can be used
as reference characteristic
The filter the selection is set to version 1
Access to Reference Data
New Feature
Input Help for Operands with Reference Fields
You can pick additional

reference characteristics
Result of operand in editor:

{ SEMPS_003, Apple Juice | Z_PRODLIN = Juice }
Variables
Local variables are…

used to store temporary results
defined using the DATA statement
always referencing a data type
usable only in a given formula
You can use the input help for

variable definitions into the editor
Global BI variables are…

used to integrate with analytical engine
defined in Planning Modeler or BEx Query Designer
referencing characteristic or numeric values
usable system-wide
accessed using VARV and VARC functions
Loops
General Looping
Variable number of loops
– DO... EXIT… ENDDO
Predefined number of loops
– DO n TIMES... ENDDO
Looping over Certain Values

Plan data values (only existing records)
– FOREACH <Variable>... ENDFOR
Reference data values
– FOREACH <Variable> IN REFDATA... ENDFOR
Selection criteria (filter)
– FOREACH <Variable> IN SELECTION... ENDFOR
BI Variable New Feature
– FOREACH <Variable> IN VARIABLE... ENDFOR
Loops – Example
Example
Formula
DATA year TYPE 0FISCYEAR.
FOREACH year.
{0AMOUNT, year} = {0AMOUNT, 2007} * 1.05.
ENDFOR.
Explanation
The values for YEAR are taken from the records in the selection
Assume we have data records for year 2008 and 2009.
– First loop: YEAR is replaced with 2008 and system calculates
{0AMOUNT, 2008} = {0AMOUNT, 2007} * 1.05.
– Second loop: YEAR is replaced with 2009 and system calculates
{0AMOUNT, 2009} = {0AMOUNT, 2007} * 1.05.
Conditional Branching
Program Flow Based on Conditions

Single condition
– IF… ENDIF.
Single condition and others
– IF… ELSE… ENDIF.
Multiple conditions
– IF… ELSEIF… ELSE… ENDIF.
Example
Formula
IF {0AMOUNT, 2007} > 1000.
{0AMOUNT, 2008} = {0AMOUNT, 2007} * 1.05.
ELSE.
{0AMOUNT, 2008} = {0AMOUNT, 2007} * 1.10.
ENDIF.
Program Elements
Program Elements
Powerful macro language
Mathematical function library
Various financial calculations
Access to master data attributes
Access to BI variables
String operations
New Predefined Functions in Formulas
New Feature
String Operations
Get part of a value
– SUBSTR
Concatenate values
– CONCAT
Replace a part of a value with another one
– REPLACE
Determine length of a value
– STRLEN
Compare values
– CP, CO, CA, CS (contains pattern, only, any, string)
Financial Functions
Currency Translation
– CURC
Rounding
– ROUND
Calling ABAP Function Modules
New Feature
You can call selected ABAP function modules

within a formula
Enter the name of the function module
in the table RSPLF_FDIR
Use ‘CALL FUNCTION…’ in the formula
You can use importing, exporting and
changing parameters
Restriction on types for parameters
– F, I, D, or STRING
– Types of characteristics and attributes
– No structures or tables
If the ABAP function module needs to raise an exception you have to
use the construct MESSAGE...RAISING

How to Optimize Formulas (FOX)
The idea is to reduce the complexity of the formula, without

changing the result of the calculation.
Less lines of FOX leads to less ABAP coding that the system has to
process and therefore faster execution times.
There are two main targets for optimization:

1. Formula Operands
2. Foreach Loops
Real-world Example
Fields to be changed:
{ Key figure, Cost Element, Version, Planning Item, InfoProvider }
Parameter group:
* Cash Discount = (Base Revenue - Price Adjustment) * 2%
DATA C TYPE 0COSTELMNT.
DATA V TYPE 0VERSION.
DATA P TYPE ZPLANITEM.
FOREACH C,V,P.
{0AMOUNT,0000415001,V,CASHDISC,PA000004} =
( {0AMOUNT,0000400001,V,CUSTSALES,PA000004} -
{0AMOUNT,0000410001,V,PRICADJDIS,PA000004} +
{0AMOUNT,0000405002,V,PRICADJBKT,PA000004} ) * 0.02.
ENDFOR.
Optimization 1: "Fields to be changed"
Find all characteristics that are restricted to only one value in the
formula. This means that the characteristic is NOT being changed
and therefore should be remove from the "fields to be changed".
Optimization 1: Example
Optimization 1: "Fields to be changed" that are not changed
Remove from "Fields to be changed": Key figure = 0AMOUNT

Remove from "Fields to be changed": Version = V
Remove from "Fields to be changed": InfoProvider = 'PA000004'
{ Cost Element, Planning Item }
Parameter group:
DATA C TYPE 0COSTELMNT.
DATA P TYPE ZPLANITEM.
FOREACH C,P.
{0000415001,CASHDISC} =
( {0000400001,CUSTSALES} -
{0000410001,PRICADJDIS} +
{0000405002,PRICADJBKT} ) * 0.02.
ENDFOR.
Optimization 2: "Formula selection"
Determine the selections i.e. the characteristic combinations that

are changed by the formula and compare it against the filter.
There can be several cases:

Perfect match (best case)
Filter selection is equal to the formula selection. The system will read
only data that is actually being changed.
Filter selection is bigger (worst case)
The system will read more data than required by the function.
Filter selection is smaller (error)
The formula potentially generates records that are not part of the filter,
which could lead to an error message.
Optimization 2 A: "Formula selections (excl. reference data)" that are different than
filter
Restrict level/filter to formula selection: Key figure

Level/Filter:
= 0AMOUNT, ZPRICEADJ, ZUNCOLLAR
Level contains more key
Formula: figures than necessary
= 0AMOUNT
Restrict level/filter to formula selection: Cost Element

Level/Filter:
No restriction
Level is not restricted on Cost
Formula: Element but formula changes
= '0000415001' only one Cost Element
Optimization 2 B: "Formula selections (incl. reference data)" that are different than
filter
Optimization works same way as 2A but tries to combine two database selections.
Optimization 3: "Conditions"
Optimization 3 A:
If the condition is equal to the filter restriction, then the condition

can be removed.
Optimization 3 B:
If there's only one condition it can be merged with the filter

selection.
Optimization 4: "Formula operands"
It is not necessary to write to the same result operand several times.

It's also not necessary to read the same reference operand several
times. Instead, the operands should be stored temporarily using
local variables (DATA).
Optimization 4 A:
Based on result data only
Optimization 4 B:
Based on reference data only
{ Material, Planning Item }
Parameter group (BEFORE): If there are 1,000 materials,

then TOTALSALES has to be
DATA M TYPE 0MATERIAL.
read and updated 1,000 times
{M,TOTALSALES} = 0.
FOREACH M.
{M,TOTALSALES} = {M,TOTALSALES} + {M,CUSTSALES}.
ENDFOR.
Parameter group (AFTER):
DATA M TYPE 0MATERIAL.

There's only one update of
TOTALSALES independent of
DATA TOTAL TYPE F.
the number of materials
TOTAL = 0.
FOREACH M.
TOTAL = TOTAL + {M,CUSTSALES}.
ENDFOR.
{M,TOTALSALES} = TOTAL.
Optimization 5: "Operands in Foreach Loops"
If an operand is used in an foreach loop but does not depend on any

foreach variable, then the operand is being processed too often and
therefore should be moved before (reference data) or after (result
data) the foreach loop.
Optimization 5 A:
Based on result data only
Optimization 5 B:
Based on reference data only
{ Cost Element, Planning Item }
Parameter group (BEFORE):

DATA C TYPE 0COSTELMNT. CASHDISC is updated inside
DATA P TYPE ZPLANITEM. the loop although it does not
FOREACH C,P. depend on C or P.
{0000415001,CASHDISC} =
( {0000400001,CUSTSALES} -
The other operands are read
{0000410001,PRICADJDIS} + inside the loop although they
{0000405002,PRICADJBKT} ) * 0.02. don't depend on C or P.
ENDFOR.
Parameter group (AFTER):

{0000415001,CASHDISC} =
( {0000400001,CUSTSALES} -
Ultimately the complete
{0000410001,PRICADJDIS} + Foreach loop can be
{0000405002,PRICADJBKT} ) * 0.02. removed.
Optimization 6: "Formulas on MultiProviders"
If the formulas is using data of only one InfoProvider but is defined

on a MultiProvider, then the complete formula should be moved to
the single base InfoProvider.
Optimization 7: "Nested Loops"
Use nested FOREACH statements only if necessary.
Use FOREACH VAR1,VAR2, ..., VARn wherever it is possible.
Example: Records

0001 2010 10
0002 2011 20
FOREACH product.
FOREACH year.
FOREACH product, year.
...
ENDFOR.
ENDFOR.
ENDFOR.
0001 2010 10 0PRODUCT 0FISCYEAR 0AMOUNT

0001 2011 0
0001 2010 10
0002 2010 0
0002 2011 20
0002 2011 20
Optimization 8: "If Statements"
If Statements versus Conditions - when to use which:

When the logic depends on variables with ranges, several values or
hierarchy nodes, then use conditions.
When using if-statements you only have one planning function and thus
only one formula. Therefore the formula is easier to understand.
Tip 9: "Naming Conventions"
Use naming conventions for local FOX variables, e.g.:

CHA_… for characteristics,
KYF_… for key figure values,
VAR_… for global BI variables,
ATR_... for attributes,
INT_… for integer numbers,
DAT_... for dates,
TIM_... for times.
Add comments to the formula.
Tip 9: Example
{ Key figure name, Posting period, Version }
* Posting period and total amount

DATA CHA_0FISCPER3 TYPE 0FISCPER3.
DATA KYF_TOTAL TYPE F.
* Planning version (via variable)
DATA VAR_ZPLNVER TYPE 0VERSION.
* Actual period (attribute of plan version)
DATA ATR_ZACTPER TYPE 0FISCPER3.
* Get actual period from plan version (via variable)
VAR_ZPLNVER = VARV( 'ZPLNVER' ).
ATR_ZACTPER = ATRV( 'ZACTPER', VAR_ZPLNVER ).
* Get total to be distributed greater than actual period
KYF_TOTAL = 0.
FOREACH CHA_0FISCPER3.
IF CHA_0FISCPER3 > ATR_ZACTPER.
KYF_TOTAL = KYF_TOTAL + {0AMOUNT,CHA_0FISCPER3,VAR_ZPLNVER}.
ENDIF.
ENDFOR.
Tip 10: "Reference Data"
If you set a local variable for a characteristic using TMVL, ATRV, or

ATRVT and use this variable in a reference data operand (right side
of formula), then the system ignores any restrictions for this
characteristic when reading the reference data from the database.
This can lead to performance problems. Check the BI statistics for

long database selection for reference data.
Try to use the new syntax for reference data in operands:

{key figure, field 1, field 2, …, field n | ref. field 1 = value 1, ref. field 2 =
value 2, …, ref. field m = value m}
Tip 10: Example
{ Company, Version }
* Company Business Case: Copy data

into a target version and each
DATA CHA_0COMPANY TYPE 0COMPANY.
company potentially has a
* Source version (attribute of company) different source version.
DATA ATR_SVERSION TYPE SVERSION.
* Target version (variable)
DATA VAR_TVERSION TYPE 0VERSION.

Source version is set via attribute
(ATRV) and then used in operand
* Get target version from variable to read reference data.
VAR_TVERSION = VARV( 'TVERSION' ). System will read ALL
versions since it can't know
which ones would be required!
* Copy data from source to target version
FOREACH CHA_0COMPANY.
ATR_SVERSION = ATRV( 'SVERSION', CHA_0COMPANY ).
{CHA_0COMPANY,VAR_TVERSION} = {CHA_0COMPANY,ATR_SVERSION} .
ENDFOR.
Tip 11: "Endless Loops"
Save the formula before testing! Otherwise you loose your work if
the program goes into an endless loop and you have to stop the
program.
To stop a modus after having programmed an "endless loop" (for

example a do loop without exit statement) go to transaction SM50
and choose Program/Mode Program Cancel.
Tip 12: "Performance Analysis"
Always do a performance analysis before you start optimizing.
Use various statistics to determine the cause of performance

issues:
BI Statistics (table RSDDSTAT_OLAP, event ids 15000 - 15999)
SQL Trace (transaction ST05)
ABAP Performance Trace (transaction SE30)
– Add planning function to planning sequence
– Save variant for planning sequence
– Run function RSPLSSE_PLSEQ_EXECUTE via SE30
(Note: Parameter I_VARIANT requires the technical name of the variant, which
can be found in table RSRPARAMETRIZA field PARAMNM)
Workload Statistic (transaction STAD)
Key Learnings
Follow the steps on "how to design a planning function"
Use subsets to your advantage
Remember the tips for implementing and optimizing FOX

formulas
Always determine the root cause first before starting to optimize
Contact Information
Marc F. Bernard
Chief SAP NetWeaver Specialist
SAP NetWeaver RIG
SAP Labs, LLC

20 Perimeter Summit Boulevard
Atlanta, GA 30319
T 1.404.943.2725
F 1.404.943.4290
E marc.bernard@sap.com
Copyright 2007 SAP AG. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be
changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p,
System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are
trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C ®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies.
Data contained in this document serves informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form or for any purpose without the express prior
written permission of SAP AG.
This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments,
and functionalities of the SAP® product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. Please note that this
document is subject to change and may be changed by SAP at any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items
contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability,
fitness for a particular purpose, or non-infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This
limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in
these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages.

Tips and Tricks For

Î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

Tips and Tricks For

Încărcat de

Drepturi de autor:

Formate disponibile

Tips and Tricks for

General understanding of BI Integrated Planning in

Some experience with implementing formulas in BI Integrated

Learn about planning functions in BI Integrated Planning and how

Design formulas the right way

Understand how formulas are configured

Resolve performance problems or avoid them in the first place

Hear tips & tricks for implementing formulas

Designing Planning Functions

Performance Tuning of Formulas

Enterprise Reporting, Query and Analysis

BEx Query Designer

Business Planning & Analytical Services

Analytical Engine Planning Modeler

Enterprise Data Warehousing

Predefined Planning Function Types

Formulas define how the transaction data is to be processed in

In addition to different calculation functions, which you can use for

Create a formula if…

There is no predefined planning function type that does the job

The task cannot be done in one predefined planning function

The customizing of a standard planning function type gets to

Create a custom planning function type if…

Designing Planning Functions

Performance Tuning of Formulas

The following holds for EVERY planning function:

0PRODUCT 0FISCYEAR 0AMOUNT

0001 2007 100 Before

0PRODUCT 0FISCYEAR 0AMOUNT

0001 2007 100

To make it easier to configure planning functions, the systems

records: 0PRODUCT 0FISCYEAR 0AMOUNT

0001 2007 100

0001 2008 100

Fields to be changed Fields for grouping Number of calls/records

Data Selection (based on Filter)

Build Subsets from Selected Data

Phase 1 Reference Data (based on Function)

Add Subsets for Reference Data

Phase 2 Execute Function

Tips for Testing Planning Functions

Create filters for small packages of plan data (e.g. 2 records)

Create a test query for your filter

Execute the planning function using the trace ("execute with

In formulas you can send messages with the relevant values to

Designing Planning Functions

Performance Tuning of Formulas

3. Select the type Formula, enter technical name and

5. Select which fields should

6. Enter the conditions

{SEMPS_003, Mango Juice} = {SEMPS_003, Apple Juice} + {SEMPS_003,

7. For each condition, enter

Various forms of input help and

Control display showing

Syntax for formulas (FOX)

Among others a statement can contain…

Choose Check button in the editor to verify syntax of formula.

FOX = Formula Extensions

You can use the input help for

Note: In contrast to BW-BPS, for BI-Integrated Planning "key figure"

Reference Characteristics in Operands

Input Help for Operands with Reference Fields

You can pick additional