Hi All,

In BPC 10.1 NW version , while we want to do an environment copy , the following problem will occur :

We do the copy in BPC Web client .During the processing we can see the copied environment is creating in backend system using T-code:RSA1.

After environment copied successfully in web side , the new environment is missing in backend system without any error message.

The root cause is that you assign the "SAP_ALL" profile to the BPC service user "BPC_SERVICE".

According to the installation guide , the "BPC_SERVICE" user should be assigned role "SAP_BPC_SERVICE".

So the solution is to remove the "SAP_ALL" profile from BPC service user "BPC_SERVICE".

Best regards,

Peter

Hi All,

You may meet error '500 - Server Error'  or 'Cannot find document/directory' while uploading document in BPC web side.

This problem only occurred by following actions:

1. BPC Web client -> Documents -> Add
2. Click [Browse] button
3. Select a file in file browser, click [Open]
4. Click [Browse] button again
5. Without doing anything -> click [Cancel] directly
6. Click [OK]
7. Enter name -> Click [OK]

Now it will be fixed in SP18 version.

Best regards,

Peter

I noticed that there were a lot questions and confusion about how to use parameter ENABLE_HANA_MDX in BPC. Here I would like to list some common questions and give my personal opinion.  You can refer to the full article as link below.

Open discussion on Parameter ENABLE_HANA_MDX in BPC 10.0/10.1

Hi All.

In EPM add-in there is function named "Activate Member Recognition" in Sheet Options.

After you activate the option , you can enter members directly in a cell of a report.

And for the same member in different dimensions , you can enter the member in a cell as: dimension name|dimension member name.

For example :

There are two dimensions named "A" and "B".

They have the same dimension member named "test".

So after activated the 'Member Recognition' option in EPM add-in client , you can enter the member as A|test or B|test  in a cell.

Best regards,

Peter

In order to test whether BW aggregation is used by BPC report, we set up a demo environment:

It includes following dimensions, and storage type is PERIODIC. 

Transaction data input through BPC Input Form, and BPC version is 10.0.

Case 1:

Step1: To build an aggregate on InfoCube with only one dimension in RSA1, here we use ACCOUNT, and scope is * which means for all members.

Step 2: Build a report in EPM Addin to query the data.

Result:

After refresh the report, we found the usage for the aggregate is still 0. Aggregate is not hit.

Case 2:

Step1: To build aggregate with all dimensions, and scope for member is * (all members included).

Step2: To refresh the report we used in case 1.

Result:

The usage for the aggregate increases after the query. Aggregate hit in this case.

Case 3:

Step1: Based on the aggregate used in case 2, we add a scope limit on hierarchy of ACCOUNT as node level equal 1.

Step2: To modify the report in EPM Addin to query the result of level 1 node in ACCOUNT hierarchy.

Result:

After refresh report, the usage is not changed. The aggregate is not hit in this case.

Case 4:

Step1: To remove one dimension for the aggregate used in case 2. For example we remove RPTCURRENCY.

Step2: To use the report used in case 2 and refresh.

Result:

The usage number is not changed. The aggregate is not hit.

Case 5

Step1: Based on the aggregate used in case 2, we add a limit on fixed member of TIME (= 2014.01).

Step2:

Build a report with ACCOUNT on row axis and TIME on column axis.

Set TIME to 2014.01, and test with difference choice of ACCOUNT dimension.

Result:

1. If we use base member on ACCOUNT dimension, the aggregate is hit.
2. If we use non-base member of ACCOUNT dimension, the aggregate is not hit.

Conclusion:

From previous tests we found it is necessary to include all dimensions in the aggregate. If you get rid of any dimension, BPC will not touch it. Setting member scope on dimension is okay, but not on hierarchy level.

This is the first part of a series that shows how you can write more powerful Script Logic for the BPC Netweaver version. We are about to embark on a quest through the thicket of BPC Script Logic so lean back and enjoy the ride. If you are completely uninitiated with Script Logic, I recommend reading BPC Script Logic for Dummies by James Lim and the help documentation first.

Background

It is well documented that the BPC Netweaver version features a limited set of Script Logic commands. Some keywords available in the Microsoft version such as FLD are not supported. As a result it has become common to use ABAP not only because of performance bottlenecks but also to work around these limitations. Sometimes ABAP has been applied even when Script Logic might have been a better choice for the task.

When Script Logic is used it is often written in a static fashion including a lot of hard-coded values. This kind of code is simple to create and easy to read. However, it also tends to be high-maintenance when things change (as they always do).

Incomplete and sometimes contradicting documentation seems to be a contributing factor to these trends. This series of articles is my attempt to help developers and business users to see the many possibilities Script Logic offers. There is much more than meets the eye at first blush. Before going to technical details let’s lay out the business case.

Business example

In our business example we want to read salary account values, calculate associated payroll charges and save the calculated values on separate accounts. In our example, the applicable percentage depends on the source AUDITID. Target ACCOUNT varies depending on the source ACCOUNT.

Source values to be read are stored with AUDITID dimension members PAYR01/PAYR02 and ACCOUNT dimension members PL5110,PL5111 / PL6110,PL6111. Calculation results should be saved using AUDITID member CALCRES and ACCOUNT members PL5119/PL6119. The table below summarizes our posting logic.

Let’s have a look at a simple script suitable for our business case. Later on, we will learn how it can be improved with minimum effort.

Simple Script

Script Logic is still often used in projects because it is easy to learn and it can be maintained by business users instead of IT specialists. Below you can find a simple Script Logic that meets our business case requirements. The keyword FACTOR is used in this example but you can easily enhance the script by using EXPRESSION instead.

