Brief Comparision Between SAP SEM-BCS and SAP Businessobjects BPC

BPCThe SEM-BCS (Business Consolidation System) application is considered as one of the most structured and mature solution, offering a high level of automation for the consolidation process. From its first release in 2002 (for the BW based version), it has benefited from major enhancements and will still be supported until at least 2017.

However, the new leading consolidation solutions should now be SAP BusinessObjects Planning and Consolidation (BPC) and SAP BusinessObjects Financial Consolidation. These products are presented as core components of SAP long-term strategy and best-in-class solutions, capable of covering large organizations and complex consolidation requirements.

For my part, I have been working on the SEM-BCS solution for many years, and to be honest, it was quite difficult to accept that a new SAP consolidation solution could replace an existing efficient one. That is why I wanted through this document to draw an objective comparison between SEM-BCS and BPC on a few detailed consolidation features, and thus show what was the logic/added value of each application.


Topic SAP SEM-BCS SAP BusinessObjects BPC
Data model The SEM- BCS data model consists of characteristics,   key figures and data streams. It is customer-definable and benefits from the   BI multi-dimensional scheme.

Master data: when defining a data model, a   “role” must be assigned to each characteristic and key figure. Several roles   are required such as version, consolidation unit, consolidation group, item,   partner…

Most of the master data are stored and maintainable   in both the consolidation system and the BI system. They can be updated   manually, using “flexible upload” (flat file) or load from data stream (load   from individual infoobjects) methods. As in the BI system, one can define   hierarchies and attributes for both the configuration and the reporting.

The master data can be time and/or version-dependent   (corresponding options must be selected on the BI side).

The key concept in BCS regarding master data is the   “breakdown category”: it determines with which subassignments a given FS Item   can be posted. This concept enables to control data consistency when posting   in the basis.

Data streams: the solution is based on a   transactional infocube (defines the data basis and stores the totals   records), transactional DSOs (store documents and additional financial data)   and their corresponding virtual infoproviders (for reporting purpose).





Data storage: BCS always stores periodic   values, even if the process is performed in YTD.

The “posting level” characteristic classifies the   journal entries (00 for local data, 10 for local adjustments, 20 for I/U   eliminations…).

The consolidation group information is physically   written in the records for posting levels 02, 12, 22 (group changes) and 30   (top adjustments), and dynamically interpreted by the virtual cube for the   other ones.

A record can contain the three key figures (value in   local/ transaction/group currency).

The BPC model is also a customer-definable and   multi-dimensional model. Characteristics are called “dimensions”,   characteristic values “members” and infocubes “applications”.

Master data: a “type” must be assigned to   each dimension : A for Account, C for Category, E for Entity,… The “type”   is equivalent to the “role” in BCS.

For both versions (Microsoft and NW), the master   data are created and maintained in the BPC administration console. For the NW   version, the system automatically populates the objects on the BI side. The   master data maintenance is very user-friendly: it is possible to maintain the   members by a simple copy-paste in Excel. Dimension members can also be   presented using hierarchies.

The version and time dependency is only applicable   to the group structure (stored in the Ownership application).

The key concept in BPC regarding master data is the   dimension “property” (equivalent to the attribute in BI): it is often   required to define business rules and trigger consolidation calculations.

Data streams: a consolidation solution   requires at least three applications : a consolidation application (totals   records) that must reference an Ownership application (consolidation methods   and percentages of ownership) and a Rate application (exchange rates).   Generally, an additional application is designed for the Inter-unit   reconciliation. It is possible to copy the business content solution   (AppShell) or import a SAP starter kit to have a pre-configured solution and   reduce the time implementation.


Data storage: BPC can store the data in   periodic or YTD, but for consolidation it is in YTD.

Data storage is “flat” (no virtual reporting logic):   each record can store only one “measure” (key figure) and as soon as an entry   is “group dependent”, it is duplicated as many times as needed.

The concept of “posting level” doesn’t exist: the   classification of journal entries is made with the Datasource (journal) and   Group dimensions.

Consolidation monitor The SEM-BCS consolidation monitor provides a graphic   overview of consolidation units/consolidation groups (in rows) as well as   tasks/tasks groups (in columns). From this central interface, the users can   execute the tasks and monitor the progress/status. A dedicated infoprovider   can even be generated to perform reporting on the progress of task   processing. The “Business Process Flows” allow to sequence   application tasks and create links to these tasks within interfaces (such as   the Web). This functionality is for the moment only available in the   microsoft version.

