A colleague of mine once told me, “People make a plan only to change it in the future.” I just smiled when I heard it, but it is true. As we all know, the situations and assumptions (e.g., economic environment, available resources) on which we base our plans and forecasts definitely change. That is the main reason to do a rolling forecast, which is a type of planning based on the facts currently available. The corporate planner revises the plan based on actual numbers that have changed since the planner initially prepared the plan. The numbers are, for example, actual revenue and expenses, exchange rates, interest rates, or economic growth rate.

A Problem During a Rolling Forecast

Rolling forecast reports need to retrieve plan and actual data together. For example, if you do a rolling forecast for May, you need the actual data from the beginning of the year to April and the forecasting data from May to the period for which you are planning. When corporate planners use SEM-BCS actual data for the past period, while making a rolling forecast, they face a reporting issue on actual data in planning InfoProvider. That is because the SAP planning InfoProvider (SAP NetWeaver Business Warehouse Integrated Planning [BW-IP] or SAP Strategic Enterprise Management-Business Planning and Simulation [SEM-BPS]) doesn’t have any function retrieving the right elimination entry properly based on consolidation group, posting level, consolidation unit, and trading partner. SEM-BCS is a consolidation tool that has a reporting engine (i.e., a function module attached to the reporting virtual infoprovider) that reads a consolidation group hierarchy, entity, and trading partner information to retrieve the right data for intercompany elimination entries by consolidation group, but neither BW-IP nor SEM-BPS has a reporting engine that can retrieve the right InterCompany transaction balances.

Some companies also use SEM-BCS as a reporting tool for rolling forecast data. They import planning data to SEM-BCS and run consolidation functions at the end of the forecasting process. However, it is very hard to accommodate the process because rolling forecast data needs to be imported into the SEM-BCS system and go through the complete consolidation process to have the right reporting results whenever there are any data changes and updates on intercompany transactions. Even though you use this approach for your rolling forecast, you still have the reporting problem in the planning InfoProvider while you are working on forecasting until you copy the forecast data to SEM-BCS and go through the whole consolidation process.

SAP SEM-BCS uses a unique method for the consolidation reporting based on a consolidation group, a posting level, a consolidation unit, and trading partner information. Let’s assume that you have a consolidation group hierarchy (Figure 1) in which consolidation group AAA is the top node and consolidation units B and C are assigned to consolidation group BBB. The consolidation units X and Y are assigned to consolidation group XXX.  

Figure 1

Consolidation group hierarchy

Consolidation unit B has the balance of account receivable $1,000 with consolidation unit C and $2,000 with consolidation unit Y. After you execute the elimination task using the consolidation monitor of SEM-BCS, the data listed in Table 1 is generated in the SAP SEM-BCS total InfoProvider. (Note: the data doesn’t appear in the SEM-BCS reporting InfoProvider.)

Table 1

Data in the SAP SEM-BCS total InfoProvider

If a user executes a Business Explorer (BEx) query for the consolidation group BBB on an SAP SEM-BCS virtual InfoProvider or MultiCube scenario, the report shows the data as in Table 2. As you see, there are two differences from the data in the total InfoProvider (Table 1).

Table 2

Reporting through a virtual InfoProvider for consolidation group BBB

The SEM-BCS virtual InfoProvider generates consolidation group BBB using a function module program that generates consolidation group based on ownership structure and consolidation group hierarchy. The fourth line of Table 1 disappears because it is the elimination entry between consolidation units B and Y. Unit Y is a consolidation unit under consolidation group XXX. That means it is a third-party company from the perspective of consolidation unit B and should not be eliminated in the consolidation group BBB.

Issues on Reporting on Plan Data and SEM-BCS Actual Together

If a user executes a BEx query on a normal planning InfoProvider (a transactional or a real-time InfoProvider) that doesn’t have a service (the function module program that the SAP SEM-BCS virtual reporting InfoProvider has) within it, the report shows the data as in Table 3. This query shows all data that the InfoProvider has (Table 1) without considering the consolidation group of the data.

Table 3

Report on a planning InfoProvider without any solution

Therefore, if you don’t have a solution for this reporting issue, you see the variances between the actual data in the planning report and the actual data in the SAP SEM-BCS report (see the numbers in bold type).

Companies that have implemented SEM-BCS and BW-IP or SEM-BPS often try to use workarounds to deal with the issue related to the elimination entry records (posting level 20). For instance, corporate planners copy actual data only with posting level 0, 01, 10, and treat all intercompany transactions like the transaction with third-party companies, or they copy data multiple times by consolidation group and do planning processes parallel by consolidation group.

Posting Level in SAP SEM-BCS

Table 4 explains the terminology of posting levels in SEM-BCS to help you understand the solution better. A posting level is a two-digit number classifying journal/automatic entries in the SEM-BCS system.

Table 4

Posting levels in SEM-BCS

The Solution

All elimination entries related to transactions with subsidiaries outside a specific consolidation group must be excluded from the report for the group. The lack of the appropriate capability to report SEM-BCS elimination data in BW-IP and SEM-BPS makes variances between actual SEM-BCS report and planning report for the period in which BW-IP or SEM-BPS has actual data from SEM-BCS. This is mainly due to PL 20 data in SEM-BCS. PL 20 data are generated in SEM-BCS, while SEM-BCS eliminates intercompany transactions among subsidiaries. The SEM-BCS system handles PL 20 data with a virtual InfoProvider with a service (or a SEM-BCS MultiCube reporting scenario). The SEM-BCS virtual InfoProvider contains the logic required to report PL 20 data, but neither BW-IP nor SEM-BPS has any such capability.