*XDIM_MEMBERSET AUDITID = PAYR01, PAYR02
*XDIM_MEMBERSET ACCOUNT = PL5110, PL5111, PL6110, PL6111
*WHEN AUDITID
    *IS PAYR01
      *WHEN ACCOUNT
        *IS PL5110, PL5111
          *REC(FACTOR = 0.25, ACCOUNT = PL5119, AUDITID = CALCRES)
        *IS PL6110, PL6111
          *REC(FACTOR = 0.25, ACCOUNT = PL6119, AUDITID = CALCRES)
      *ENDWHEN
    *IS PAYR02
      *WHEN ACCOUNT
       *IS PL5110, PL5111
          *REC(FACTOR = 0.31, ACCOUNT = PL5119, AUDITID = CALCRES)
       *IS PL6110, PL6111
          *REC(FACTOR = 0.31, ACCOUNT = PL6119, AUDITID = CALCRES)
      *ENDWHEN
*ENDWHEN

Some remarks

There is nothing inherently wrong writing script this way especially when only a few static operations are needed. However, adding new members and more complicated conditions might require numerous nested WHEN statements. As time passes and the system evolves, a statically written script tends to become longer and longer. Lack of forethought during the design phase can make the system difficult to maintain and even prone to errors.

In the second part of this series, I will show step by step how easy it is to improve this sample script.

Member formula is widely used in BPC environment, but many customers facing the same challenge when running queries with aggregation on member formulas, the calculation result is incorrect. For example in following table, the correct result should be 0.2, but query result usually displayed as 0.5:

This is a BPC production limitation at the moment, which is unable to handle exception aggregation on member formula for transient queries, and this can’t be handled in BW side alone either, as BW BEX query is unable to recognize the difference between member formula rows and normal rows.

The solution below is to combine both BPC member formula and BW exception aggregation methodology to handle this challenge for reporting.

1. Scenario

Here is account type, account hierarchy setup from BPC side:

R100T and its children nodes R101 and R102 are ratio nodes, which are calculated from T101, T201 etc.

2. Member formula

R101 and R102 are member formula to calculate ratio. Besides the member formula on children nodes, also design accordingly member formula on parent node level (R100T = T100T/T200T).

3. Add “PERIODIC” as restricted key figure, and create “Formula 1” which is actually “PERIODIC”,

4. Set the Exception Aggregation on “Formula 1”as “No aggregation along hierarchy”.

5. Create “Formula 2” with following logic:

‘Formula 1’ + ( ‘Formula 1’ == 0 ) * ‘Periodic’

This formula is used to check the value for “Formula 1”, if “Formula 1” has a value (not empty),  then (“Formula 1” == 0) will return false value, which is 0, it’s going to use the value from “Formula 1”.  If “Formula 1” is empty ( because no aggregation on hierarchy for the exception aggregation),  then (“Formula 1” == 0) will return true value, which is 1, the value from “Periodic” will used for the final result.

6. Use standard aggregation on “Formula 2”(no exception aggregation)

7. Run the BEX query,you will find the R100T aggregation on:

