SAP IP Tips and Tricks Implementing IP

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
Pattern Web Analyzer Web Application Designer Report Designer
BEx Analyzer
MS Excel Add-in
BEx Query Designer Business Planning Analytical Engine

OLAP services
Drill Down Currencies/Units Calculations/Formulas Exceptions/Conditions Variables Hierarchies Aggregation Sort
& Analytical Services Planning Modeler

Planning specific services
Enqueue Validations Data slices Characteristic relations
Planning Functions & Sequences

Distribute Formulas (FOX) Copy Revaluate Repost Forecast Custom defined
Focus for this webinar
Caching services
Plan data cache
Enterprise Data Warehousing

Operational Data Store
Architected Data Marts Data Warehouse Layer
Master Data
Various Business Requirements and Their Solutions

Distribute planned revenue to different products
Predefined Types of Planning Functions

Delete the data in one plan version
Copy data from actual version to 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 workdays in company calendar
Customer defined Type of Planning 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
Predefined Function Types
Formulas (FOX)
Customer Defined 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 0001 0002 0FISCYEAR 2007 2007 0AMOUNT 100 200
Before
0PRODUCT 0001 0001 0002 0002
0FISCYEAR 2007 2008 2007 2008
0AMOUNT 100 100 200 200
After
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 0001 0001 0002 0002 0FISCYEAR 2007 2008 2007 2008 0AMOUNT 100 100 200 200
Fields to be changed Empty Year Product All
Fields for grouping All Product Year Empty
Number of calls/records 4 calls, one record per call 2 calls, records (1+2) and (3+4) 2 calls, records (1+3) and (2+4) 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 Access Data Records
Information Retrieval (e.g. Variable Values)
String Operations
Formulas (FOX)
Call External Functions
Foreach and Do Loops Conditional Branching Programming Variables
Predefined Mathematical Functions
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
FOREACH <Variable> IN VARIABLE... ENDFOR
New Feature
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'
Fields to be changed: { Cost Element, Planning Item }
Parameter group: * Cash Discount = (Base Revenue - Price Adjustment) * 2% 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 Formula: = 0AMOUNT
Level contains more key figures than necessary
Restrict level/filter to formula selection: Cost Element Level/Filter: No restriction Formula: = '0000415001'
Level is not restricted on Cost Element but formula changes 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
Fields to be changed: { Material, Planning Item }
Parameter group (BEFORE): DATA M TYPE 0MATERIAL. {M,TOTALSALES} = 0. FOREACH M. {M,TOTALSALES} = {M,TOTALSALES} + {M,CUSTSALES}. ENDFOR.
If there are 1,000 materials, then TOTALSALES has to be read and updated 1,000 times
Parameter group (AFTER): DATA M TYPE 0MATERIAL. DATA TOTAL TYPE F. TOTAL = 0. FOREACH M. TOTAL = TOTAL + {M,CUSTSALES}. ENDFOR. {M,TOTALSALES} = TOTAL.
There's only one update of TOTALSALES independent of the number of materials
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
Fields to be changed: { Cost Element, Planning Item }
Parameter group (BEFORE): * Cash Discount = (Base Revenue - Price Adjustment) * 2% DATA C TYPE 0COSTELMNT. DATA P TYPE ZPLANITEM. FOREACH C,P. {0000415001,CASHDISC} = ( {0000400001,CUSTSALES} -
CASHDISC is updated inside the loop although it does not depend on C or P.
{0000410001,PRICADJDIS} + {0000405002,PRICADJBKT} ) * 0.02. ENDFOR.
The other operands are read inside the loop although they don't depend on C or P.
Parameter group (AFTER): {0000415001,CASHDISC} = ( {0000400001,CUSTSALES} -
{0000410001,PRICADJDIS} + {0000405002,PRICADJBKT} ) * 0.02.
Ultimately the complete Foreach loop can be 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
0PRODUCT 0001 0002 FOREACH product. FOREACH year. ... ENDFOR. ENDFOR. 0PRODUCT 0001 0001 0002 0002 0FISCYEAR 2010 2011 2010 2011 0AMOUNT 10 0 0 20 0PRODUCT 0001 0002 0FISCYEAR 2010 2011 0AMOUNT 10 20 FOREACH product, year. ENDFOR. 0FISCYEAR 2010 2011 0AMOUNT 10 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
Fields to be changed: { 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

Fields to be changed: { Company, Version }
* Company DATA CHA_0COMPANY TYPE 0COMPANY. * Source version (attribute of company) DATA ATR_SVERSION TYPE SVERSION. * Target version (variable) DATA VAR_TVERSION TYPE 0VERSION.
Business Case: Copy data into a target version and each company potentially has a different source version.
* Get target version from variable VAR_TVERSION = VARV( 'TVERSION' ).
* Copy data from source to target version FOREACH CHA_0COMPANY.
Source version is set via attribute (ATRV) and then used in operand to read reference data. System will read ALL versions since it can't know which ones would be required!
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.

SAP IP Tips and Tricks Implementing IP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP IP Tips and Tricks Implementing IP

Uploaded by

Copyright:

Available Formats

Tips and Tricks for Implementing and Optimizing Formulas in SAP NetWeaver BI Integrated Planning

SAP NetWeaver BI Architecture for Business Planning

BEx Query Designer Business Planning Analytical Engine

& Analytical Services Planning Modeler

Planning Functions & Sequences

Focus for this webinar

Plan data cache

Enterprise Data Warehousing

Architected Data Marts Data Warehouse Layer

Various Business Requirements and Their Solutions

Predefined Types of Planning Functions

Copy data from actual version to plan version

Increase the planned revenue by 10%

Convert from Euro to USD

Customer defined Type of Planning Function

Predefined Planning Function Types

Complexity vs. Functionality

Predefined Function Types

Customer Defined Function Types

Example for a Planning Function Business Scenario

0PRODUCT 0001 0001 0002 0002

0FISCYEAR 2007 2008 2007 2008

0AMOUNT 100 100 200 200

The plan data for each subset is processed separately

Planning Functions Subsets: Example

Fields to be changed Empty Year Product All

Fields for grouping All Product Year Empty

Flowchart for Planning Functions

Configuring Formulas 1/3

Configuring Formulas 2/3

6. Enter the conditions

Configuring Formulas 3/3

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

Control display showing which fields can be changed in the formula.

Formula Syntax Syntax for formulas (FOX)

Among others a statement can contain

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

Calculations Access Data Records

Information Retrieval (e.g. Variable Values)

Call External Functions

Foreach and Do Loops Conditional Branching Programming Variables

Predefined Mathematical Functions

FOX = Formula Extensions

Access to Data Records Operands

Access to Data Records Example Example

Access to Reference Data

Reference Characteristics in Operands

Access to Reference Data

Input Help for Operands with Reference Fields

Result of operand in editor:

Variables Local variables are

Global BI variables are

Loops General Looping

Predefined number of loops

Looping over Certain Values

Reference data values

Selection criteria (filter)

Loops Example Example

Conditional Branching Program Flow Based on Conditions

Single condition and others

Program Elements Program Elements

New Predefined Functions in Formulas

Replace a part of a value with another one

Determine length of a value