Logic Design & Troubleshooting inSAP Business Planning and Consolidation(4.x and 5.x)Craig BodingtonProduct SupportApril 21, 2008

AgendaUnderstanding logic in BPCLogic SyntaxTroubleshooting Logic

Understanding logic in BPC

TopicsThe types of logic used in BPCWhen is each type of logic usedHow and when is logic executedPros and Cons of each typeWho typically writes logic and when

Types of logic in BPCSpreadsheet LogicFormulas written in native ExcelFormula exists only in the spreadsheetsCreated and maintained within individual workbooks and worksheetsCan reference multiple ApplicationsDimension LogicFormulas written in member sheets in the FORMULAHx propertyCan be in any dimension but typically in the A{ccount} type dimensionThe executed formula exists in the analysis services cubesCreated and maintained through manage members process in BPC AdministrationSpecific to the applications the dimension resides in

Types of logic in BPCBusiness Rules (aka table based logic)Encrypted SQL Stored procedures that are shipped with the productWritten by product development and cannot be modified by usersParameters are defined in BPC Administration and then executed through scripting logicParameters are application specific but procedures are in all applicationsScripting logic (aka modeling logic, advanced logic, SQL logic)Proprietary language written for BPC by product developmentTwo forms of the language (SQL and MDX) that perform the same functionFormulas are stored in one or more script filesCreated and maintained through BPC AdministrationCan reference multiple applications but code resides in one application

When is each type used SAP 2007 / Page *Only used when same formula applies at all levels of the application. This is for performance reasons not an Analysis Services limitation.Calculations involving aggregated values are derived within the logic not referenced from the cube.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.

UsesSpreadsheet LogicDimension LogicBusiness RulesModeling LogicReporting ValuesYesYesYesYesCreating RecordsYesNoYesYesMoving DataYesNoYesYesCalculations on base recordsYesYes(1)YesYesCalculations on parent levelsYesYes(1)Yes(2)Yes(3)

When is each type of logic usedSpreadsheet logicReportingFor 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/ForecastingLimit 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 logicIn SQL 2005 the general recommendation is not to use dimension logic.ONLY used when the same rule applies at all levelsCan 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 usedBusiness RulesUse 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 calculationsRunSummarize Performs addition and subtraction on accounts based on a formula property in the dimensionRUNCalcAccount Performs a straight summarization of a group of accountsRUNCopyOpening Summarizes a group of activity accounts and copies the value into an opening balance accountRUNFX Performs standard currency translation.RUNAutoElim Performs intercompany eliminations.Script logicUse 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 executedSpreadsheet LogicExecutes 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 databaseDimension LogicExecutes 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 only exist virtually in the AS cube.Values are always based on the data in the cube when the query is executed by ASBusiness RulesExecuted 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 executedScripting LogicCan 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 logicSpreadsheet LogicProsSimple.its ExcelOnly limited to what you can do in Excel.ConsFormulas only execute when the spreadsheet is opened.Can end up re-implementing Excel-hell.Logic is contained in individual workbook files.Dimension formulasProsUses standard MS-MDXExecutes at query time so data is always currentFormulas are centrally stored and maintainedConsCan have significant performance impact.Can become very complex if multiple hierarchies existIf 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 logicBusiness RulesProsCode is centrally stored and parameters are maintained by the application administratorExecution can be setup to run on-demand or automaticallyTypically fastest execution because it works in the relational database using SQL Server memoryConsIf product development hasnt written it, it cannot be done with BRStored procedures cannot be customized to fit unique client needs.Rules tables are not well documented and can be difficult to understand

Pros and Cons of each type of logicScript LogicProsSQL logic executes fast.Code is specific to customer needs and can be created as needed.Scripts are centrally stored and maintained by application administratorsCode 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.ConsMDX logic can be very slowProprietary 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 whenSpreadsheet logicImplementation consultants, application administrators, report writers, end users, just about any system user.During entire life cycle of systemDimension LogicImplementation consultants, application administratorsTypically during implementation but can be modified anytime reporting requirements change.Business RulesImplementation consultants, application administratorsTypically during implementation but can be modified anytime business processes change.Script LogicImplementation consultants (normally write), application administrators (modify)Typically during implementation but can be modified anytime business processes change.

Logic Syntax