“Periodic” is 0.7 (incorrect), which is a result of 0.2(number calculated from member formula in BPC) + 0.5 (aggregation result from BW, 0.1 +0.4) “Formula 1” on R100T is correct, 0.2(number calculated from member formula in BPC), but it’s empty for T100T, T200T, because we set exception aggregation on BW ( No aggregation on hierarchy).“Formula 2” is correct for all aggregation nodes, because we used formula in BEX query.(if “Formula 1” is empty, take the value from original aggregation value from “Periodic”.

8. Now hide the key figures “Periodic” and “Formula 1”,

The query result will look like below, correct aggregation numbers will be displayed for all nodes:

Above is just an example for hierarchy with periodic, similar method could be used for YTD/QTD calculations like:

Feedback:

If you have any comments, questions or feedback, please kindly send an e-mail to:

George Yang (ge.yang@sap.com)

Freeter Xie (freeter.xie@sap.com)

Alex Shen (yang.shen@sap.com)

Dynamic scripting

In this second part of the series, we will go through methods which can make your script way more dynamic. These methods are well documented for the most part. Hard-coding is acceptable at times but statically written script can easily turn into “write-only” spaghetti which is difficult to maintain.

In many cases, it is enough to modify a script only slightly to make it much more flexible. Using dimension properties is my favorite way of bringing order to an otherwise chaotic environment. The most valuable benefit you gain by using properties instead of hard-coded member values is that any new AUDITID or ACCOUNT (or whatever dimension) members will be automatically handled correctly. This can make a huge difference when changes are frequent and schedules are tight.

It may sound paradoxical, but adding a little bit of complexity early on can make things a lot simpler down the road. Proper design during the implementation phase eliminates the need for technical expert involvement during day to day operations. Having autonomy and control over the system allows the business to make changes independently. Time and again clients have emphasized how important it is to retain ownership of THEIR solution. Flexible maintenance is one of BPC’s key strengths and where it truly shines out.

The following table shows how the dimension members should be maintained to support a dynamic script suitable for our purposes. In this case, we have added a custom property SRCTYPE for both AUDITID and ACCOUNT dimensions. We have also added a custom property TRGTACCT for the ACCOUNT dimension. A new account INCPERC has been created. These preparations are necessary to make our solution more flexible. Exactly how they are used will be explained shortly.

Now that we have maintained all the dimension members, we can improve the script easily. Our first step is to replace the hard-coded scoping with dynamic member selections. The following example shows how to do this. We use the names %AUDITSRC% and %ACCOUNTSRC% to temporarily store our selection of source AUDITID and ACCOUNT members.

  *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
  *SELECT(%ACCOUNTSRC%, ID, ACCOUNT, SRCTYPE= PAYR)
  *XDIM_MEMBERSET AUDITID = %AUDITSRC%
  *XDIM_MEMBERSET ACCOUNT = %ACCOUNTSRC%

The above statements make our scoping of data dynamic but we still need hard-coded values to handle different percentage rates and target accounts. Generally speaking, percentages and other values should not be hard-coded. A simple way to avoid this is to store the necessary values as transaction data. That is the reason we created the INCPERC account. We use this account to enter the two percentage values used in our calculations. We only need one account as the percentages are associated with the AUDITID’s. So our preparations should include entering the correct percentages for the relevant AUDITID’s.

In the Microsoft version, the keyword GET could be used to retrieve the stored values. In the Netweaver version we use the tuple syntax instead. Our second step is to replace the hard-coded percentage values with references to values stored in the database. The script below shows how this can be done using the tuple syntax.

   *REC(FACTOR = [ACCOUNT].[INCPERC], ACCOUNT = PL5119, AUDITID = CALCRES)

We only specify the account here which implies that the percentages are stored with the same level of detail as our data entry. This is done to keep our business case simple. In practice, percentages are usually entered at a much higher level so that a single value is used by all profit centers, for all periods of the year etc. So the tuple part of a real-life script would include more dimensions. Percentage values are typically entered centrally at the beginning of the planning cycle. Entry may also be decentralized and the timing can vary depending on the process requirements.

Our third and final step is to replace the static target account with a dynamic statement. In this example, we use ACCOUNT property TRGTACCT to determine the posting account. AUDITID can remain hard-coded because it never changes in our example.

  *REC(FACTOR = [ACCOUNT].[INCPERC], ACCOUNT = ACCOUNT.TRGTACCT, AUDITID = CALCRES)

The script shown below wraps it all up. You will notice that this dynamic script is much shorter than the original static version. More importantly, this script will not need to be changed when ACCOUNT and AUDITID members are updated. It is compatible with driver-based planning and it can cover many scenarios that would not be feasible with hard-coded values.

*SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
*SELECT(%ACCOUNTSRC%, ID, ACCOUNT, SRCTYPE= PAYR)
*XDIM_MEMBERSET AUDITID = %AUDITSRC%
*XDIM_MEMBERSET ACCOUNT = %ACCOUNTSRC%  
*WHEN AUDITID
      *IS *
      *REC(FACTOR = [ACCOUNT].[INCPERC], ACCOUNT = ACCOUNT.TRGTACCT, AUDITID = CALCRES)
*ENDWHEN

Sometimes you might want to use a LOOKUP instead of a tuple. This is the case when the driver values are stored in a separate model or if you require more flexible use of properties in your rules. Here’s an example how you can use a lookup in your REC statement.

     *REC(FACTOR = LOOKUP(LINCPERC), ACCOUNT = ACCOUNT.TRGTACCT, AUDITID = CALCRES)

If you want to select accounts using hierarchy nodes instead of property values you can use a script like the one below. In this example, PL5000 is the hierarchy node you want to select. Keyword BAS is used to determine the base level members under PLNODE. I prefer properties because they allow more flexibility than a hierarchy selection but it all depends on your needs and setup.

*SELECT(%ACCOUNTSRC%, ID, ACCOUNT, ID = PL5000)
*XDIM_MEMBERSET ACCOUNT = BAS(%ACCOUNTSRC%)

The story so far

Script Logic is readily accessible to and easily understood by most business users. Using Script Logic instead of ABAP means that the solution can continue to be owned by the business with minimum IT expert involvement.

We have already seen how easy it is to write dynamic script that requires few if any changes when accounts or other members are added. In the third part of this series we will delve deeper and learn how to harness the immense power of Script Logic variables.

In the second part of this series we saw simple yet effective techniques to write dynamic Script Logic. However, some requirements are not easily met. One of the most commonly cited topics is the (lacking) ability to use property values for calculations in a REC statement. I don’t recommend using property values in calculations but I will show you how this can be accomplished. I haven’t seen this method published anywhere else. I believe it is novel to all readers except for a few who are privy to intel not available to mere mortals.

Using variables in Script Logic

Let’s cover some related topics in more detail to put the solution in context. Handling of variables in Script Logic is different from many other programming languages. Some variable operations are non-obvious or entirely out of scope. Official documentation on variable usage in the Netweaver version is patchy and sometimes out of date. The following overview is my attempt to explain how the system handles variables. Please note that MDX variables are not covered in this article.

A great way to introduce variable values into your script is to use Data Manager (DM) variables also known as Dynamic Parameters. Values are based on user prompts or they can be constants. It is worth noting that for your Script Logic all DM variables behave as constants because the assigned values cannot be changed. DM variables can be recognized by the dollar signs around them such as $INCPERC1$. There is a good How to paper explaining how to pass DM variable values to Script Logic so I will skip the details. In our business example, we could prompt the user to provide a percentage and then use this value in the script as follows.

    *REC(FACTOR = $INCPERC1$, ACCOUNT = PL5119, AUDITID = CALCRES)

There are two other types of variables that I have found particularly useful. Both are usually written with percentage signs around them such as %ACCSEL%. Use of $ and % signs is optional in some cases, but I find they make the script easier to read so I use the notation consistently. We already saw the first type of variable in action when we wrote our SELECT statement. In the example below, %AUDITSRC% is a variable which contains the selection specified by the condition.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)

SELECT statement is used for data scoping, but it can also be used for other purposes. There are three interesting features that make the statement very versatile. 1) in most cases, the system treats variables without paying too much attention to data type; 2) in many cases the system interprets a variable value as a text string; 3) put together these two features enable concatenation which is nice because string manipulation is otherwise not possible. This allows us to accomplish many things that might seem unattainable.

Now we are ready to see how property values can be used in Script Logic calculations. Suppose we have the necessary percentages maintained in AUDITID property INCPERC. In the Microsoft version this is accomplished using the FLD statement as follows.

*REC(FACTOR = FLD(AUDITID.INCPERC))

We cannot use FLD in the Netweaver version as it is not supported. Luckily, we can work around this. Let’s have a closer look at the SELECT statement.

  *SELECT(%INCPERC%, ID, AUDITID, ID = PAYR01)

The statement above selects AUDITID dimension member PAYR01 and stores the ID PAYR01 to our variable %INCPERC%. But we don’t want the ID but the numeric value stored in INCPERC. All we need to do is to alter the statement slightly.

  *SELECT(%INCPERC%, INCPERC, AUDITID, ID = PAYR01)

The statement above selects AUDITID dimension member PAYR01 as before, retrieves the property INCPERC value and stores the retrieved numeric value in our variable %INCPERC%. Now that we have captured the percentage value we can use it in our calculation.