This can be combined with the “work status” option:   it allows submitted data to be tracked, approved and locked. The submission   process and the hierarchical levels are customer-definable. It is also   possible to build reporting on work status information.


Balance Carry Forward ● Configuration: this task is mainly triggered by   the master data properties. By default, only balance sheet and statistical   balance FS items are carried forward. When balances are CF, the system   changes the transaction types according to their customizing settings, which   means that the balances are CF to the specified CF transaction types. The FS   Items are CF on themselves, but it is possible to define exceptions.

● Scope: all posting levels (for both manual and   automatic entries) can be processed at once.

● Special logic: what is also specific to BCS: a   dedicated “system period” (00) is used to store the CF balances. This is due   to the fact that the solution always stores the periodic values.


● Configuration: in BPC, you need to define your own   carry forward rules, that is to say source and destination accounts/flows,   with the option to filter the source data source types. The CF is executed   via a standard program included in a dedicated script logic.

● Scope: it is imporant to notice that this task   only treats the “Input” data and the manual adjustments. The automatic   adjustments are taken care of during the consolidation procedure itself.

● Special logic: the solution works in year to date   mode: the system needs to perform this “copy opening” process on each period   of the new year (thus the task must be executed each month).


Data collection ● Methods: SEM-BCS provides three methods to collect   data: flexible upload (flat file), load from data stream (infocube) and data   entry layouts (manual).

● Update modes: data collection can be performed in   periodic or YTD, using four update modes: Delete all, Overwrite, Delete   uploaded data, No modification.

● Mapping rules: in the flexible upload and load   from data stream methods, one can define mapping rules with   conditions/conversions, but these rules must generally remain simple, mostly   for maintenance reasons. More complex needs require BADI implementation.

● Manual entry: regarding data entry layouts, the   best practise is to limit their use, because they are not enough   user-friendly and flexible.

● Methods: BPC offers the same methods as BCS (load   from infocube is only available in the NW version).

● Update modes: three update modes are available :   Merge (Overwrite), Replace and clear (Delte all) and Append (Delta). It is   possible to preview the data before uploading them.

● Mapping rules: the solution is more flexible   regarding mapping rules because they are defined/maintained in Excel. A   “default” script can also be enhanced to perform additional calculations on   the fly when the records are written in the data basis (calculation of the   variation flow for example).

● Manual entry: data entry layouts are more user   friendly because they can be designed directly in Excel and also be used as   reports.


Journal entries ● Configuration: the core object you need to   configure is the “document type” (journal). Its properties and attributes   determine how the entry is treated in the consolidation process (posting   level, application, currency, …). The document type settings also enables   to manage the fields to be displayed in the journal entry screen.

● Posting logic: a journal entry remains valid for   the subsequent periods (periodic storage), except if the document type is defined   with the “inversion” property.

● Posting modes: four modes are available: enter,   reverse, invert, enter with reference and display document.

● Data storage: in BCS, all journal entries are   first stored with a high level of details in a DSO (flat table) and then   automatically replicated in a more aggregated format into the totals   infocube.


● Configuration: in BPC, you need to configure a   “journal template”, that is to say the format of your journal entry screen   (header, dimensions order, additional fields…). One must pay special   attention here: if the journal template structure is modified, journal   entries with the old structure are deleted.

● Posting logic: the inversion concept doesn’t have   sense in BPC because the solution works in YTD. That also means that if a   document is still valid the next period, it has to be re-posted.

● Posting modes: other options are available such as   save, unpost, or even create multiple journal entries based on a single   header.

● Data storage: the storage logic is the same as in   BCS, the documents are first stored in a table and then replicated in the   totals infocube.

Validations ● Configuration: a configuration interface allows to   build customer-definable selections and formulas to compare characteristics   combinaisons values. Tolerance limit and error/warning/information messages   can be set up. A very useful option called “validation with grouping   characteristics” is also available: it enables to apply a validation rule not   to all of the data, but to first split up the data according to specific   criteria, and then execute the validation for each data subset. This can save   you a lot of configuration effort and make the solution more flexible.

● Log: when executing the task, the system displays   the validation status, message and an overview of the selections/formulas. It   is also possible from EHP2 to jump to the list of totals records for more   details.

● Configuration: in BPC, validations are defined   using business rules. In these rules you specify the two sets you want to   compare with the corresponding accounts/flows and operand. Filters on other   dimension members can also be performed. The business rules are executed via   a standard program which is included in a dedicated script logic. Generally   speaking, the configuration and the possibilities offered by the BPC are less   flexible than in BCS (less operands, only two comparison sets, no “grouping”   option…).