TopicsLogic overviewDimension LogicScope of ExecutionBusiness RulesRunAllocationRunSummarizeRunCalcAccountScripting Logic

Logic OverviewSpreadsheet logicSIMPLE..its Excel.Uses normal Excel cell formulasCalculated values are written to the database by normal update functions: EVDRE, EVSEN, EVSNDDimension LogicSIMPLE (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 OverviewBusiness RulesUnderlying 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 OverviewScripting LogicNOT simple.but not too hard once you get use to it.Proprietary language for scripting calculations in BPC.Two forms of the syntaxMDX (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 processingMDX form queries the AS cube to generate the initial record setSQL 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 SyntaxIts all about the Solve OrderMDX 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 SyntaxMDX formulas are used two places in the applicationCalculated 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 orderParent 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 references the SignedData values performs sign-flips. Has a solve order of 3.MTD, 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 ExecutionIts all about the SCOPEIn 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 OfficeIn 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 ExecutionExecution from Data ManagerThe 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-calculatedThe 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 ExecutionFor example, lets assume that the user has entered data for six cells in the cube.The corresponding records could be the following:In this case, BPC for Excel will pass a selection containing the category ACTUAL, the timeperiods 2007.JAN and 2007.FEB, the products PRODUCTA1 and PRODUCTA2,the currency LC, and the entity SALESITALY.

CATEGORYTIMEENTITYCURRENCYACCOUNTPRODUCTPERIODICACTUAL2007.JANSALESITALYLCUNITSPRODUCTA112,345 ACTUAL2007.JANSALESITALYLCINPUTPRICEPRODUCTA1100 ACTUAL2007.FEBSALESITALYLCUNITSPRODUCTA154,321 ACTUAL2007.FEBSALESITALYLCINPUTPRICEPRODUCTA1200 ACTUAL2007.FEBSALESITALYLCUNITSPRODUCTA26,789 ACTUAL2007.FEBSALESITALYLCINPUTPRICEPRODUCTA2300

Scope of ExecutionThe 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} =

*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 ExecutionExample:*XDIM_GETMEMBERSET EMPLOYEE=[EMPLOYEE].[CY_NEWHIRES].Children*XDIM_MEMBERSET HRCOSTELEMENT=NO_ELEMENT*XDIM_MEMBERSET TIME=2008.INP*CRITERIA [COSTCAT].[LOGIC_FLAG]1*ENDXDIMExplanationWe will search the children of CY_Newhires in the employee dimensionWhere HRCOSTELEMENT is equal to NO_ELEMENTAnd TIME is equal to 2008.INPTo find which CY_Newhire children have a value 1 in account Logic Flag.*Note CostCat is a TYPE A account dimension

Scope of ExecutionA simple example would be to hard code a member:*XDIM_Memberset Datasrc = InputOr just as simple, we could hard code muliple members:*XDIM_Memberset COSTCAT = PTO_DAYS,FLOAT_HOLIDAYS,STAN_DAYS,FIXED_HOLIDAYSExpand 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 ExecutionHow 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 - RunAllocationAllocation Engine Table Components*RunAllocation initiates the allocationDimensions to include in the allocation*DIM AccountDimensions not defined in the allocation will default to scoping.What Base member to be allocatedsupports multiple members WHERE=AccountA,AccountBWhere 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]="ExistingUsing (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 ignoredNumerical values such as 2 What x 2Using What is multiplied by Using. Total column is ignored.Using/Total What is multiplied by Using/Total1/COUNT Divided evenly among 1/count of where members

Business Rules Syntax - RunAllocationExample 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 AccountWHAT=SALES; WHERE=

Business Rules Syntax - RunAllocationExample 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 AccountWHAT=SALES; WHERE=

Business Rules Syntax - RunSummarize

Business Rules Syntax - RunCalcAccountCalculation Rule Name - The name of the ruleNOTE: 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 Rule Description - The rule description.Source MonthBlank: the current monthNon-blank: the month where to read the value to process. It can be an absolute or a relative amount Source YearBlank: the current year Non-blank: the year where to read the value to process. It can be an absolute or a relative amount