The property itself allows basically any value as the data type is CHAR (character). The system does not control how the properties are maintained. Script Logic accepts our text string variable value and REC statement treats it as a number. It is the up to the key user to make sure that only numeric values are entered to avoid errors. The example script below works because the system allows us to take liberties when it comes to data types.

*REC(FACTOR = %INCPERC%, ACCOUNT = ACCOUNT.TRGTACCT, AUDITID = CALCRES)

Hey presto, we have successfully used a property value in our REC calculation. This is all very nice but we only captured one value. If you want to read values from multiple members, you could simply add a variable for each of your AUDITID’s. However, that is not flexible and dynamic enough for most purposes. So let’s see how we can enhance the method.

At this stage, I would like to remind you about the nature of the select statement. As its name implies it is used for selection and it can store multiple values. If you are familiar with SAP ERP or ABAP it might be helpful to think in terms of SETs, SELECT-OPTIONs or RANGEs. To select multiple values, we can define a dynamic selection such as the example below. Please note that both variables will contain the same number of values because we use the same selection condition in both statements. As already mentioned above, the key user is responsible for maintaining valid property values.

   *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
   *SELECT(%INCPERC%, INCPERC, AUDITID, SRCTYPE= PAYR)

Now that our variables contain multiple values we need one more thing to use those values. It is time to introduce the third type of variable and the FOR-NEXT loop construct. See below for complete script example.

  *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
  *SELECT(%INCPERC%, INCPERC, AUDITID, SRCTYPE= PAYR)
  *SELECT(%ACCOUNTSRC%, ID, ACCOUNT, SRCTYPE= PAYR) 
  *XDIM_MEMBERSET AUDITID = %AUDITSRC%
  *XDIM_MEMBERSET ACCOUNT = %ACCOUNTSRC%

  *FOR %AUDITLOOP% = %AUDITSRC% AND %INCLOOP% = %INCPERC%
  *WHEN AUDITID
     *IS %AUDITLOOP%
     *REC(FACTOR = %INCLOOP%, ACCOUNT = ACCOUNT.TRGTACCT, AUDITID = CALCRES)
  *ENDWHEN
  *NEXT

We use two variables %AUDITLOOP% and %INCLOOP% in the FOR-NEXT loop and our SELECT statements guarantee that they contain the same number of entries. Netweaver help documentation implies that only one variable is supported with FOR-NEXT loops. This seems to be a documentation glitch and I consider it safe to use two variables. Again, this is really neat but the method works only if you need just one variable value per data record. If you need more variables the best way is to use tuple expressions. The tuple method was described earlier in this article and it is the recommended tool for the job.

In the fourth part of this series, you will get a glimpse of some of the most elusive SELECT statement features.

Hello Experts,

We are getting error message saying "Currency is not available in CONSOLIDATION Application" on executing the carry forward package with currency as <ALL>.

If we run the package with single currency or with individually selecting multiple currency it is working fine.

Below is the script logic:

*RUN_PROGRAM COPYOPENING
CATEGORY = %CATEGORY_SET%
CURRENCY = %RPT_CURRENCY_SET%
ENTITY = %ENTITY_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM

We have recently upgraded the BW system  from 7.0 to 7.4 and finding this issue after the upgrade.Could please anyone help in this.

I have debugged the standard class "CL_UJP_COPYOPENING->READ CURRENCY()" and looks like when we pass <ALL> as currency it is not reading all the base members instead it is passing as <ALL> only. As <ALL> is not part of the master data ,it is giving the exception saying "Currency is not available".

Regards

Pratibha

Hello Experts,

We are getting error message saying "Currency is not available in CONSOLIDATION Application" on executing the carry forward package with currency as <ALL>.

If we run the package with single currency or with individually selecting multiple currency it is working fine.

Below is the script logic:

*RUN_PROGRAM COPYOPENING
CATEGORY = %CATEGORY_SET%
CURRENCY = %RPT_CURRENCY_SET%
ENTITY = %ENTITY_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM

We have recently upgraded the BW system  from 7.0 to 7.4 and finding this issue after the upgrade.Could please anyone help in this.

I have debugged the standard class "CL_UJP_COPYOPENING->READ CURRENCY()" and looks like when we pass <ALL> as currency it is not reading all the base members instead it is passing as <ALL> only. As <ALL> is not part of the master data ,it is giving the exception saying "Currency is not available".

Regards

Pratibha

In this fourth part of the series we will unravel the mystery surrounding the SELECT statement.

Additional useful information

Unfortunately, some parts of the help documentation are out of date. Many functional enhancements are not properly covered. Incomplete and confusing documentation makes it difficult to see the possibilities offered by Script Logic. Admittedly, most improvements have been documented in the Notes which can be found at SAP Marketplace but locating the information can be difficult. Sometimes different sources contain contradicting statements. I have collected updated information and added my personal findings about the statements covered in this article. If in doubt, please check the official SAP documentation to ascertain the support status of any features you plan to use.

Syntax of the SELECT statement

Throughout this article I have written SELECT statements without brackets or quotation marks such as below.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE = PAYR)

Most Script Logic examples use a more complex syntax. See the statement below for comparison.

    *SELECT(%AUDITSRC%, "[ID]", AUDITID, "[SRCTYPE] = 'PAYR'")

I find the version with fewer special characters more readable and it seems to work exactly the same way. It is also much easier to write. If there are many conditions, quotation marks might improve readability. Anyway, the system doesn’t seem to care either way so it’s your call.

Variables with the SELECT statement

Although it’s not easy to find documentation, the SELECT statement does allow the use of variables. Both DM variables (the ones with $ signs around them) and % variables can be used. Let’s have a look at a pair of SELECT statements we used before.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
    *SELECT(%INCPERC%, INCPERC, AUDITID, SRCTYPE= PAYR)

This could be rewritten as follows.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR)
    *SELECT(%INCPERC%, INCPERC, AUDITID, ID = %AUDITSRC%)

Keyword AND with the SELECT statement