● Log: the result of a validation rule is stored in   a technical account: the system posts any variance between the balances in   the two sets in this account. You then build a report on the technical   accounts to analyze the results.


Data re-classifications In BCS, a reclassification transfers the trigger   value from the source account to the target account using a reversed   debit/credit sign. The target selection is optional. The source is also   optional if it is equal to the trigger. In addition it is possible to define   a condition under which a reclassification takes place or perform a partial   reclassification by applying a percentage rate to the trigger. The   reclassification function can work in periodic or YTD.


In BPC, this function is called “account transformation”   and its principle is different: the system reads the value posted in the   source selection and posts the same value in the destination selection.   However it is possible to perform the posting with a sign inversion. There is   also the option to execue the task in YTD if the application works in   periodic.
InterUnit reconciliations ● Configuration: a dedicated task is available to   perform inter-unit reconciliations. It can use the same method as the   inter-unit eliminations, or a different one. A tolerance limit can be set up:   if an elimination difference exceeds the limit, the system generates an error   message.

● Logic: you can use reconciliations to determine   any elimination differences without having the system post elimination   entries. For that, the system translates the local currency amounts on the   fly and reconcile the results for a pair of companies and characteristic   groups (selections). This task is performed at the company level. The   reconciliation can be analyzed in the task log.

● Configuration: the best practise is to create a   dedicated application. The inter-unit transactions (input data and input   adjustments, in local currency) are copied from the consolidation application   and translated in group currency in the IC matching application.

● Logic: in BPC, the reconciliation is performed   within the same company. For that, after the copy, a program generates new   records as follows : 1) the company transaction is copied on a Buyer or   Seller datasource 2) the corresponding partner transaction is copied on the   corresponding Buyer or Seller datasource, with the same company and partner   values as the company transaction

Finally, a second program generates the difference   record. A reporting can be designed to analyze the figures.


Currency translation ● Configuration: in the BCS currency translation   method you specify the reference translation exchange rate type, the specific   translation parameters (source, exchange rate type and translation key) and   the difference item. A method can be divided into steps when you have groups   of items that follow different translations rules.

● Exchange rates: a table stores the exchanges rates   between one source and one target currency, for a specific date. This table   is shared by the consolidation and the BI system.

● Logic: during the task execution, the system   updates the group currency value field (doesn’t generate a new record) and   populates a currency translation adjustment if the specific translation is   not equal to the reference translation. Currency translation can be performed   in periodic or YTD. To perform an historical translation (for investments and   equity), you can use the translation based on the additional financial data.

In case you need to perform a consolidation in   several group currencies, you need each time to copy your data and   re-translate them in the target group currency.

● Configuration: the currency translation is defined   using business rules. One must define rules for both the specific translation   and the reference translation. The groups of FS items and flows to be   translated are designed using dimensions properties.

● Exchange rates: a dedicated application (RATE) is   available to store the exchange rates. The rate is not entered for a pair of   currencies but for one currency only: this rate enables to convert the source   currency into the group currency. If a consolidation is performed in several   group currencies, the system uses a pivot currency (rate for this currency =   1,00).

● Logic: during the task execution, the sytem   generates new records to store the group currency values and the CTA. The   currency translation is performed by default in YTD. The historical   translation is not covered: you need to populate manually the historical   value and then specify to the system to not re-translate this value in the   subsequent periods.

In case you need to perform a consolidation in   several group currencies, no need to copy the data: the system generates   separate records for each group currency.


Inter-Unit Eliminations ● Configuration: you can re-use the reconciliation   method or create a new one. In the method you specify the selections to be   compared, the difference item(s) and the tolerance limit.

● Logic: the system posts the elimination entries   and the difference (the document is posted only if the difference doesn’t   exceed the tolerance limit). One must distinguish “two sided” elimination   (pair of selections) and “one sided” elimination (only one selection).   Regarding the difference, it is possible to split the difference between   currency-related and other difference if the transaction currency value is   reported. As explained previously, the consolidation group is not physically   written in the elimination records but dynamically interpreted by the virtual   cube.


● Configuration: the inter-unit elimination rules   are part of the consolidation business rules. That means that the rule   depends on the consolidation method of the company and its trading partner.

● Logic: the elimination document is the same as in   BCS, except that the difference item is also the link account. Another   difference: the inter-unit eliminations are performed separately for each   consolidation group, which means that the consolidation group information is   physically written in the records.

