Thought Leadership

How to: Create Conditional Logic in SAP BPC, version for NetWeaver

Posted by
Will Leonard
Will Leonard
on Tue, Apr 11, 2017 @ 09:04 AM

Applicable Releases:conditional logic.jpg

Software Component Version  Support Package       
  • CPMBPC 800 SP18+
  •  CPMBPC 801 SP11+
  •  CPMBPC 810 SP07+

1. Business Scenario

Business logic is often dependent on which process is being performed.  For example, during Budget season, an EPM application will execute one set of logic over many different time periods.  However, during a monthly Consolidation process, a different set of logic will be executed to prepare data for financial reporting.

Ideally, all business logic could run “on the fly” or indefault logic.  However, it would be detrimental to performance and data integrity if all logic ran for each individual process.  Instead, the system would need to determine which logic to run based on which process was being run.  In the past, this hasn’t been possible if there is any complexity to the logic at all.  Either the logic would have to be run in batches, or a custom BADI would have to be written to execute the correct logic depending on which process was being run.

Fortunately, SAP has provided an enhancement to script logic for BPC NW which enables different logic to run based on certain conditions.  The enhancement comes in the form of a new key word, and is explained in SAP Note 2146749 - New keyword *XDIM_SKIPNULLCHECK is introduced.  A PDF of this note can be found in the appendix.

For users of BPC MS, a solution to try is “Logic_By”, which is discussed on this page. Logic_By is not available on the NW platform. 

2. Explanation

The *XDIM_SKIPNULLCHECK key word works by checking whether the next *XDIM_MEMBERSET statements return a null value or not.  If the null condition is met, the *XDIM_SKIPNULLCHECK key word will skip any code below an *XDIM_MEMBERSET statement which returns a null value, all the way to the next *COMMIT statement. 

The practical way to force this condition is with a *SELECT statement.  Within a *SELECT statement multiple criteria can be used, and if all the conditions are met, the statement returns a valid dimension member or list of dimension members, which can then be passed into the scope of the logic script with an *XDIM_MEMBERSET statement.  However, if all the conditions are not met, the statement will return a null value.

Below, we will show an example of this by leveraging the CATEGORY dimension in *SELECT statements.

3. Setup

In our scenario, imagine that the Actual Consolidations logic should be performed by the system every time data is loaded from BW.  By contrast, Planning logic should be performed every time an input to the Budget or Forecast Categories is performed by a user.

In this case, the master data would look something like this:

Category Dimension














Note that the CATEGORY Dimension has a custom property called “RUNLOGIC”.  This will be used to create our conditional criteria within *SELECT statements as shown below. 

In Default logic, we need to call CONSOLIDATION.LGF for the Actual Consolidations logic.  For the Planning logic, we will call a custom BADI.

Individually, these two logic calls look like this:a-2.png


However, if left like the above, both calculations would run every time.  To run these conditionally, we must use *XDIM_SKIPNULLCHECK.

First, set up the *SELECT statements – one to check whether the Consolidations logic should be run, and one to check whether the Plan logic should be run.  Note that the ID cannot be used twice as criteria so the RUNLOGIC property is required.


  • The %CONSCAT% variable would return a null value whenever %CATEGORY_SET% is not ACTUAL
  • The %PLANCAT% variable would return a null value whenever %CATEGORY_SET% is not BUDGET or FORECAST

Next, use *XDIM_SKIPNULLCHECK, *XDIM_MEMBERSET and *COMMIT statements to set the conditions for when the logic should run:


Because of the above configuration, CONSOLIDATION.LGF will only run when ACTUAL records are submitted, and PLAN_LOGIC will only run when BUDGET or FORECAST records are submitted.

4. Other Considerations

One common issue with the *INCLUDE statement is that it will append the called logic script to the calling LGF at runtime.  Because of this, any *COMMIT statements in the included LGF will be considered by the XDIM_SKIPNULLCHECK key word.  Thus, the entire LGF is not always skipped as intended. 

There are two known workarounds to this issue:

  1.  Remove unnecessary *COMMIT statements in the included LGF file.  Since the *COMMIT statement only serves to reset the scope or place an endpoint for *XDIM_SKIPNULLCHECK in BPC NW script logic, *COMMIT statements can be replaced with *XDIM_MEMBERSET [DIM] = %[DIM]_SET% statements for any scope that needs to be reset.
  2. Implement RUNLOGIC_PH and call the LGF this way.  When a BADI such as RUNLOGIC_PH is called, any commit statements that are run within are not considered by the *XDIM_SKIPNULLCHECK key word so calling an LGF with RUNLOGIC_PH is a safe way to bypass this issue.  The How-To guide for RUNLOGIC_PH can be found here.

We are offering a 3-day hands-on workshop that covers BPC logic during our upcoming BPC Logic Boot Camp at the EMEA EPM Summit in June. Click the button below for more information!

bpc logic boot camp

More Content You Might Like:

 -The_EPM_add-in_enables_users_to_analyze_data_from_several_EPM_solutions_at_the_same_time._It_was_introduced_in_BPC_10_as_an_Add-in_for_Excel_PowerPoi.pngBuilding_a_Competent_BPC_Team.png SAP_BPC_Staffing_and_Support_Models.png

Will-Leonard.pngAuthor Bio:

Will Leonard has extensive experience in managing and implementing EPM, planning and consolidation solutions. His background in finance, accounting and planning & analysis complement his deep technical skill sets, and his focus on quality, process and end user experience highlight his proven track record.