According to the help documentation the SELECT statement does not support multiple selection criteria using AND or OR keywords. Documentation is in need of an update as keyword AND is supported. The statement below is an example of a valid SELECT statement with multiple criteria.

    *SELECT(%AUDITSRC%, ID, AUDITID, IS_CONSOL = Y AND IS_CONVERTED = Y AND CALC = N)

Operators with the SELECT statement

According to the help documentation only operators = and <> can be used with the SELECT statement. Again, the documentation does not list the many enhancements. In fact, the SELECT statement supports comparisons with the following operators: =, <>, <, >, <=, >=. For example, the following statement can be used to select AUDITID’s with property SRCTYPE values PAYR01 to PAYR10 with the exception of member ID “BONUS”.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE >= PAYR01 AND SCRCTYPE <= PAYR10 AND ID <> BONUS)

Logical OR with the SELECT statement

The system also allows something akin to logical OR as it accepts multiple values in the condition. The statement below dynamically selects AUDITID members where property SRCTYPE is equal to PAYR or MANUF. This is not quite the same as the keyword OR but it is better than advertised for in the help documentation.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE= PAYR, MANUF)

A word of caution is warranted. The following statement behaves exactly the same way as the one above. I find this is counterintuitive as I would expect no members to be selected in this case.

    *SELECT(%AUDITSRC%, ID, AUDITID, SRCTYPE = PAYR AND SRCTYPE = MANUF)

Naturally, you can also use the keywords XDIM_ADDMEMBERSET and XDIM_FILTER to fine-tune your selection. Here’s an example. This is one of the few cases where the system requires quotation marks.

    *XDIM_FILTER ENTITY = [AUDITID].properties("SRCTYPE") = PAYR

I have experienced problems with XDIM_FILTER but these would probably be fixed by applying the relevant correction notes. In any case, I prefer using SELECT statement variables whenever possible and I have had little use for XDIM_FILTER.

In the fifth part of this series, we will set the record straight as far as XDIM_MEMBERSET is concerned.

Sometimes, you raised an incident to SAP, but soon issue is solved finally by applying a BPC note(The one can be applied by snote). You may wonder how I can find the right BPC note for my issue. If you have experience of searching notes, you may have a feeling that there are so many notes searched out, which note is the correct one or most likely correct one to apply.  Let me introduce some tips of searching BPC note.

Where is the note searching?

1. Open https://support.sap.com/notes and click button "Launch the SAP Note and KBA search ".

How to search note effectively?
1. Define the application scope(also called component). If you search BPC NW note, input EPM-BPC-NW*(Be noted there is wild char). Otherwise, you will get many non-BPC notes.

2.Limit the component as much as you can. If you know exactly what the issue is, such as the currency conversion issue, limit the component by extending the component to EPM-BPC-NW-TDL-CT.

3. Use the keyword to filter the BPC version.  If you are using BPC NW 10.0, put 800 or 801 in the Search Term. You can also use 10.0, but highly recommend using 800 or 801, which gets more accurate result.

4. Sort the note number in the descending order.  Normally, the notes are listed in Ranking order, but to search a BPC note,  recommend using note number descending order to display.

• Default order by Ranking.

• Click Number header twice to display note in descending order.

Well, which note should I apply?

1. Check the support package information. Open the 1st note and at the bottom of the page, you will find support package information. Take note 2122890 as the example, it's delivered in 800 SP17 and 801 SP10. If your BPC version is lower than 800 SP17 or 801 SP10, technically, you can apply this note on your system in most cases. (However, sometimes the note can only be applied from certain SP to certain SP. If your BPC is our of the scope, the note cannot be applied).

2. The note can be applied, but the symptom is not the same. Should I apply?

The symptom may not be the same as yours, but still recommend applying them, because the code fix delivered in the note may impact other functions/parts.

3. Still got many notes. Should I open each of them and check the support information one by one. The answer is NO. So HOW? Pick up one note in the middle. Open it and see if the note can be applied. If YES, open the next note, of which the note number is bigger(No need to open the next one. You can jump to two or three), until you find one note(e.g. Note123456) that cannot be applied. Then all the notes larger than note 123456 can be applied on your system. If the answer of the beginning is NO, open the previous note, the smaller one.

Is there any other way to find the note?

Yes. That is the central note. If you are using BPC 10.0 SP14 and the latest is SP16, open central note SP15 and SP16.  You can find what note fixes are delivered in this SP. If your BPC is quite old, e.g. SP10, well you have to take more time to check each central notes.

In the central note, sometimes there are almost 100 note fixes. You may don't want to check one by one.  You can use search function in the browser by pressing Ctrl + F. Then search the keyword, e.g. currency. Then all the notes related to currency will be highlighted with color.

Some other keywords I often use:

• SQE,MDXfor report display issue, e.g. error, wrong result, etc.
• Slow, Performancefor performance issue
• HANA for HANA related issue.

But there is limitation here. The central note only will be released when the SP is ready, which means you can download SP installation package from SMP. Before the central note is released, almost all of the notes in the central notes are already released. As a result of this, you cannot find the note through the central note way.

This fifth part in the series “How to write dynamic BPC Script Logic” has relatively few earth shattering jolts but the tension is building up below the surface as we continue our journey to uncharted territory.

XDIM_MEMBERSET with keyword BAS and more

In general, help documentation is fairly accurate when it comes to XDIM_MEMBERSET. However, there are more valid use cases than the help documentation describes. Below you can find some examples most of which are properly documented.

Scope selection can contain multiple members.
   *XDIM_MEMBERSET P_ACCT = PL5111, PL5112, PL2111

XDIM_MEMBERSET can be combined with BAS to set the scope to base members of a hierarchy node.
   *XDIM_MEMBERSET P_ACCT = BAS(PL5000)

Keyword BAS can digest multiple members to set the scope to base members of several hierarchy nodes.
   *XDIM_MEMBERSET P_ACCT = BAS(PL5100, PL5200)

Keyword DEP can be used to select direct children of a hierarchy node.
   *XDIM_MEMBERSET P_ACCT = DEP(PL5110)

