SAP Strategic Enterprise Management-Business Consolidation System (SEM-BCS) and SAP Enterprise Controlling-Consolidation (EC-CS) have consolidations logic programmed into the reporting. In many cases, this logic allows you to obtain consolidated results dynamically for almost any consolidation group.

Figure 1 shows the consolidation logic for reporting on consolidation of investments with SEM-BCS and SAP EC-CS. Although SEM-BCS is illustrated in Figure 1 with SAP NetWeaver BW InfoCubes, the logic applies to EC-CS as well.

Figure 1

SEM-BCS SAP NetWeaver BW reporting with SEM-BCS virtual InfoCube’s consolidation logic

 Here is a further explanation of the information presented in Figure 1:

1. A query is executed for the consolidated results of a specific consolidation group for a certain period of time. (A consolidation group is a related group of consolidation units for determining and reporting the consolidation results, and consolidation units are individual entities within the consolidation hierarchy and typically represent a legal company, profit center, segment, or business area.)
2. By reading the time-dependent consolidation group hierarchy, the system uses this logic to determine which consolidation units are included in the consolidation group for the period of time being queried.
3. Data is retrieved from the totals database for the consolidation units determined in step 2.
4. Eliminations (posting level 20) data is included only if both the consolidation unit and partner unit are included in the consolidation group being queried.
5. Additional logic reads the consolidation group master data and excludes the data for any consolidation units divested prior to the period of time being reported. The logic also reads the accounting technique and further excludes data for consolidation units assigned the accounting technique of equity.
6. The remaining totals records are included in the query output.

A consolidated group is not stored in the totals records, except for posting levels 02, 12, 22, and 30 entries. The fact that the consolidation group is not stored in most records is important for better understanding the dynamics of the reporting logic and that records with posting levels 02, 12, 22, and 30 may pose limitations to such reporting. The remaining data to be included in the report is thus determined dynamically.

The consolidation logic that allows the consolidation group to be determined dynamically provides flexibility, particularly related to restatement. Restatement in this case is when the historically reported results are revised because the consolidation group hierarchy was changed. In such restatement cases, the consolidation processes do not necessarily have to be re-executed, and it may be possible to simply re-execute the reports after the consolidation group hierarchy changes are made for the restated results.

Consider this example. You select consolidation group A (CG-A) in a given report for the actual data period 002/2010. From the consolidation configuration, the system consolidation logic determines which units make up the group as of 002/2010. The consolidation logic checks the period of the first consolidation or divestiture and determines that units A, B, and C make up the group at that point in time (Figure 2). All these units are accounted for on the purchase method. Therefore, the consolidation logic selects base data (i.e., posting level 00, 01, and 10 records) for these units.

Figure 2

An example of a consolidation group hierarchy

The group should include eliminations only among the three units making up the group, so the consolidation logic automatically selects elimination records only if both the unit and the partner unit are parts of the group (A, B, or C). A partner unit is a second consolidation unit that has a business relationship with a given consolidation unit. The reporting logic then automatically selects consolidation group records (posting level 30) specific to group consolidation group A. The results are automatically accumulated and reported.