Business Rules Syntax - RunCalcAccountCalculations Table FieldsApply to YTD - In a PERIODIC application if this checked, the YTD value will be used in the calculationInvert Sign - If checked, the value of the amount is reversed.Account - The source ACCOUNTSource Account Member - The source DATASRC memberSource Subtable Member - The source subtable memberDestination Account - The destination ACCOUNT. If left blank, the value equals AccountDestination 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 SyntaxLogic can be broken down into 5 types of commandsScoping commandsBody/Code What do I want to do with the scoped records?*WHEN Statements*REC statements*GET statements*FOR loopsWriting the records to the fact table*COMMITPerformance commands*XDIM_NOSCAN*XDIM_MAXMEMBERSSpecial 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} is what to test. Typically, its a property of the current member of a dimension. DimensionName.PropertyExample: *WHEN ACCOUNT.RATETYPEThe default property is ID *WHEN ACCOUNT.ID is the same as *WHEN ACCOUNT{ValidCondition} Example 1:*IS "AVG","ENDExample 2:*IS 10,20,30If no operator is specified, the *IS clause assumes the presence of an equal sign (*IS = AVG, END).*IS > 2, *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 SyntaxFactor means to multiply the value of the current record by some value.*REC(FACTOR=1)Signeddata x1*REC(FACTOR=-1)Signeddata x -1*REC(FACTOR=1/12)Signeddata/12*REC(FACTOR=(2+3))Signeddata x5Expression 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 {Dimension name} = {Members Set}Example: *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 SyntaxLOOKUP 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 ]*ENDLOOKUPWhere:{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*ENDLOOKUPIn 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 SyntaxMemory 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 SyntaxMoving 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

TopicsSpreadsheet logic troubleshootingDimension logic troubleshootingTable based logic troubleshootingScripting logic troubleshooting

Spreadsheet logic troubleshootingTypically not coding issues. Remember.its just ExcelBe 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 troubleshootingIts probably solve orderIf 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 troubleshootingSuppose 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 isIIF(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 troubleshootingMost 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 troubleshootingIts probably a scoping issueThe 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.2If 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 troubleshooting4.x and 5.xIf 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 folderCheck 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 locationsGet 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 troubleshootingSpreadsheet logic troubleshootingDimension logic troubleshootingTable based logic troubleshootingScripting logic troubleshooting

Additional ReferencesDimension logic (MDX)MDX Solutions comprehensive MDX syntax reference http://www.amazon.com/MDX-Solutions-Microsoft-Analysis-Services/dp/0471400467BPC Script LogicThe on-line help document provided with BPC is available from the Administration client.Select Using script logic > Rules keyword reference

SAP 2007 / Page *Questions

SAP 2007 / Page *Copyright 2007 SAP AGAll rights reservedNo 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.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge 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 and associated logos displayed 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. 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. 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 pagesWeitergabe und Vervielfltigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrckliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen knnen ohne vorherige Ankndigung gendert werden.Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte knnen Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind.SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwhnte SAP-Produkte und Services sowie die dazugehrigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Lndern weltweit. Alle anderen in diesem Dokument erwhnten Namen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte knnen lnderspezifische Unterschiede aufweisen. Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderen Vereinbarung mit SAP. Dieses Dokument enthlt nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP-Produkts und ist fr SAP nicht bindend, einen bestimmten Geschftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP bernimmt keine Verantwortung fr Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht die Richtigkeit oder Vollstndigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewhr, weder ausdrcklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschlielich, hinsichtlich der Gewhrleistung der Marktgngigkeit und der Eignung fr einen bestimmten Zweck sowie fr die Gewhrleistung der Nichtverletzung geltenden Rechts.SAP bernimmt keine Haftung fr Schden jeglicher Art, einschlielich und ohne Einschrnkung fr direkte, spezielle, indirekte oder Folgeschden im Zusammenhang mit der Verwendung dieser Unterlagen. Diese Einschrnkung gilt nicht bei Vorsatz oder grober Fahrlssigkeit.Die gesetzliche Haftung bei Personenschden oder die Produkthaftung bleibt unberhrt. Die Informationen, auf die Sie mglicherweise ber die in diesem Material enthaltenen Hotlinks zugreifen, unterliegen nicht dem Einfluss von SAP, und SAP untersttzt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewhrleistungen oder Zusagen ber Internetseiten Dritter ab.Alle Rechte vorbehalten.