Note
Running reports on top of an SEM-BCS reporting InfoProvider that stores data extracted from SEM-BCS through a virtual InfoProvider stores data physically in the InfoProvider instead of generating data on the fly as a virtual InfoProvider does.

To address this challenge, you can use a restricted key figure with user exit variables. You can emulate the standard SEM-BCS reporting logic in a SAP NetWeaver BW query or report on a planning (transactional or real-time) InfoProvider.

You can build the solution with the following steps:

Step 1. Create a variable for consolidation group (manual input type variable). This variable retrieves any data with consolidation group (PL 30 data) based on user selection criteria. This is a normal BW characteristic variable.

Step 2. Create a BW exit variable for # (i.e., blank or an unassigned value in the BW InfoProvider) consolidation group. This variable adds the # (blank or not assigned) value to the consolidation group variable to retrieve the data with PLs 00, 01, 10, and 20, which doesn’t have consolidation group information in the SEM-BCS total InfoProvider. If users don’t mind inputting # into the consolidation group variable (you created this in step 1) whenever they execute the report, you don’t need to create this exit variable.

Step 3. Create restricted key figure 1. This key figure selects all PLs 00, 01, 10, and 30 data excluding the PL 20 data. This key figure is used in step 6.

Step 4. Create user exit variable for the trading partner (hierarchy). This variable is used in restricted key figure 2 (step 5). This gets the same consolidation group value as the user input to the variable that you created above step 1 for the trading partner company hierarchy. Refer to the example of code at the end of this document.

Step 5. Create restricted key figure 2. This key figure selects the data with PL 20, which has the trading partner companies restricted by the user exit variable for the trading partner (step 4).

Step 6. Create a calculated key figure. This key figure calculates the sum of restricted key figure 1 and restricted key figure 2. This calculated key figure is the last output of this solution, which is used for reports built on the planning InfoProvider.

Benefit of the Solution

The biggest challenge related to building this solution is finding people who have expertise in SAP planning, consolidation, and SAP NetWeaver BW. Another challenge I found in the project is a lack of effective communication between the planning and the consolidation departments.

Because of these challenges, most companies end up copying only unconsolidated actual data with PL 0 and 10 from SEM-BCS, copying data multiple times using the trading partner restriction, or storing them separately by consolidation group and running forecasting process multiple times. These alternatives cause data redundancy or reporting results that are insufficient or wrong.

Table 5 shows which solution has right reporting values and whether multiple planning procedures are required.

Table 5

Comparison of alternatives

 (O = Reports show the right value. X = Reports show wrong consolidation group records [PL 20 data] that should not show up.)

Using the solution provides right reporting results for the top of the house and specific consolidation group without running multiple planning processes by consolidation group.

Companies can have many benefits from this solution because it makes their planning processes run more smoothly and in a timelier manner:

• Without bringing planning data into SEM-BCS, you can report on rolling forecast data that contains the actual consolidated SEM-BCS data and planning data together in planning InfoProvider. Some companies import planning data to SEM-BCS and run consolidation functions at the end of the planning process, but it is very hard to accommodate the process since planning data needs to be imported into the SEM-BCS system and go through the complete consolidation process to have the right reporting results whenever there are any data changes and updates on intercompany transactions.
• Actual data in the planning reports matches with data on SEM-BCS reports for all consolidation groups.
• Better performance than the reports using the SEM-BCS virtual InfoProvider and the MultiCube scenario because the solution doesn’t execute any program and uses fewer numbers of records comparing to the data in SEM-BCS reporting InfoProvider.
• This solution can also be used for reporting on the top of the total InfoProvider, which provides you with better reporting performance and nearly the same reporting result as the virtual InfoProvider provides, except for missing consolidation group value for PL 0-20 data.
• No multiple planning processes by consolidation group.

Reporting Output with the Solution

If users execute a BEx query on the normal planning cube with this proposed solution, it shows the data like in Table 6. Note that this query doesn’t show the fourth line that you saw in Table 3. Because the trading partner company Y is not under the same consolidation group BBB, the solution excludes the record from the report.

Table 6

Report on the planning InfoProvider with the solution

Figure 2 shows the report on the planning InfoProvider without any solution.  

Figure 2

Retrieved data without the solution

Figure 3 shows the reports with this proposed solution.

Figure 3

Retrieved data with the solution

The report in Figure 2 shows all elimination postings (PL 20) with all trading partners. In the report, the balances of the PL 0 and PL 20 data are exactly matched.

All other companies with PL 20 (from line 50 to 68) in Figure 2 except for 2030, 2032, 2035, 2060, 2061, and 2062 are not the members of the SEG group in this example then all of them are excluded from the report in Figure 3 by the solution.

Figure 3 shows the report with the solution. This solution enables a BEx report to retrieve only the elimination entries with the trading partners under the same consolidation group (SEG in this example) input to the variable by a user. It is the same result that a SEM-BCS report has. Compare the PL 20 data in the red box with the data in Figure 2.

Figure 4 is the example of the exit variable.

Figure 4

ABAP code example for exit variable