Keyword ALL can be used to select all children of a hierarchy node.
   *XDIM_MEMBERSET P_ACCT = ALL(PL5100)

Not equal to sign can be used to exclude a member.
   *XDIM_MEMBERSET P_ACCT <> PL5111

Not equal to sign can be combined with BAS to exclude base members of a hierarchy node.
   *XDIM_MEMBERSET P_ACCT <> BAS(PL5300)

The help documentation specifies that you cannot combine bas() with any other member set. This does not seem to be true as the following statement works.

   *XDIM_MEMBERS ACCOUNT = BAS(PL3000), PL5111

It is worth pointing out that any duplicate base members resulting from BAS will be automatically removed. The following statement exemplifies how this works. Let’s assume that PL3100 is a child of PL3000. In this case, retrieving base members of both PL3100 and PL3000 would result in overlapping sets. However, the system only lists a single occurrence of each account if you use a script like the one below.

   *XDIM_MEMBERS ACCOUNT = BAS(PL3000, PL3100)

There is one more thing I want to mention as it is not specified in the documentation. Keyword BAS also accepts base level members in addition to calculated members. The example below will return base level members belonging to the hierarchy node PL3000 plus the base level member PL5111.

   *XDIM_MEMBERS ACCOUNT = BAS(PL3000, PL5111)

In the above examples, you may also use variables instead of fixed member values and I recommend you do. Let’s see how we can use the SELECT statement to pick up base members of a given hierarchy node. This is not possible directly, but you can combine SELECT variables with XDIM_MEMBERSET, XDIM_ADDMEMBERSET, XDIM_FILTER and WHEN. The example below gives an idea how to use BAS with a SELECT variable. Here we set the scope for base members under the calculated member PL3000.

    *SELECT(%ACCOUNTSRC%, ID, ACCOUNT, ID = PL3000) 
    *XDIM_MEMBERSET ACCOUNT = BAS(%ACCOUNTSRC%)

In the sixth and final part of this series, we will see that the keyword IS has similar dynamic capabilities and then some. I will also show more examples of variable usage. Some of the things I am about to reveal are Wikileaks magnitude so stay tuned.

When using EPM Add-in as the report tool for BPC NW version, the http compression can be used to reduce the network transfer time and improve the overall performance for reports.

This setting is very useful for the big reports with lots of records, and it is also helpful for the user accessing system with VPN.

1.When to check this setting?

To catch the http request by Fiddler, and check whether much time is spent on the network.

Network time = ServerDoneResponse – ServerBeginResponse (roughly estimation)

ServerBeginResponse - Exact time that Fiddler got the first bytes of the server's HTTP response.

ServerDoneResponse - Exact time that Fiddler got the last bytes of the server's HTTP response.

In following example, it is 17.262 sec (total is 24.972), and seems most of the time is on network transmission.

2. To check the content is compressed or not

Click on the request got in Fiddler, and select “Inspectors” in right panel.

Click the RAW button for the http response (lower part).

If you can’t find “content-encoding: gzip”, it means the content is not compressed when it is sent from server to fiddler.

Sample without compression

Sample with compression

3. Compression can be used or not

There are some preconditions to use this compression:

• The protocol should be http 1.1.
• Clients can decode gzip content. (check it in the request head)

4. How to set it

1. Logon BW server, and type T-code: SICF,   and select “ALIAS” as shown below.

2. Expand the node “default_host”, and double click “/sap/bpc”.

3. Set parameter “Compression” to “YES” and save.

5. Other setting

• Profile parameter ict/disable_compression: You can use this profile parameter to deactivate the compression of an instance. The standard value of this parameter is FALSE.
• Profile parameter ict/min_compression_size: This profile parameter specifies the data volume (in bytes) from which a compression should be performed. The standard value of this parameter is 1024.
• Profile parameter ict/exclude_compression specifies a negative list to specify which type of files you don't want to compress.

This is the final part of my six-part series “How to write dynamic BPC Script Logic”. I am sure you will find a few ideas you haven’t seen before.

Behold the myriad possibilities offered by keywords WHEN and IS

Help documentation states that IS supports only literals, not variables. The following statement is given as an example of un-supported usage.

    *IS dimension.property

The documentation seems to be out of date as properties can be used. For example, the following construction using property SRCACCT works.

  *WHEN ACCOUNT
     *IS AUDITID.SRCACCT

The following example also works. The only caveat with this pattern is that an empty property value may lead to unexpected errors.

*WHEN ENTITY.CMETHOD
   *IS INTERCO.CMETHOD

I have also used other types of variables with keyword IS. Let’s assume, we want to check if AUDITID property CHK01 equals ACCOUNT property “X” Property “X” in this case is not constant but it is a variable the value of which depends on the CATEGORY. Sounds complicated and it is if we have to hard-code all possible combinations in advance.

The following script shows how to apply concatenation referred to earlier in this article. In this case, %CATSEL% contains a single base level CATEGORY member. Now we can compare AUDITID property CHK01 value against ACCOUNT property %CATCOL% value.

*SELECT (%CATCOL%, COLSEL, CATEGORY, ID = %CATSEL%)
*WHEN AUDITID.CHK01
     *IS ACCOUNT.%CATCOL%

The same works with the IS statement or even if both parts (WHEN / IS) have a variable property.

  *SELECT (%CATCOL%, COLSEL, CATEGORY, ID = %CATSEL%)
  *WHEN ACCOUNT.%CATCOL%
     *IS AUDITID.CHK01

There can be syntax errors when you save but the script works anyhow. I suggest some caution when pushing the system to extremes but probably we are not quite there yet. I will save the most shocking stuff until a bit later.

Keyword IS can also be accompanied by the following operators: <, >, <=, >=. Logical keywords AND and OR are not supported so the following example will not work.

  *WHEN AUDITID.SRCTYPE
    *IS >= PAYR01 AND <= PAYR10

However, this is easy to work around as shown below.

*WHEN AUDITID.SRCTYPE
   *IS >= PAYR01
     *WHEN AUDITID.SRCTYPE
      *IS <= PAYR10

