Skip to Content
Author's profile photo Former Member

SEM-BCS and IFRS – Part I

Translation, storage, and processing of this text in an electronic system is FOR EDUCATIONAL PURPOSES ONLY and is not a copyrighted edition.

Sources: Item 1, Item 2


In order for us to use consolidation function, we first need to set up a data model in the consolidation workbench. The data model is particularly relying on a data basis that in turn is based on applicable consolidation InfoCubes in BW and a consolidation area.

Data modeling plays in SEM-BCS a more important role than in EC-CS in which a data model of ECMCT2 was provided. SEM-BCS is based on BW (Business Information Warehouse) and allows for individual information needs be reflected in flexible data modeling. This flexibility allows a higher level of freedom, but also requires more attention to be paid to the specific data model design.

Data Storage

SEM-BCS is utilizing SAP Basis of version 6.3 and for data storage the generic platform of BW. The important difference between R/3 and BW based consolidation is not only different basis architecture, but also different data models: relational vs. multidimensional. The relational model is appropriate for quick write and transaction processing of large data volumes. It relies on two-dimensional tables (relations) with a fixed amount of columns and as many rows as needed. The advantage of multidimensional storage (OLAP) over the traditional technology is in quick read of large data volumes.

The underlying data model of BW is an extended star schema which in conjunction with OLAP processor allows for multidimensional access to relational data. Thus, each data query is optimized. The fact table contains the most disaggregated and granular (indicating) measures. The surrounding dimension tables contain characteristics according to which measures can be taken. Technically speaking, a dimension groups characteristics with each other up into a higher level according to a certain order. For example, characteristics are ordering groups like fiscal year, period, or item. They serve as classifications of the underlying data. Master data define allowed values which comprise characteristics, e.g. fiscal year 2009, 2010, 2011. Reporting entity data can thus be analyzed from different points of view. When displayed, multidimensional data gets converted in a report down to two dimensions.

Data Streams

It’s important to understand data streams between different architectural building blocks because BW is used for BCS, both and data storage and for preparation of consolidation data.  For each data stream there is one InfoProvider in BW. The latter can be either a physical InfoCube or a Virtual Provider or some other object. All terms are under one umbrella term of InfoProvider.

Data Store Objects

Data Store Object contains physically stored nonaggregated detail data from an upstream system. These detail data are a permanent basis for aggregated data in InfoCubes. In contrast to multidimensional storage of data in InfoCubes, data in Data Store Objects is stored in flat and transparent database tables. Data Store Objects allow incremental uploads as well as copying of data down to InfoCubes or other Data Store Objects.  The advantage of Data Store Objects lies in the ability of accessing the original source data without reloading it from the source system. Hence, the source data can be further processed before being loaded into an InfoCube.


InfoCubes are the central object of BW. They consist of a definite number of relational tables that are ordered like a cube and pull their data from InfoSources (logically grouped business data) and serve as the starting point for multidimensional analysis and reporting.

Data streams reference storage areas for consolidation movement data. Data can be read from any and written to any data stream. The data stream for totals records is the starting point for the data basis and consequently the data model. BCS is utilizing an InfoCube for the totals records. Movement data depicting the ending balances of accounts is stored in the designated InfoCubes. To allow adjusting journal entries another data stream needs to be created referencing a Data Store Object. The journal entry documents that are stored in them contain additional characteristics like journal number, user, description, and amounts to fulfill audit documentation requirements. Only new data sets can be added. For the end user it’s irrelevant whether the system is using InfoCubes or Data Store objects. As soon as a checkmark is set in the data basis for generation of data stream and subsequently saved the system will generate an InfoCube or a Data Store automatically.

Furthermore, data streams are required for additional financial data (AFD). AFD is required for detailed information gathered during consolidation entries that update account movements: e.g. investment or share capital ownership percentage. Those Data Store Objects are used by goodwill and investment accounting and reporting. In order to use AFD for quarterly result eliminations or for equity consolidations a separate data stream needs to be established. Each data stream is assigned to one InfoCube.

Data stream indicates also the system in which data is stored. The target system of a data stream does not necessarily have to be a BW object on the same server but can also be a remote system connected via an RFC (Remote Function Call).

In addition to the data streams used for documentation and additional financial data BCS requires data streams based on virtual InfoCubes for reporting. Such vitual InfoProvider reads consolidation totals data from an InfoCube and writes back new and changed data back into it. Virtual InfoCubes contain no data, but only selection logic and a connection to the real data stream, from which data is pulled. Also, those virtual cubes for reporting can be automatically generated since they have the same structure as the original objects.

Data Basis

Data Basis is the foundation of the data model of consolidation. This area when EC-CS and BCS are compared offers more flexibility in consolidation characteristics. The former had a fixed data model whereas the latter allows for customer specific data modeling and ultimate reporting.

Consolidation area

Within the data model we need to have the ability to apply specific accounting cutoff method which allows different accounting results depending on statutory requirements. This is accomplished through a consolidation area which shows portions of the data basis. Consolidation are allows exclusion or inclusion of individula data basis characteristics. By creating multiple consolidation areas we can combine different characteristics into groups. Those groups need to be unique. In order to comply with such standards as US GAAP or IFRS, a consolidation chart of accounts is fixed so that different charts are separate from each other. Tasks and methods are specific to a consolidation area as well.

In configuration of consolidation area the choice of characteristics and key figures is made for assigned roles again in the data basis and it is possible to provide further values for individual characteristics.

The clients are advised to implement Business Content provided by SAP and adjust it to their own individual requirements. Depending on the specifics of an enterprise additional configuration may be required. For creating customer content objects need to be created separately and they cannot overlap. Portions of basis content can however be copied.

Three-tier architecture of SEM

Data storage is the first-tier basis for this data warehousing solution. Data from different sources is gathered and stored in one data base before the next step of preparation and merging can be executed. BW is aware of the business background of data coming from different sources and contains relevant structures. BW allows valuation of data either from an operating R/3 or from any other upstream enterprise system. In addition, data from external sources like databases, online services, and internet can be extracted, transformed, and analyzed.

The application layer is the second tier and it is based on the OLAP processor. The processor allows for access to InfoCubes which is focused on observation of business relationships. Moreover, drill down to ODS objects, PSA and OLTP systems (R/3) occurs via the processor. This is how OLAP prepares large amounts of operating and historical data for analysis.

The third layer of BW architecture is manifested by business explorer and its reporting tools. The valuation of data stored in InfoCubes occurs in this presentation layer with the help of queries. A query is a comination of characteristics and key figures that provide a structure for definition of a request. Data is later presented via BeX or Web. From there, reporting is fast and comfortable.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.