Consolidation of Investments ● Configuration: the SEM-BCS COI concept is based on   standard “activities” which follow SAP pre-defined posting schemes. The   configuration mainly consists in selectioning the relevant options and   assigning the target/offsetting FS items with their corresponding breakdowns.   One advantage is that the logic is already there when you install the   solution, which can significantly reduce your configuration time. One   drawback is that it is very little flexible if the standard schemes don’t   perfectly match your requirements.

● Posting logic: in BCS, the COI works in “Delta”   mode. Delta for the time perspective: the system posts the periodic   documents. Delta for the group structure perspective: if a consolidation   group is included in another one, the system dosn’t post the transactions   twice, but only generates the delta documents. This logic reduces the number   of postings, especially if the structure of the group doesn’t change. On the   other hand, this logic doesn’t really reflect the common accounting   practices: accountants often have difficulties to get used to this logic and   prefer separating the closings/consolidation groups and perform the process   in year to date.


● Configuration: regarding this topic, BPC is a more   “open” solution. You can configure your business rules, formulas and   automatic adjustments according to the posting logic you need. It is also   possible to re-use pre-defined examples offered in SAP starter kits. Most   important COI requirements can be covered, such as purchase, equity, and   proportional methods or consolidation group changes. Additional concepts   (compared to BCS) are also available (and make the solution maybe more   flexible), such as the “Percentage of Consolidation” if you need to manage   the percentage of integration.

● Posting logic: BPC works like most of the   consolidation solutions available on the market, that is to say in year to   date mode. From the group structure perspective, documents are duplicated if   sub-consolidations need to be performed. Another specificity: COI documents are   always posted using the group shares (BCS offers group shares and direct   shares).

Reporting ● Configuration: consolidation reporting is designed   using a dedicated and separate interface, the Business Explorer.   Nevertheless, the execution can be performed in Excel or in the Web. Business   users can also format their own workbooks, analyze them offline and   re-execute them later.

BEX queries are very flexible, because part of their   components can be defined as variables, and also because the query structure   can be modified dynamically by the end-user after execution (“free   characteristics” concept).

● Reporting Logic: SEM-BCS uses a virtual reporting   logic: the queries are not directly based on the Infocubes for totals records   and journal entries. Instead they are based on virtual infoproviders that   dynamically (on the fly) interpret the data and apply to them the   consolidation logic (consolidation group logic, consolidation methods,   reporting mode…). This is possible with the help of programs.


● Configuration: the real strength of BPC is that   the reporting function is highly integrated with Microsoft Excel, for both   the design and the execution. The data are retrieved using pre-defined   BPC-Excel functions such as EVDRE. Another strength : the reports can also be   used to send data / comments in the database (same as for BI-IP).

● Reporting Logic: there is no specific logic as for   BCS. The consolidation logic is “physically” written in the records. The   consequence is that the records are duplicated as many times as consolidation   “views” you need.

Authorizations This topic requires deep knowledge and experience in   BI authorizations, especially if the requirements are sophisticated   (decentralized consolidation process combined with several “authorization   relevant” characteristics). Obviously, this is another expertise area.   Technically speaking, access to tasks is managed using “standard   authorizations” (assignment of authorization objects to roles), whereas   access to characteristic values is monitored by “analysis authorizations”.   The strength is that most of the authorization requirements can be covered   due to the advanced BW features.


Security is a lot more user friendly in BPC. An   easy-to-use authorization wizard is available in the administration console.   Defining the authorization profiles doesn’t require specific knowledge: the   administrator can easily restricts access to activities and dimension   members. Nevertheless, the matrix offered in standard only enables to meet   basic requirements : it becomes, for example, a lot more complex to perform   restrictions on member combinations…
Subsequent changes in the data model Generally speaking, subsequent changes in the BCS   data model might have side effects, especially if you modify the   characteristics with roles version, consolidation unit, consolidation group   and FS Item. Documentation on the SAP marketplace provides detailed   information about this topic. It is also difficult to change or delete a   characteristic value as soon as it is used in the transactional data: the   system always performs integrity checks. The BPC is obviously more flexible regarding changes   in the data model. It is for example possible to modify the dimension   properties, or re-modelize an application without major impacts, the objects   only need to be “re-processed” (re-activated) after these modifications. A   characteristic value can even be deleted or modified; however, the rules that   use this value must be updated manually after this change.


Kommentare sind geschlossen.