Keyword WHEN allows us to create conditions using member ID or property values. A nice addition to the arsenal is the addition of using the parent as a condition. This allows us to check the immediate parent of a member.

*WHEN ACCOUNT.PARENTH1
    *IS SALARIES

If you need to create a condition for all base members of a hierarchy node you can use keyword BAS.

  *WHEN ACCOUNT
     *IS BAS(PL5000)

If you need to exclude those base members you can use the following format.

  *WHEN ACCOUNT
     *IS <> BAS(PL5000)
   // Some calculation here
   *ENDWHEN

If you find it easier to use only positive statement the following example has the same effect.

*WHEN ACCOUNT
   *IS BAS(PL5000)
    // Do nothing
   *IS SOMEOTHERCONDITION
     // Some calculation here
*ENDWHEN

Help documentation states that you can only pass a single value when the unequal sign (<>) is used. I have used multiple values such as the examples below. So the documentation seems to be out of date.

*WHEN ACCOUNT
   *IS <> PL5111, PL5112, PL5211, PL5212

*WHEN ACCOUNT
   *IS <> BAS(PL5100,PL5200)

Documentation about wild card usage is not entirely consistent so I will explain my findings here. Asterisk works with the IS statement. The following condition is true for any ACCOUNT number. So the statement can be used when you don’t want to apply any condition for your REC statement.

*WHEN ACCOUNT
   *IS *

Unfortunately, wildcard can’t be combined with a partial string to check for patterns. The following statements do NOT work.

*WHEN ACCOUNT
   *IS PL2*

*WHEN ACCOUNT
   *IS PL2?2?

Wildcard does not appear to work with the WHEN statement. The following expression which can be found in some documents does NOT work. I don’t consider this to be a real loss.

*WHEN *
   *IS *

Write back statements can include variables

Help documentation is silent about using variables with write back statements. In fact, you can construct very dynamic write back statements using variables. Below you can find some elementary examples with variable values. Variables can be used either directly in calculations or as selection conditions to retrieve the relevant values.

The first pattern you have seen in this article many times.

  *REC(EXPRESSION = %VALUE% * %INCPERC%)

The second pattern is also very useful. In the following example, we calculate a time-based ratio. The result is saved on a separate evaluation view dimension member.

*REC(EXPRESSION = %VALUE% / ([TIME].[%PREVYRSEL%]), EVALVIEW = PREVYRCOMP)

Conditions based on transaction figures

Our business case didn’t require if-then conditions based on the transaction data but the topic is very closely related. For example, you might want to apply a different interest rate depending on the account balance. This is where ternary expressions come in handy. The help documentation doesn’t provide any information, so I will write a few lines. There are also many good posts at the SAP Community Network. I would like to give special credit to Vadim Kalinin who has written some of the most instructive posts on this important topic.

Ternary expressions can be used when you need to apply Boolean logic. Boolean logic is simply an if-then statement. It consist of three parts. The first part is the condition. You can also think of it as the question asked. The second part is the outcome if the condition is met (logical true). The third part is the outcome if the condition is not met (logical false). The syntax is as follows.

  A > B ? C : D

In the above example, A > B ? is the question asked or the condition. If A is greater than B, the value will be C. In the opposite case, the value will be D. A common application is to reclassify receivables and payables based on the account balances. The following script can be used to reclassify credit balance receivable accounts.

*WHEN ACCOUNT
  *IS *
    *REC(EXPRESSION = %VALUE% < 0 ? %VALUE% * -1 : 0, DATASRC = RECL)
    *REC(EXPRESSION = %VALUE% < 0 ? %VALUE% : 0, ACCOUNT =   ACCOUNT.RECLASS, DATASRC = RECL)
*ENDWHEN

Ternary expressions support the following comparison operators: >, <, >=, <=, ==

Final remarks

I hope that this article has raised your awareness and that it helps to see that Script Logic can do much more than it is usually given credit for. Once you start thinking about ways to make your script more dynamic you are bound to find many uses for these techniques. If you feel uncertain about SAP service coverage, it is advisable to stick to features explicitly specified in the documentation provided by SAP. So if in doubt, please check the help documentation and your system specific Notes at SAP Marketplace to be on the safe side.

Oh, I almost forgot the truly wicked thing I promised. Here it comes, so be forewarned. Gloves are off, no narration this time, just code.

*SELECT (%COOLVAR%, COOLCOL, CATEGORY, ID = %CATSEL%)
*WHEN ACCOUNT
    *IS *
      *REC(FACTOR=1, %COOLVAR%)
*ENDWHEN

Cool, eh? How do you like this one?

*SELECT (%COOLVAR%, COOLCOL, CATEGORY, ID = %CATSEL%)
*WHEN ACCOUNT
  *IS *
   %COOLVAR%
*ENDWHEN

If that wasn’t enough, check out the following monstrosity.

%COOLVAR1%
%COOLVAR2%
%COOLVAR3%
%COOLVAR4%

Ineffable! Well, maybe not quite. But that should give you enough food for thought to cause severe cerebral indigestion.

Hi friends it has been observed that we are not able to override the page axis with multi members by using cell reference. Below is the sample VBA code to achieve the same.

Sample requirements:

1. Dimension:  Costcenter_test ---> Page axis cell ” B1”
2. Dimension: Profitcenter--> Row axis
3. Dimension: Time--> Column axis

Assuming cell “C3” already have the dimension members separated by commas

Ex: 10101008, 10101009, 10101010

Before:

ALT + F11   “ open the VBA editor”

Insert >>new module

sample code is available in APPENDIX

After macro code is run, the default report  page axis  formula has been inserted with multi members.

please note that here we are explicitly refreshing the report through macro to recognize the newly inserted formula in the page axis.

As per the business requirement you can call the macro  through function BEFORE_REFRESH in this case it is not required to refresh the report explicitly

and the code "EPM.RefreshActiveSheet"  can be removed/commented

if we double click on the costcenter_test dimension in cell "B1" then we would be able to see the olapmultiplemembers that were recognized.

this means page axis has been override with multi members.

I am beginner in VBA , please provide your valuable comments or suggestions..

Thanks,

Dinesh.V

APPENDIX

**********************************Start*****************************************************************************************************

Sub pageaxis()

Dim ARY() As String

Dim i As Integer

Dim comm As String

comm = Range("C3").Value     'CELL C3 contains dimension members seperated by commas

Set R1 = Range("B1")         ' cell B1 would be pageaxis of dimension Time

Dim EPM As New FPMXLClient.EPMAddInAutomation

ARY = Split(Range("C3"), ",")   ' splitting the dimension members in cell and passing to array

Final = "=EPMOlapMultiMember(""" & comm & """,""000"""     ' formulae  for defult report (i.e "000")

For i = LBound(ARY) To UBound(ARY)

Final = Final & "," & """" & "[COSTCENTER_TEST].[PARENTH1].[" & ARY(i) & "]" & """"

Next i

Final = Final & ")"

ThisWorkbook.Worksheets("Sheet2").Range("B1").Formula = Final     ' copying the final olapMultimember formula to page axis

EPM.RefreshActiveSheet ' refreshing the report

End Sub

**********************************End*****************************************************************************************************

Hello Everyone,

Continuation to previous blog: Master data loading from flat file (http://scn.sap.com/docs/DOC-63482), writing another blog on the same data loading topic, but this is not about loading about flat file. This is about the loading from info provider.

The main purpose of this blog is pulling data into BPC from the rates data which is available in the BW side

Here I am using the delta initialization package to pull the data from BW to BPC.

Assumptions:

1. The data is already available in the BW info provider
2. Dimensions required for rates model are already created, and model is also available in BPC web admin.
3. The connection is already established.

Step 1:  Log on EPM add-in Excel.

Step 2: Create transformation file (please take a look in to how to load master data loading from flat file for how to create transformation file)

  This is sample transformation file

Next click on validate transformation file

Next click on save. We will see validation successful log like below..

Step3:  Create a delta initialization package.

1. Go to Data Manager Tab à organize à organize delta initialization

The below screen will appear when you complete the 3^rd step. Next right click on the screen and click one new.

It will pop up a screen like below and give the respective fields. How to fill those fields are also mention in the below image.

Next go to organize à organize package list à go to data management à add package --> /CPMB/LOAD_DELTA_IP

Add the above package.

Step 4: Running package

1. Next go to run package --> select the package which is created above --> click on run

It will ask for delta initialization file which is created in the step 3

Click on next, it will ask for whether we want run the default logic choose no

Click on next, it will ask whether we want check the work status or not, choose no

Next run and next view status.

Please feel free to add any new points / more points

Regards,

Saida Reddy G

Hello every one,

This blog briefly explain the differences  and similarities between classic and Unified models.

Classic version which for the people who are already using BPC 10.0 version

Consolidation central is available in classic model where as its not available in Unified version

Unified is fully integrated with integrated planning( this is deeply integrated with SAP BW)

For embedded version SAP HANA is mandatory where as for unified and classic models is an optional(not mandatory)

Theses are some key similarities and differences between those two...

Reporting differences between classic and unified models

Similarities and differences between SAP Planning and consolidation version for NW and Planning application kit

Please add any comments or few more points..

References : SAP service market place ramp-up material

Thank you ...

Regards,

SRG...

Scenario

Business users wanted to see the balance sheets and income statements based on some specific hierarchy which was not coming from ECC system. So, they decided that they will maintain 2 hierarchies out of which one will be loaded from ECC system and other will be custom maintained in BPC dimension administration. While creating the custom members in hierarchy, users faced several issues and error whose resolutions will be explained in this document.

Why multiple hierarchies

In most of the implementations, hierarchies for profit center, accounts, cost center usually come from ECC system. For example: In ECC, accounts are groups by their type and accordingly assets accounts fall under asset node, liabilities fall under liabilities node.

However, this will be used to create balance sheets and income statements very well. But let us say business is planning and they would like to see all the accounts in one group that are related to revenue/expenses generated/incurred in fleet. It could be on product basis, region basis or any other business function relate criteria. This way it becomes easier for business users to group accounts according to their convenience, which is different than the standard hierarchy.

Implementation of multiply hierarchy

Create a new hierarchy in structure of account dimension from BPC web administration page. For help on creating the alternate hierarchy please refer:

http://scn.sap.com/docs/DOC-56122

1. Unhandled Error: unmarshal.invalid.xml

Error detail:

This error is encountered when you try to delete the members in the hierarchy or sometimes when you try to change the members existing in the dimension.

Reason of this error:There is a dynamic table from which BPC pulls data whenever we request. In addition to this there are BW tables where actual BPC dimension data is stored in BW server. Whenever we delete the data from a dimension it sometimes reflects the data in BW table but the dynamic table is not refreshed. In this case we need to sync the BW table and dynamic BPC table.

Solution:  Solution for this error is a program: “UJA_REFRESH_DIM_CACHE”. This program will sync the dynamic table with the BW tables. After executing this program, reprocess the dimension and the error will be resolved.

2. Base member ‘XXXX’ cannot be a parent of ‘XXXX’ in PARENTHH1

In this case user was trying to create a H2 hierarchy members by suffixing ‘_H2’ to the members assigned in H2. However, user made a mistake in which he assigned the _H2 members to H1 hierarchy. This was a rule violation.

This error occurs when we break the rules of creating multiple hierarchy.

Rule says: If for example: Account “300000” rolls into “Q_50_H2” in H2 hierarchy then while creating “Q_50_H2” as a member, its parent should also be populated in H2 column and not in H1. If it’s in the H1 column then it will likely fail and throw this error.

This way if you create your hierarchy then it won’t fail.

Conclusion

Alternate/multiple hierarchies are very useful for finance users in order to see the reports according to their custom build hierarchies which are easily understood and closely relate to their day to day work. While creating these multiple hierarchies we just need to take care of the rule mentioned above and can be really beneficial for any customer.