Vous êtes sur la page 1sur 60

SAP Business Objects EPM How-to Guide

How To Setup a Legal Consolidation Application using SAP BPC 7.0 version for SAP NetWeaver

Applicable Releases: SAP BusinessObjects BPC 7.0 for SAP NetWeaver

Version 1.1 December 2009

Copyright 2010 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. MaxDB is a trademark of MySQL AB, Sweden. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. SAP NetWeaver How-to Guides are intended to simplify the product implementation. While specific product features and procedures typically are explained in a practical business context, it is not implied that those features and procedures are the only approach in solving a specific business problem using SAP NetWeaver. Should you wish to receive additional information, clarification or support, please refer to SAP Consulting. Any software coding and/or code lines / strings (Code) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent. Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or altered in any way.

Document History
Document Version 1.10 1.00 Description << Enter your summary of changes in this version >> First official release of this guide

Typographic Conventions
Type Style Example Text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation Example text Emphasized words or phrases in body text, graphic titles, and table titles File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.

Icons
Icon Description Caution Note or Important Example Recommendation or Tip

Example text

Example text

<Example text>

EXAMPLE TEXT

Table of Contents
1. 2. 3. 4. Business Scenario ..........................................................................................................2 Background Information .................................................................................................3 Prerequisites....................................................................................................................3 Step-by-Step Procedure ..................................................................................................4 Application Set Creation ....................................................................................................4 Login in to Apshell ....................................................................................................4 Create Appset ...........................................................................................................5 Set AppSet Parameters ............................................................................................6 Master Data (Dimensions) Set-up ......................................................................................7 Set-Up Dimensions in Dimension Library ..................................................................8 Required Dimension properties........................................................................................12 Account Dimension .................................................................................................12 Category Dimension ...............................................................................................13 Data Source Dimension ..........................................................................................15 Entity Dimension .....................................................................................................16 Currency/Group Dimension(s) .................................................................................16 Flow Dimension ......................................................................................................19 Maintain property ....................................................................................................20 Maintain dimension members .................................................................................21 Create/Modify the Application ..........................................................................................23 Rate application: .....................................................................................................24 Ownership application:............................................................................................25 Consolidation (Main) application: ............................................................................28 Set the Application Parameters........................................................................................34 YTDINPUT setting ..................................................................................................36 Business Rules Interface .................................................................................................37 Customizing for Table Driven ABAP Program..........................................................37 Execute consolidation task ..............................................................................................38 Add the data Manager Packages for consolidation application. ...............................39 Create Script Logic files (LGF) ................................................................................41 Maintain the business rule table ..............................................................................43 Loading data ...................................................................................................................44 Loading exchange rate to rate application ...............................................................44 Input ownership data and calculate ultimate ownership ...........................................45 Loading the Financial data ......................................................................................48 Work Status Setting .........................................................................................................50 Work States Setting (AppSet dependent) ................................................................50 Work Status Setting (Application Dependent) ..........................................................51 Journal Template and Validation Setting ..........................................................................52 Journal Template ....................................................................................................53 Validation Setting ....................................................................................................54

1.

Business Scenario

When closing a financial period, the finance department faces the task of consolidating their numbers to produce their consolidated financial statements of a group of legal entities. Common activities to achieve a consolidated financial view usually include: Initialization of beginning balances when a new reporting cycle starts Uploading of financial data for each entity Data Validation Matching of inter-company transactions (e.g., AR / AP reconciliation) Conversion of local currency data in the desired group reporting currencies Generation of all the consolidation entries for the desired groups of entities such as: o o o o o Ultimate ownership calculation elimination entries for intercompany revenue, investments and profit in inventory adjusting entries re-classifications minority calculations other calculations

Final Validation Report generation The Legal application as well as all the legal/statutory consolidation business rules functionality that enables our customers to perform many of the number-crunching activities required in the generation of consolidated statements of a group of legal entities need to be built Please note that not all of the above mentioned functions will be covered in detail in this document. This How to Guide focuses specifically on the dimension properties and relevant setting required for the various dimension, application and task in order to successfully perform Legal consolidation using BPC 7.0 for SAP NetWeaver. This guide will also briefly describe how to setup the Currency translation, inter unit elimination, COPY opening etc. using the Business Rules tables and script logic using the BPC Admin. Furthermore, it will be shown how to setup the data package to run the task using the BPC Excel. The configuration of Business Rules will be discussed as they provide the mathematical foundation for the BPC application thus allowing users to manage both - management and legal consolidation reporting. Following steps outline what is being covered in this guide in order to set up your consolidation environment Consolidation (Legal) AppSet creation/Parameters setting Master Data (Dimensions) Set-up Application creation/Parameters setting

Table Driven ABAP Program Maintaining (Data Manager Packages, Scripts Logic, Business Rules) Rate Data and Ownership Data Update Work Status Setting Journal Template and validation setting .

2.

Background Information

In the SAP NetWeaver environment the ApShell, the starting example Application Set provided in BPC7 for SAP NetWeaver, comes with only a Planning and Rate application. So, ApShell does not contain any consolidation application. The strategy is to keep ApShell straight and reflect the baseline requirement for customer to start a new implementation and ensure there is nothing that will have to be re-engineered that is related to the customers master/meta data, on the other hand, need minimize the taken off work on ApShell at customers. This document is intended for consultants or administrators who understand the basic elements that need to be set up in order to make the consolidation engine work. It also provides detailed procedures for setting up all the elements in the consolidation module. The guide does not explain how the consolidation rules can be defined with BPC consolidation engine to meet certain legal requirements such as accounting principles like IFRS or USGAAP. Please refer to the IFRS starter kits for BPC for more detail.

3.

Prerequisites
Successful installation of BPC7.0 for SAP NetWeaver ABAP server, .Net server and client Completion of ApShell content activation Understanding Business Rules for BPC. Understanding Script Logic for BPC.

4.

Step-by-Step Procedure

The first step in setting up legal consolidation is to configure the application dimensions properly. This document walks through the required dimensions and properties for setting up the legal consolidation framework.

Application Set Creation


Login in to Apshell
Once installation and ApShell activation have been completed, you should be able to log on Admin Console with the AppSet ApShell.

Figure 1: ApShell Application Set within BPC 7.0 for SAP NetWeaver

Tip: To check that the ApShell content activation has processed successfully, either log on Admin Console or access ABAP server from GUI and run the transaction RSA1 to check the BI Infoprovider APSHELL and its structure.

Create Appset
In Admin Console, Copy ApShell into the target AppSet as a starting point to begin building out your appset.

Figure 2: Copying ApShell as a starting point for Legal Consolidations

Note: If you already have an existing application set (e.g., for planning or reporting), then you can use this appset to host your Legal Consolidation. Using the application set for planning or reporting as a basis to build consolidations allows you to share the relevant dimensions such as account - with your consolidation environment.

Set AppSet Parameters


Application set parameters allow you to customize your application sets within BPC. The following parameters are available when setting up the Application Set. (Most of them are not necessarily consolidation required, but the generic system requirement for AppSet. )

Key ID

ALLOWEXTENSIONS ALLOW_FILE_SIZE

AVAILABLEFLAG

AVAILABLEMSG

AVAILABLEURL

DEFAULT_EXTENSIONS LANDINGPAGEITEM

LOGLEVEL

MAXLRCOLUMNS

MAXLRROWS

SMTPAUTH

Description Defines the file extensions the system permits users to upload to the application, data manager files, content library files, web ready files, and library files. When set to ALL, BPC allows all extensions. The default value is ALL. (Required) The maximum file size BPC permits users to upload. The default value is 100 MB. (Required) Controls whether the system is offline or not. Yes means the system is online and available for sending data to the database. You can take the system offline by changing the value to No. (Required) The message that displays to users who try to access an application that is offline (AVAILABLEFLAG = No). (Required) Example: The message could be BPC is temporarily unavailable due to scheduled maintenance. Please try again later. The name of the Web page to display to users who try to access an application that is offline (AVAILABLEFLAG = No). (Required) Example: The url could be /osoft/NotAvailable.asp. The file extensions BPC allows users to upload by default: .XLS, XLT, .DOC, .DOT, .PPT, .POT, .XML, .MHT, .MHTML, .HTM, .HTML, .XLSX, .XLSM, .XLSB, .ZIP, .PDF, .PPTX, .PPTM, .POTX, .POTM, .DOCX, .DOCM, .DOTX, .DOTM, .CDM, .TDM, .PNG, .GIF, .JPG, .CSS, .MRC. See ALLOWEXTENSIONS above. To customize the Getting Started page on BPC Web, contact your system administrator. Used by application set to control the level of the ABAP log, which you view by the transaction SLG1. (Optional) LOGLEVEL has the following possible values: 0 - None: Log is off. 1 - Error: Log only the error, abort, and exit messages. 2 - Warn: Log the warning, error, abort, and exit messages. 3 - Info: Log the info, status, error, abort, and exit messages. The maximum number of columns to display in a live report in BPC Web. The value includes header and data columns. Example: If you specify a value of 5, one heading column and four data columns are displayed. The maximum number of rows to display in a live report in BPC Web. The value includes header and data rows. For example, if you specify a value of 5, one heading row and four data rows are displayed. Example: If you specify a value of 5, one heading row and four data rows are displayed. The authentication method of the SMTP server. (Required) 0 = Anonymous 1 = Basic 2 = NTLM

SMTPPASSWORD SMTPPORT SMTPSERVER SMTPUSER

TEMPLATEVERSION SYSTEM MESSAGE STATUS

This setting does not change the method on the SMTP server, but must match the type of authentication enabled on it. Failure to set this appropriately can result in errors from the email server. The password for the user name defined as the SMTPUSER (Required) Port number for your SMTP email server. Default is port 25, the default SMTP server port number. (Required) The name or TCP/IP address of the SMTP email server the system uses to send email. (Required) The user name from which email from the system originates. (Required) Current version number of the dynamic templates in your application set. Whenever you add to or change your input schedule or report dynamic templates, you should increment this version number so that users will automatically get the new templates downloaded when they log on to this application set. (Required) You can also reset the template version from the Admin Console. BPC 7 Internal system Parameter, default value = 1 BPC 7 Internal system Parameter, default value = Blank BPC 7 Internal system Parameter, default value = 1
Figure 3: Appset parameters

Tip: In the back end, all the above parameters are stored in ABAP DDIC table: UJA_USER_DEF.

Master Data (Dimensions) Set-up


The BPC consolidation engine leverages 3 applications, Legal, Rate and Ownership to retrieve the information necessary to perform its calculations. The Legal or Main application - This Consolidation Type Application is the application within which the respective consolidation entries for e.g. currency conversion or intercompany eliminations are written The RATE application - The currency conversion process uses a RATE application, to look up the appropriate exchange rates for each relevant currency. The OWNERSHIP application - The Consolidation process uses an OWNERSHIP application, to store the definitions of each consolidation perimeter. In particular, such definitions may include: The list of companies being consolidated in each group Their consolidation method Their consolidation percentage Their ownership percentage (how much they are owned by the group) Their control percentage (how much they are controlled by the group) Main, Rate and Ownership application can be named as desired. Within the same AppSet, multiple MAIN applications may exist, each one pointing to its own RATE and / or

OWNERSHIP applications. Multiple MAIN applications can also share the same RATE or OWNERSHIP applications, if appropriate. The RATE application associated to a given application is defined when a new MAIN application is being created. The OWNERSHIP application associated to a given application is identified using an application parameter as follows: OWNERSHIP_APP = {app name} If this parameter does not exist, the consolidation procedure will by default search for an application named OWNERSHIP. Each one of the above listed applications must contain some required dimensions, while some other dimensions are optional. The details will be discussed in the next section. The dimensions discussed in this document are based on the standards used in the business rules. Other dimensions can co-exist in a reporting application but do not impact the business rule function. All applications must contain the four required ENTITY, CATEGORY, TIME and ACCOUNT dimensions (albeit named as desired). The CURRENCY / GROUP dimension must be same used in the Ownership application as well as the Main application. Here are some of the common member requirements between these dimensions for Legal consolidation environment setup described below: The CATEGORY and TIME dimensions can be the same across the Main, Rate and Ownership applications, or they must contain the appropriate matching members if different. The ENTITY dimension of the Main application can be the same used in the Ownership application or at least it must contain the appropriate matching members if different. The CURRENCY / GROUP dimension of the Main application (see Currency/Group Dimension(s)) must be same used in the Ownership application or at least it must contain the appropriate matching members. In most cases it is preferred to use the same dimensions across applications as it is easier to maintain. Note: The Rate application is delivered with Apshell. Most dimension properties required for the consolidation setup are pre-delivered with the dimensions within Apshell. However it is recommended to verify that before proceeding further.

Set-Up Dimensions in Dimension Library


For the consolidation application, the following listed dimensions are mandatory requirements. Therefore, it is advisable to double check that all the dimensions are available in the Dimension Library of your consolidation Application Set created from ApShell as describe in the previous in section Note: While the dimension names can be chosen as desired it is mandatory that the dimension types match with the ones described in this guide for the corresponding applications.

The Main Legal Consolidation Application requires the following dimensions:

Account dimension (C_Acct in ApShell) of Type A Account. - Members of this dimension are for example Revenue, Salaries etc Category dimension (C_Category in ApShell) of Type C Category. - Contains the types of data you are going to track, such as Actual, Budget, and Forecast. You can set up categories to store versions, such as BudgetV1, BudgetV2. Data Source dimension (C_Datasrc in ApShell) of Type D Data Source. - Used in the business rules of a reporting consolidation application to segregate input data Subtable dimension (Flow in Apshell) of Type S Subtable. - Breaks down account activity or flow Entity dimension (Entity in ApShell) of Type E Entity dimension - Contains the business units that are used to drive the business process Depending on your application design, the Entity type can be an operating unit, a cost center, a geographic entity, and so on. Intco dimension (Intco in ApShell) of Type I Intco dimension - Contains the inter-company codes for the entities Time dimension (Time in ApShell) of Type T Time dimension - Contains the time periods for which you store data Currency dimension (Groups in ApShell) of Type R Currency dimension - The currency type dimension is required if the customer reports on local currency and translated values. The currency-type dimension was also used for storing the group component of legal consolidation. The group represents the relationship of entities for a given consolidation result. This group is consolidated in a single currency hence there is no need to have another dimension. Note: However if the requirement is to have consolidated results in multiple group currencies within a single entity structure, then the customer can continue to use the currency type dimension for this purpose or a separate dimension for the group. Group provides multiple currencies for a group member. The Rate Application containing Exchange Rates requires the following dimensions: Account dimension (R_Acct in ApShell) of Type A Account. - Members of this dimension are utilized to detail the different types of rate (Average, End-of-period, etc.). Category dimension (C_Category in ApShell) of Type C Category.

- Contains the types of data you are going to track, such as Actual, Budget, and Forecast. You can set up categories to store versions, such as BudgetV1, BudgetV2. Entity dimension (R_Entity in ApShell) of Type E Entity. - This is used to store multiple tables of rates, if desired, otherwise the R_Entity dimension may just be limited to one dummy member, typically named GLOBAL. Currency dimension (InputCurrency in ApShell) of Type R Currency. This dimension is utilized to store for each applicable local currency. Time dimension (Time in ApShell) of Type T Time dimension - Contains the time periods for which you store data Note: Time and Category dimensions must be shared by all the application involved in consolidation The Ownership application storing the ownership details requires the following dimensions:

Account dimension (O_Acct in ApShell) of Type A Account. - Members of this dimension are for example METHOD (consolidation method), POWN (ownership percentage), PCON (control percentage ) etc Category dimension (C_Category in ApShell) of Type C Category. - Contains the types of data you are going to track, such as Actual, Budget, and Forecast. You can set up categories to store versions, such as BudgetV1, BudgetV2. Entity dimension (Entity in ApShell) of Type E Entity dimension - Contains the business units that are used to drive the business process Depending on your application design, the Entity type can be an operating unit, a cost center, a geographic entity, and so on. Intco dimension (Intco in ApShell) of Type I Intco dimension - Contains the inter-company codes for the entities Time dimension (Time in ApShell) of Type T Time dimension - Contains the time periods for which you store data Currency dimension (Groups in ApShell) of Type R Currency dimension - Here the currency-type dimension is used for storing the group component of legal consolidation. The group represents the relationship of entities for a given consolidation result. This group is consolidated in a single currency hence there is no need to have another dimension. Note: If the requirement is to have consolidated results in multiple group currencies within a single entity structure, then the customer can continue to use the currency type dimension for this purpose or a separate dimension for the group. Group provides multiple currencies for a group member. In this case you have to use the group type dimension in Ownership application which is available as of BPC 7.5 for SAP NetWeaver

Caution: An appset copied from ApShell will already have the Rate application. You should ensure sure to replace the Rate Category dimension with the Consolidation C_Category as this dimension already has the properties required for Consolidation. The following table gives a summary of what dimension is required in which application:

Name C_Acct IC_Acct O_Acct R_Acct Flow C_Category Entity R_Entity Intco Time Group InputCurrency C_DataSrc

Type A A A A S C E E I T R R D

Legal X

Ownership

Rate

X X X X X X X X X X X X X X X X X X

Figure 4: Dimension in application matrix

Note: IC_Acct dimension shown here is used when separate application is created for Intercompany Matching. Please refer to the How to guide on how to setup Intercompany Matching for more details. To create a new dimension, go to the Admin Console -> Go to dimension library. In the action pane, click on option Add a new dimension to create dimension as shown below.

Figure 5: Creating a new dimension in the BPC admin console

Required Dimension properties


...

When you create a new dimension, all the required properties (attributes) are created automatically based on the dimension type. But in order to ensure that consolidation and related processes work (such as currency conversion, simulation, automatic adjustment etc.) additional dimension properties are needed to achieve the filter, flagging and calculation of the target data. Therefore, we need make sure those properties are maintained with the expected values for the consolidation process according business requirement. The following subsections discuss all additional dimension properties (attributes) needed to enable the consolidation process. These property-lists are check lists for the completeness of master data settings to enable a base line consolidation process.

Account Dimension
The Account dimension defines the chart of accounts for your application, and how those accounts are calculated and aggregated. Any dimension that is assigned the type A is considered an Account dimension. Each application can have only one Account-type dimension. In Apshell we will have four Account type dimensions C_ACCT used in the consolidation application, O_Acct used in the Ownership application, P_ACCT used for planning Application and R_ACCT used in Rate application.

Property Name ACCTYPE

Length 3

Description of appropriate property value INC for Income, EXP for Expense, AST for Asset, LEQ for Liabilities & Equity.
Note: signed Data = - signed Data when

DIMLIST

20

RATETYPE

10

ACCTYPE = INC or LEQ. Used to group the accounts for using in Business Rules. For example : using the DIMLIST property value can help reducing the size of the FXTRANS table Used by the currency conversion business rules. This determines the business rules to be applied in translating any given account from local to reporting/group currency. Value is optional. All ACCOUNTS with no RATETYPE (RATETYPE = blank) will be translated with a factor of 1
All ACCOUNTS with the reserved RATETYPE = NOTRANS will not be translated

ELIMACC

20

Used in the Elimination process; which represents the difference account, which the accounts to be eliminated will be posted into.

Category Dimension
All applications require a category type dimension. The properties required in this dimension as described below are for two business rules currency translation and copy opening balances. For simulation purposes, or to analyze the variances from one set of data to another, it is very often necessary to mix-and-match different rates and values of different data categories from different time periods. For example a user might want to compare ACTUAL with BUDGET values when both are translated at the ACTUAL rates, or this year ACTUALS with last year ACTIUALS, both translated using last year rates, etc. This can be done by either creating some additional simulation CATEGORY (like Actual_at_Budget_rate or the like) or adding an extra dimension to the MAIN cube, where all the simulated cases can be stored.

The beauty of our solution is that for all the desired simulations there is no need to copy around any of the input values. A few definitions, stored in some specialized properties of the CATEGORY (or the FX simulation) dimension will tell the translation procedure where to read the input values and where to write the translated results. To minimize the impact of the different simulations on the size of the database, it is also possible to tell the system to only store the difference between the default results and the simulated scenarios. When using the simulation categories in the Main cube, simulated translations are stored in additional members of the CATEGORY dimension. These categories will have non-blank values in one or more of the following properties: Property Name FX_SOURCE_CATEGORY RATE_CATEGORY RATE_YEAR Length 20 20 4 Description of appropriate property value The category for the source (LC) data. If blank, it is the current category. The category from which the rates are read The year from which the rates are read. The value can be absolute (2005, 2006) or a relative value (-1, -2, +1, + 2). If blank it is the same as the source. The period from which the rates are read The value can be absolute (DEC, FEB) or a relative value (-1, -2, +1, + 2). If blank it is the same as the source. If = Y, only the difference between the default values and the simulated values is stored.

RATE_PERIOD

10

FX_DIFFERENCE_ONLY

The business rules for copying opening balances can be controlled by assigning some special properties to the category dimensions. If existing, these properties affect the execution. Property Name CATEGORY_FOR_OPE Length 20 Description of appropriate property value Blank: the category for the opening balances is the same Non-blank: the ID of the category where to read the opening balances from Blank: the prior year Non-blank: the year where to read the opening balances from. It can be an absolute or a relative amount Blank: the last period of the year Non-blank: the period where to read the opening balances from. It can be an absolute or a relative amount

OPENING_YEAR

OPENING_PERIOD

10

Data Source Dimension


The data source dimension type is an optional application dimension. However, it has become a best practice standard dimension. The name of dimension can be customized as appropriate for the customer. Mandatory for the elimination business rules. The DATASRC dimension is required for elimination and/or consolidation business rules. For example the automatic elimination will work only if you have be a base level value and has to have the datasource type A for it to work. Optional for the currency business rules as it is not used in the business rules for currency conversion. Mandatory for the consolidation business rules, it is require as the results destination. For example you can define by Source Data Source a specific Destination Data source under which the resultant postings shall be posted.
Mand atory fo r th eelimi nati o n b usine ss rule s Option al fo r the c ur ren cy b usi ness u r les Mand atory fo r th eco nsolid a tion bus in ess r ul es, it is requir e as the results des tina ti on

Property Name IS_CONVERTED

Length 1

Description of appropriate property value Y if the datasrc has to be converted N id the datasrc has not to be converted G If you want to convert the datasrc from a currency group to a group currency i.e. the members are copied from the reporting currency of the GROUP being translated into the currency member corresponding to the given group. This obviously applies only if the translation is run for a GROUP and not for a reporting currency. Blank for management Application Y for Consolidation I for Input M for manual journal entry A for automatic generated journal L for Level - This is used in consolidation by level to move prior level eliminations into a datasrc with property DATASRC_LEVEL=Y in the Group dimension. Blank or Y: this member is copied N: this member is not copied Blank: same as the source member Non-blank: the ID of the desired destination DATASRC for the copy

IS_CONSOL DATASRC_TYPE

1 1

COPYOPENING OPENING_DATASRC

1 20

Entity Dimension
The Entity dimension defines the organizational structure of the business units for your application and how the units aggregate. Any dimension that is assigned the type E is an Entity dimension. Each application can have only one Entity-type dimension.

Property Name CURRENCY

Length 20

Description of appropriate property value Local Currency used by the Entity. This currency must be defined in the InputCurrency dimension.

FX_TYPE

20

Special rate for Entity used by the currency conversion business rules. Value is optional. Used to link intercompany counterpart ID for elimination. Also known as Trading Partner. This ID must be defined in the IntCo dimension. Used for work status

INTCO

20

OWNER

60

Generally the Entity dimension contains the business units that are used to drive the business process. For consolidations this will be the legal entity in most cases. Depending on your application design, the Entity type can be an operating unit, a cost center, a geographic entity, etc. This dimension is also used to supply the members that are used in the work status approval process.

Currency/Group Dimension(s)
The currency type dimension is required if the customer reports on local currency and translated values. The currency-type dimension is also used for storing the group component of legal consolidation. The group represents the relationship of entities for a given consolidation result. This group is consolidated in a single currency hence there is no need to have another dimension. As of BPC 7.5 customers can continue to use the currency type dimension for this purpose or they can split it into a Group dimesion (Type G) and a pure currency dimension (Type R) in order to allow reporting in multiple group currencies. The required properties for a separate group dimension are:

Property Name GROUP_CURRENCY

Length 20

Description of appropriate property value Can be a valid reporting currency. Used for currency Conversion This property can only be used on CURRENCY members with the property

Property Name

Length

Description of appropriate property value CURRENCY_TYPE= G and in this case it must contain a valid ID from the CURRENCY dimension with the property CURRENCY_TYPE = R. Must be a valid Id from the Groups dimension. If you want to do the consolidation by level, you must indicate here the higher level from the group. If you want to use this property to define the hierarchy, enter the same code as the Id for your Top group. If this property is blank, the dynamic hierarchy from the Ownership application is used. Blank or a valid Entity ID. Is used to define the link between the Group and the Entity and / or to indicate the entity where the aggregation should be stored. If this property is filled with valid Entity id, and the property STORE_ENTITY is set to Y, the results of the currency conversion for the current GROUP will also be copied into this ENTITY Used for currency Conversion Values = Y or N or Blank By default the results of the conversion into a GROUP currency are written in both the GROUP member and in the CURRENCY member of the currency dimension. If only the GROUP member is to be stored, the administrator can set this property to N. Y or blank: Y if you want to store in the id filled in the entity property. This property controls the way the converted values must be saved in case of a multi-level conversion of groups. This property can only take the three values Y, E or N (blank).

PARENT_GROUP

20

ENTITY

20

STORE_GROUP_CURR

STORE_ENTITY STAGE_ONLY

1 1

The required properties for a currency and group dimension combined are:

Property Name PARENT_GROUP

Length 20

Description of appropriate property value Must be a valid Id from Groups dimension. If you want to do the consolidation By level, you must indicate here the higher level from the group. If you want to use this property to define the hierarchy, enter the same code as the Id for you Top group. If this property is blank, the dynamic hierarchy from the OWNERSHIP cube is used. This property can only be used on CURRENCY members with the property CURRENCY_TYPE= G and in this case it must contain a valid ID from the CURRENCY dimension. Blank or a valid Entity id. Is used to define the link between the Group and the Entity and / or to indicate the entity where the aggregation should be stored. If this property is filled with valid Entity id, and the property STORE_ENTITY is set to Y, the results of the currency conversion for the current GROUP will also be copied into this ENTITY Can be: L = Local Currency R = Reporting Currency T = Transaction Currency G = Group Used for the currency Conversion Can be a valid reporting Currency. Used for currency Conversion Used for currency Conversion Y=When you run the conversion for a group Currency, the procedure also stores the results in the corresponding Group_currency. N=The GROUP_CURRENCY is not stored in the database. Y or blank: Y if you want to store in the id filled in the entity property. This property controls the way the converted values must be saved in case of a multi-level conversion of groups. This property can only take the three values Y, E or N (blank).

ENTITY

20

CURRENCY_TYPE

GROUP_CURRENCY STORE_GROUP_CURR

20 1

STORE_ENTITY

STAGE_ONLY

Property Name FIRST_CONS_DATE

Length 10

Description of appropriate property value Blank for management Application YYYY.MON for Consolidation

Flow Dimension
The flow type dimension is optional but its use is highly recommended. This dimension allows for a customer to track changes within the account activities, such as opening balance, additions, subtraction and currency translation adjustments. If the customer does not require this level of detail, the business rule tables should be left blank for the sub-table field.. Flow is similar to the movement type in SAP ERP. If Flow is included in the application, it can be used (1) by the currency translation procedure, to detail the changes in the balance sheet generated by fluctuations in the exchange rates and (2) by the consolidation procedure to detail the eliminations applied to the movements of the balance sheet accounts. If the customer choices to use a flow type dimension the following properties are required: Property Name FLOW_TYPE Length 12 Description of appropriate property value OPENING : opening TRANSLOPE : Change Diff On opening ALLOCINC : Allocation MERGER : merger INCOME : Net Income From The period CHANGE: Variation. TRANSFER : transfer TRANSFLOW : Translation Change on Flow VARSCP : Variation In Scope (Generic) VARSCPMETH : Variation In Scope Method VARSCPPERC : Variation In Scope percentage VARSCPNEW : Variation In Scope new Company VARSCPLEAV : Variation In Scope Sold Company CLOSING : Closing NONE : No Flow Blank : all other Flows Used to group the Flows for several Business Rules Y if the flow is an input one N if the flow is not an input one

DIMLIST IS_INPUT

20 1

Maintain property
To maintain the property of a dimension, Go to Admin Console - > left click to select a dimension in dimension library -> find option Maintain dimension property in action pane.

Figure 6: Property Maintenance in the BPC administration Console

When you select say C_Acct and click on Maintain dimension property you will see the properties associated with this dimension similar to the one listed below:

Figure 7: Property Maintenance in the BPC administration Console

Maintain dimension members


1. Maintain dimension members and their property values. To maintain the dimension member of a dimension, go to Admin Console - > left click to select a dimension in dimension library -> find option Maintain dimension member in action pane.

Figure 8: Maintaining dimension members and their properties

Here is an example of the Entity dimension member sheet that shows up when you click on Maintain dimension members .

Figure 9: Example of Member sheet

Note: The dimension member values are case sensitive with BPC7 for SAP NetWeaver version, which means if upper case and lower case written are recognized as two different members. But for RATE cube and Ownership cube, we strongly recommend that not set two members just with different cases, for example R_ACCT dimension AVG and Avg could be two different members to store the AVG exchange rate, this is not recommended to be used for storing exchange rate and ownership details, as both script logic and consolidation program could be confused as well as bad ender user recognition issues might be resulted. For consistency reasons it is recommended to use only upper case for the dimension IDs.

Create/Modify the Application


...

When creating a new application, you have to choose an application type, which tells the system which properties to associate with the application. In BPC, an application is either Reporting or Non-reporting. Non-reporting applications are designed to support reporting applications or to simply hold data (e.g. price or rate info). There are three types of reporting applications in BPC: Financial: performs management consolidation functions, such as currency conversions, intercompany eliminations, etc This application must reference a Rate-type application. Consolidation: performs legal consolidations. Similar to Financial applications, but with legal consolidation rules instead of management This application must reference an Ownership-type application and a Rate-type application. Generic: has no special requirements (other than to include the four minimally required dimensions) Has no out-of-the-box intelligence, so logic must be created using K2 Script Logic. The two non-reporting types of applications can be associated to only the financial and consolidation type applications. The two types of non-reporting applications are: Rate: stores exchange rates that support currency conversions for reporting applications This application must include a Currency-type dimension to store the exchange rates by currency. Ownership: Stores information such as the consolidation methods, ownership percentages, and group rollup information used for legal consolidation. Within the same application set, multiple reporting applications may exist, each one pointing to its own Rate and/or Ownership applications. Multiple reporting applications can also share the same Rate or Ownership applications, if appropriate. The Rate and/or Ownership application associated to a given reporting application is defined when a new consolidation type application is created. Note: You can report on non-reporting application data, but you cannot assign work status codes to the data. In addition, you cannot define business rules to these application types. All applications require at least the four main dimension-types: Entity, Account, Time, and Category. In SAP BPC, as mentioned in section 4.2 a consolidation application requires at least 3 applications: Legal Main Application containing all financial data. All consolidation postings such as eliminations, minority interest calculations etc are posted in this application Ownership Used to manage the organization structure and ownership percentages Rate Contains all currency exchange rates for the different rate types like average, sport rate etc

Currency Translation can run on any type of reporting application. Currency conversion applies to both Financial and Legal Consolidation Applications to which a corresponding Rate Application has been referenced and that the reporting application must contain a currency (type R) dimension.

Rate application:
A rate application is a supporting application for financial and consolidation reporting applications. It is used to store exchange rates that support currency conversion in Consolidation applications. ApShell comes with a rate application already, so you can leverage this one by just modifying the Category dimension from Category to C_Category. The time dimension must be identical to the dimension used by the applications using the rate application to store their foreign currency exchange rates and must have the same category member IDs. This application must include a currency dimension detailing the exchange rates by each input currency. The currency dimension in a rate application does not need to have the REPORTING property. The Currency conversion process makes use of a RATE application, where the appropriate exchange rates will be searched for each relevant currency. This cube can be named as desired. But we will refer to it as the RATE application, in this document. Please refer to the How to guide on this topic that shows the entire process in detail. Note: The master data (dimension) can be shared by application within an application set.

But for the RATE application, to fulfill certain requirements like properties required are different compared to C_Acct used in the Main application, R_Acct (Account Dimension for RATE application) and R_Entity (Entity Dimension for RATE application) are specific and utilized only by Rate Application.

Figure 10: The rate application R_Acct is utilized to detail the different types of rate (Average, End-of-period, etc.). R_Entity s used to store multiple tables of rates, if desired, otherwise the R_Entity dimension may just be limited to one dummy member, typically named GLOBAL. For

example if you have an entity C1000 for which a special exchange rates needs to be applied, then it will be defined here and the special rates need to be applied. Currency dimension is utilized to store for each applicable local currency. Time and Category dimensions can be shared by all the application involved in consolidation.

Ownership application:
Any consolidation type application must refer to a RATE and OWNERSHIP application. As mentioned before Apshell comes only with Planning and Rate application, the ownership application needs to be created before we can create the Consolidation application. Please refer to the steps wizard of creation process. The business rule process makes use of an Ownership type application when calculating the ultimate ownership or during the minority interest calculation. This application must be associated to a Consolidation type application. The ownership application will contain the values of each consolidation parameter. In particular, such definitions may include: The list of companies being consolidated in each group Their consolidation method Their consolidation percentage Their ownership percentage (how much they are owned by the group) Their control percentage (how much they are controlled by the group) Ownership application can be named as desired, but we will refer to it as the Ownership application, in this document. If the name of the application is other then OWNERSHIP, you must identify the application by name in an application parameter as follows: ORG_OwnerShipCube= {app name} If this parameter does not exist, the consolidation procedure will by default search for an application named OWNERSHIP. Create a new application, name it and select the application OWNERSHIP. Select Ownership as Non-Reporting Type as shown below.

Figure 11: the Ownership application type

From the Shared Dimensions area add the Entity, O_Acct, Groups, and IntCo dimensions to the Application Dimensions area. Remove the InputCurrency, R_ACCT, and R_Entity dimensions from the Application Dimensions area. Then select the Entity dimension row and click the Secured button and verify that your screen looks similar to the following:

Figure 12: the Ownership dimension selection

Make sure security is toggled to Yes for C_Category and Entity. Then click on Add a New Application. Ownership application defines ownership details such as the consolidation scope, method, % of share owned by holding company or groups etc. For ownership application, the only dimension which is specific for ownership cube is Ownership Account (O_Acct) to be used BPC consolidation engine to get the information listed above. In order to pass the information, we have to set up several required members, which include, 1. Method, defines consolidation method 2. POWN, defines % of ownership (how much they are owned by the group) 3. PCON, defines % of consolidation 4. PCTRL, defines % of control (how much they are controlled by the group)

Figure 13: the Ownership application

To set the Application parameters do the following steps 1. Open the BPC Administration webpage. If you have closed it, you need to go back to the BPC launch page and click the BPC Administration. Icon. 2. Set the Application Set to the name of your Appset and the application to the name of the Ownership application in the top right corner of the Action Pane. You may need to click on Available Interfaces / BPC Administration to go back to the BPC Administration webpage after you changed the Appset/Application 3. Click on Set Application Parameters. Here are the relevant application parameters and the recommended values that should be set through the Web Admin. Please refer to the Admin guide on how to set these values.

Key ID
ORG_OWNERSHIPCUBE ORG_INTCO

Description
The default value is OWNERSHIP. The default value is I_NONE, which should also be a member ID in the INTCO dimension in the ownership application if using dynamic hierarchies.

ORG_ACCOUNTOWN OWNERSHIP_APP

The default value is PGROUP. The name of the Ownership application. If this parameter does not exist, the consolidation procedure will by default search for an application named OWNERSHIP.

ORG_ACCOUNTLIST ORG_PARENTPROPERTY

The default value is METHOD,POWN,PCON. This parameter is used with dynamic hierarchy statutory applications when defining fixed hierarchies. The value must match the value in the ParentProperty property value of entities in the statutory application's supporting ownership application. The default value is PARENT_GROUP.

Figure 14: the Ownership application parameters

Consolidation (Main) application:


Any consolidation type application must refer to a RATE and OWNERSHIP application. Going forward we will use the ones created in the previous step. Please refer to the steps wizard of creation process. Create a new application, name it and select the application Consolidation. Assign the corresponding RATE and OWNERSHIP application to as shown in the screenshots.

Figure15: Naming the Consolidations application

Figure 16: selecting the right application type: Consolidations

Figure 3: associating the desired Rate and Ownership application with the new consolidation application

In step 3, select all the consolidation business rules need to be implemented. Here is the list of Business Rule that is available for selection: Currency conversion: Conversion of local currency data in the desired reporting currencies. Calculations: T o calculate and store amounts which are required for purposes of account transformation. Intercompany bookings: Matching of inter-company transactions. US Eliminations: Specifically designed to address the posting of inter-company eliminations in simpler scenarios where a full legal consolidation application is not required. Opening Balance: Initialization of beginning balances when a new fiscal cycle starts. Validation: Validation of input data. Intercompany Eliminations: Generation of all the consolidation entries for the desired groups of entities (eliminations, adjustments, re-classifications, minority calculations, etc.)

Consolidation business rules allow the automated processing of data to render a consolidated set of financial statements. This is commonly thought of as eliminations of

investments in subsidiaries, adjustments of minority interest, reclassifications and any other postings depending on the nature of the consolidation methodologies required. The enabling of this functionality is done through a combination of ABAP and business rule tables. Note: Only when the consolidation type application are created and the business rule Automatic Adjustments are created, the pre-delivered business rule library tables will be activated and shown from Admin Console UI, which includes Method Library, Elimination Rule and Rule formula tables, as only Automatic Adjustment (such as Minority posting, Investment adjustment) utilize those Elimination rules and formulas for the calculation of actual postings. Before the consolidation type application is created, from UI of BPC, the user will not be able to display the rules and the pre-delivered library tables content are stored in following ABAP database table. Method: UJP_Method Rule Header:UJP_RULEH Rule Formular: UJP_RULE In Step 4, uncheck the dimensions check as shown in order to select the desired dimensions required for legal consolidation.

Figure 4: De-select the dimensions box to allow you to specify the relevant dimensions for your consolidations application

In this step, set dimensions to be included in the consolidation application and also set the secured dimension to control the security via BPC member access profiles.

Figure 5: Selecting the dimensions for your consolidations application

Normally the Entity and Category dimension are set as secured dimension for member access control.
For Group dimension here, it stores both group currency and reporting currency and also consolidation groups. The MAIN cube must contain a CURRENCY dimension to store the translated amounts. The consolidation entries, as generated by the consolidation process, will also be stored by GROUP in the same CURRENCY dimension (this is why we refer to it as the CURRENCY / GROUP dimension). The reason for this overlapping of dimensions is that, in the great majority of cases, the CURRENCY dimension and the GROUP dimension do not intersect. In other words the Entity details are either in local currency - LC - or in a reporting currency say USD or are consolidated into a given GROUP say G1 - in which case specifying the group is enough to identify its currency. As a result of this, we can simply define the intersections ENTITY / LC, ENTITY / USD and ENTITY / G1, to be able to store all required information.

Any additional dimension is optional in the MAIN cube, as far as the currency translation is concerned. For consolidation purposes however, some other requirements come into play, as described below: The application may have an INTCO dimension, but it is not required for the Consolidation procedure to work, unless some elimination rule makes an explicit reference to this dimension. The application may have a FLOW dimension. This dimension is optional, but, if it exists, it can be used (1) By the currency translation procedure, to detail the changes in the balance sheet generated by fluctuations in the exchange rates (2) By the consolidation procedure to detail the eliminations applied to the movements of the balance sheet accounts. A DATASRC dimension may exist in the MAIN cube, but it is not required by the currency translation. If it exists, however, the currency translation will be able to recognize which members of such dimension should be translated and which ones should be just copied as they are into the destination currency. On the other hand, this dimension is required for the consolidation procedure to work.

Additional (user defined) dimensions can be added to the MAIN cube (like product, market, division, etc.), as desired by the administrator. The Consolidation Engine will be able to recognize their existence and take them into account in the process, and even apply some custom behavior to their members. Here is the Legal Application created with all the dimensions shown.

Figure 20: The dimensions of the consolidation application we just created.

Set the Application Parameters


Application parameters provide a nice collection point for properties that affect how applications are used. The Legal application is an excellent example because it requires quite a few settings. In this case, some of the more important parameters are used to determine how organizational information from the ownership application is used. Go to BPC Administration (Web) -> Set Application Parameters -> Change the current view and set to the consolidation cube Here is the table of the business rule activation during the creation of Consolidation type application.

Key ID

Description
If you want to use the work status feature, you must use this field to identify the hierarchy level (H1, H2, H3, ..., Hn) for which you want to track the work status of deliverables. You can define only one hierarchy for each application within an application set. For alternate organizations, No Status displays when viewing those members in the work status screen. If this field is blank, work status tracking is disabled. When set to ON, various BPC modules write detailed runtime statistics to tables UJ0_STAT_HDR and UJ0_STAT_DTL. You can use this information to monitor system performance. Valid values are ON and OFF.

APPROVALORG

BPC_STATISTICS

CALCULATION INTCOBOOKINGS VALIDATIONS USELIM FXTRANS OPENINGBALANCE

Allows the use of the Calculation business rule tables. Default = 1 Allows the use of the Intercompany booking business rule tables. Default = 1 Allows the use of the validation business rule tables. Default = 1 Allows the use of the business rule tables for US Eliminations. Default = 1 Allows the use of the currency conversion business rule tables. Default = 1 Enables the business rule table for balance carry forward. Default = 1 A custom Journal module assumes that the property named UB must be present in the Account dimension to further filter the journals to re-open. The default is Group. If Group, then there is no need to modify the account dimension. Name of the linked Ownership application. The default value is OWNERSHIP. The 3rd party member in the Intercompany dimension to which all ownership calculations are posted. The default value is I_NONE, which should also be a member ID in the INTCO dimension in the Ownership application if using dynamic hierarchies. Member id of the ownership account that specifies the Position of a consolidation entity within the group. The default value is PGROUP. Member ids of the ownership account dimension that store methods, %con (% consolidation), %own. These will appear in the dynamic hierarchy editor. The default value is METHOD,POWN,PCON. The property name in the Groups dimension to define the hierarchy used in the dynamic hierarchy editor. The Group property that will contain the legal rollup members. This parameter is used with dynamic hierarchy statutory applications when defining fixed hierarchies. The value must match the value in the ParentProperty property value of entities in the statutory application's supporting Ownership application. The default value is PARENT_GROUP. The consolidation logic requires the Ownership application to be listed here as well. The name of the Ownership application. If this parameter does not exist, the consolidation procedure by default searches for an application named OWNERSHIP. This parameter controls whether data is input in year-to-date format. Valid options are 1, which means YTD format; or 0, which means periodic format. (Optional) Figure 21: Application parameters

JRN_REOPEN_PROPERTY ORG_OWNERSHIPCUBE

ORG_INTCO

ORG_ACCOUNTOWN

ORG_ACCOUNTLIST

ORG_PARENTPROPERTY

OWNERSHIP_APP

YTDINPUT

To set the Application parameters for the LEGAL application do the following steps 1. Open the BPC Administration webpage. If you have closed it, you need to go back to the BPC launch page and click the BPC Administration. Icon. 2. Set the Application Set to the name of your Appset and the application to the name of the Ownership application in the top right corner of the Action Pane. You may need to click on Available Interfaces / BPC Administration to go back to the BPC Administration webpage after you changed the Appset/Application

3. Click on Set Application Parameters.

Here are the relevant application parameters and the recommended values that should be set through the Web Admin. Please refer to the Admin guide on how to set these values.

Key ID APPROVALORG FXTRANS INTERCOMPANY JRN_BALANCE JRN_POST_OVERWRITE OPENINGBALANCE ORG_ACCOUNTLIST ORG_ACCOUNTOWN ORG_INTCO ORG_OWNERSHIPCUBE ORG_PARENTPROPERTY OWNERSHIP_APP VALIDATIONS WORKSTATUSVALIDATE YTDINPUT

Value H1 1 1 1 Y 1 METHOD,PCON,POWN PGROUP I_NONE OWNERHSIP PARENT_GROUP OWNERSHIP 1 Yes Yes Figure 22: Consolidation Application parameters

YTDINPUT setting One of the most important application parameter in web admin parameter that should be set is YTDINPUT. This defines the application type whether it is periodic or YTD (Year to Date). This parameter plays important role since it controls how the data is stored in the cube. Most source systems store balances on a periodic basis (whether it is daily, weekly, monthly, fiscal periods, etc). With this method, periodic data must be accumulated for year-to-date reporting (except for Balance Sheet accounts, which gets the value from the last period). However, in some business cases, calculations should occur on a year-to-date basis. If YTD is required, applications can store the data on a YTD basis. When data is entered into YTD, its periodic values used for reporting purposes, are calculated as the difference between the current period and the last period (again, Balance Sheet accounts would simply take the value from the last period). January February March April 100 200 0 100 100 300 300 400

Periodic YTD

Figure 23: Year to Date vs. Periodic By default, applications are PERIODIC. You can change the YTDINPUT parameter to a value of 1 to turn it into an YTD storage type.

Business Rules Interface


SAP Business Planning and Consolidation delivers pre-defined functions designed to calculate and post amounts required supporting common accounting activities such as: Currency translation Matching and elimination of inter-unit balances. The complete list of functions will be discussed in the next section.

Customizing for Table Driven ABAP Program


In order to give our customers the flexibility to customize these functions to meet their specific requirements table-based logic is applied. For each pre-defined data packages and script logic, one or more Business Rule tables exist in which the business user can configure rules. The consolidation engine uses the Table Driven ABAP Programs to perform all the appropriate calculations on a user-selectable region of data, and write the calculated results into the database Table based logic (Business Rules) provides the flexibility for a customer to customize certain delivered functions (logic), to meet their specific business needs, without having to understand scripting/programming. Here is an example of the currency conversion business rule table shown below:

To run these programs, you must use of the designed Data Manager Packages through SAP BI Process Chains to invoke the Programs directly from the K2 scripts logic file and pass the appropriate parameters to the data package. Here is the full list of consolidation process that BPC7 supports with its BI Process Chain and Script File and corresponding Business Rules. Script Logic Files Name
COPY_OPENING.LGF VALIDATION.LGF

Consolidation Task Balance Carry Forward Validation

Process Chain Name /CPMB/OPENING_BA LANCES /CPMB/VALIDATIONS

Business Rule Table Name Carry-forward rules Validation rules and

Validation details Currency Conversion Intercompany Reconciliation Intercompany Balance Booking Legal Consolidation (Elimination and Adjustment) Account Calculation (Cash Flow functioned) US widely used Intercompany Elimination /CPMB/FX_RESTATM ENT /CPMB/ICDATA /CPMB/ICBOOKING /CPMB/LEGAL_CONS OLIDATION /CPMB/RUNCALCAC COUNT /CPMB/IC_ELIMINATI ON Currency Conversion Rules No rules needed Intercompany booking Automatic Adjustments and Automatic Adjustment Details

FXTRANS.LGF ICDATA.LGF ICBOOKING.LGF

CONSOLIDATION.LGF

CALCACCOUNT.LGF

Account Transformation

ICELIM.LGF

US Elimination

For each process, the pre-defined Data Manager Packages with their associated logic scripts and rule tables are executed, performing the consolidation task according to the business rule customization. Any specific business requirement needs to be configured in corresponding Business Rule Tables. With this approach the customer has the possibility to freely decide when and how a process should be triggered. We can, for example, invoke a currency conversion directly from the DEFAULT logic, whenever a value has changed via Web, Excel or via a data load, or we can decide to run one or more consolidation processes in a batch mode, using some customized data package that invokes an appropriately-designed logic file. Also, we can combine one or more of these specialized processes with other custom-defined calculations, like allocations or modeling formulas or whatever else may be defined using our general-purpose logic scripting technique. The details steps of how to execute each tasks is described in separate How to Guide available in the SDN such as How To setup Currency translation for Consolidation Application using BPC for SAP NetWeaver How to setup Breakdown validation using BPC 7.0 for SAP NetWeaver How to use COPYOPENING using BPC 7.0 for SAP NetWeaver.

Execute consolidation task


In BPC 7.0 for SAP NetWeaver Data Manager Packages are implemented as process chains and allow you to do common data manipulation activities. The packages that come with BPC 7.0 are designed to be dynamic so that you do not need to modify the packages in order for them to work with your applications and dimensions. Data Manager Packages allows the user to manage data within BPC applications and dimensions.

Here are Financial Packages that can be used for the consolidation process apart from the Standard and Administrative Packages. Process Chain Template BPC: Default Formulas Logical BPC: Allocation BPC: Calculate Ownership BPC: FX Restatement BPC: IC Elimination BPC: ICBooking BPC: ICData BPC: Legal Consolidation BPC: Opening Balances BPC: Run CalcAccount BPC: Clear the Journal Tables BPC: Export the Journal Tables BPC: Restore Journal Tables Description This package executes default formulas stored in your default.xls file. The package runs the Allocation logic. Technical Name /CPMB/DEFAULT_FORMULAS /CPMB/ALLOCATION

The package runs the CalcOwnership logic. /CPMB/OWNERSHIPCALC This package is used for currency translation. The package runs the FXTrans logic. This package is used to Perform InterCompany eliminations. The Package runs the ICElim logic. The Package runs the ICBooking logic. The Package runs the ICData logic. The Package runs the LegalConsolidation logic. The Package runs the OpeningBalances logic. The Package runs the CalcAccount logic. /CPMB/FX_RESTATMENT

/CPMB/IC_ELIMINATION

/CPMB/ICBOOKING /CPMB/ICDATA /CPMB/LEGAL_CONSOLIDATION /CPMB/OPENING_BALANCES /CPMB/RUNCALCACCOUNT

Clears Journal tables and creates an output /CPMB/CLEAR_JOURNALS file. Exports Journal tables to an output file /CPMB/EXPORT_JOURNAL

Allows you to load Journal tables from a File /CPMB/RESTORE_JOURNALS

Add the data Manager Packages for consolidation application.


Login to BPC for Excel Interface -> eData-> Organize Data Package List -> Add a data Package-> look for the consolidation task related pre-delivered SAP BI Process Chain and select to add.

Figure 6: Adding the Balance Carry forward package

The DM package could also be modified for its dynamic script to achieve the specific parameter passing requirement and reassign of the table driven program used scripts logic file (LGF).

Figure 7: Modifying the delivered Data Manager package

To Modify DM Package, Go to BPC for Excel Interface -> eData-> Organize Data Package List -> Select the package and right click -> Modify Package -> Click View Package from Modify Package Screen -> The Dynamic Script Editor for Data Manager should be prompted up -> Click Advance button -> Edit the script of dynamic selection screen generation

Figure 8: The underlying code of the data manager package

Create Script Logic files (LGF)


Script Logic allows the user to define formulas that perform calculations on SAP Business Planning and Consolidation 7.0 members and data. You can create two different types of logic: Dimension Member Formulas Script logic (K2) Each type has advantages and disadvantages. Logic is application specific and all Script Logic statements are Case-Insensitive. Login to BPC Admin Console -> Expand Consolidation Application -> Go to Script Logic Editor -> Create an LGF file by using K2 script supported by BPC 7.0 for SAP NetWeaver

Figure 9: Script Logic

Note: All consolidation logic file (LGF) examples are stored in the File Service Directory: \Root\Webfolder\ApShell\Systemlibrary\LogicLibrary. These examples are a great help when it comes to understanding the K2 syntax. These examples can be copied and reused in a customer application rather than having to create all logic from scratch. These script logic files can be accessed through T-Code UJFS for File Service UI: as shown below:

Figure 10: Transaction UJFS allows you to access the File Service

Note: The K2 Logic File name must be identical as the string defined with the data package.

Maintain the business rule table


SAP Business Planning and Consolidation delivers certain pre-defined functions designed to calculate and post amounts required to support common accounting activities such as: Currency translation Matching and elimination of inter-unit balances. In order to allow a customer the flexibility to customize these functions to meet their specific requirements table-based logic is applied. For each pre-defined function, one or more Business Rule tables exist in which the business user can configure rules such as: What balances should be read in order to calculate an amount to be posted. What are the posting rules for the calculated amount (i.e. what account and data source does one wish to post the calculated amount under). Table based logic (Business Rules) provides the flexibility for a customer to customize certain delivered functions (logic), to meet their specific business needs, without having to understand scripting/programming. The following Business Rule (table-based logic) Functions are delivered with BPC 7.0:

Currency conversion: Conversion of local currency data in the desired reporting currencies. Account Transformation: To calculate and store amounts which are required for purposes of account transformation. Intercompany bookings: Matching of inter-company transactions. US Eliminations: Specifically designed to address the posting of inter-company eliminations in simpler scenarios where a full legal consolidation application is not required. Opening Balance: Initialization of beginning balances when a new fiscal cycle starts. Validation: Validation of input data. Automatic Adjustments: Generation of all the consolidation entries for the desired groups of entities (eliminations, adjustments, re-classifications, minority calculations, etc.) The details of each business rules please refer the How to guide for each topic for example the Currency conversion can be check with How to do Currency Translation for Consolidation Application in BPC for SAP NetWeaver, How to setup Breakdown validation using BPC 7 for SAP NetWeaver, How to use COPYOPENING using BPC 7 for SAP NetWeaver etc. Login to the BPC Admin Console -> Expand Consolidation Application -> Go to Business Rule Editor -> Select the rule table to create the content of the rules according business requirements.

Figure 11: Business Rule Editor

Loading data
Loading exchange rate to rate application
The Rate application should store the exchange rates for doing currency conversion. There are several ways to upload the data to rate application, such as utilize the data manager package Import, or use dynamic templates to send data from the input schedule. Please refer to the How to do Currency Translation for Consolidation Application in BPC for SAP NetWeaver for detail steps on how to load the rates. Please also refer to the How To load exchange rates from TCURR table that is available in SDN.

If EVDRE are used, the Rate Account type dimension and Input Currency dimension can be set in Row and Time dimension can be set in column. Save the EVDRE as input schedule to send data to the Rate Application. Such input schedule could also be saved as a template in library for sharing and reuse.

Figure 30: Dynamic Input Schedule template (Nested Row) for Rate Input

Input ownership data and calculate ultimate ownership


As the consolidation scope (such as ownership percentage, group/unit hierarchy) is time dependent and given the fact that the dynamic hierarchy editor is not available in BPC 7.0 for SAP NetWeaver, our recommendation is to leverage the steps suggest below on how updating the ownership cube with ownership details. (Note that BPC 7.5 for SAP NetWeaver offers the dynamic hierarchy editor functionality) If the way direct share input is preferred by business, Step1: Input direct ownership % between Investor unit (entity) and investee unit (Intco) under a group dimension member (most often LC could be used) by category and time. Member POWN in O_Acct dimension stores this information.

Figure 31: Maintaining ownership %, consolidation method, and consolidation group assignment for each entity

Step2: Input the consolidation method of each entity under each consolidation group. 90 Represents holding company in a group 86 Purchase (Global) 70 Proportional 30 Equity Member Method in O_Acct dimension stores this information. Step3: Input the position of each entity in a consolidation group. Value 1 represents in the group Other value represents not in the group. Member PGROUP in O_Acct dimension stores this information. The input schedule can be built to input above ownership details into cube. The Dynamic Consolidation Hierarchy Maintenance schedule shown below shows all the details including the consolidation method and positioning in a consolidation group. Both of the factors can be maintained with using this input schedule:

Figure 312: Maintaining Position in group, consolidation method assignment for each entity

Step4: Run the pre-delivered DM package Calculate Ultimate Ownership to calculate the ultimate ownership that is calculating how much each consolidation group owns of each entity. The result of this calculation - the ultimate ownership - is stored under the member I_NONE of IntCo dimension, and POWN, PGROUP, METHOD member has the groupown-entity value described above. The pre-delivered DM package Calculate Ultimate Ownership basically runs based on what the Direct Percent Ownership is entered into a selected account for each owner entity and for each owned intercompany entity. For example if, in period 2009.JAN for category ACTUAL, entity A owns the companies B and C by 80% and 30% respectively, the following information should be entered: CATEGORY ACTUAL ACTUAL TIME CURRENCY 2009.JAN LC 2009.JAN LC ACCOUNT POWN POWN ENTITY INTCO A I_B A I_C VALUE 0.8 0.3

Note: Since information for the CURRENCY dimension is irrelevant, so the non-group member LC is used.
For example if in category ACTUAL and period 2009.JAN, entity A is the holding company of CG1, the following information should be entered:

CATEGORY ACTUAL

TIME CURRENCY 2009.JAN CG1

ACCOUNT METHOD

ENTITY INTCO VALUE A I_NONE 90

Here 90 is the value corresponding to the consolidation method for the holding company.

Note: Here the information for the INTCO dimension is irrelevant, so the non-intco member I_NONE is used. When the Calculate Ultimate Ownership package is executed after selecting the category, period, and group for which the Ultimate Percentage Ownership must be calculated. The result will be stored in the POWN account for each entity of the selected group, like in the following example CATEGORY ACTUAL ACTUAL ACTUAL TIME 2009.JAN 2009.JAN 2009.JAN CURRENCY CG1 CG1 CG1 ACCOUNT POWN POWN POWN ENTITY A B C INTCO I_NONE I_NONE I_NONE VALUE 1 0.8 0.3

If the business users prefer to enter the ultimate share directly rather than inputting the ownership percentages of the direct parent, then, the only step required is to input the groupown-entity value for POWN, PGROUP, and METHOD under I_NONE under IntCo dimension. Check Ultimate Ownership Report after running the Group Share Calculation (DM package).

Figure 33: Checking the Ultimate Ownership calculation

Loading the Financial data


After loading the financial data, it is best practice to use a BPC report to validate that the numbers loaded reconcile with the numbers in the source system. In the following example data was loaded for 2008.MAR for the Japanese Entity and the reporting currency is USD. So we will show the source data loaded through the report.

1. Create a report using standard EVDRE to validate and use the RptCurrency in the column and Account in the row. Here is an example to validate the data loaded for MAR 2008. Note: The exchanges rate was loaded for 2007.DEC and 2008.MAR in the Rate application. . 2. Click on Expand all icon and check that the LC is populated and USD will be displayed as 0.00.

Figure 34: Report Parameters

3. Here is the report that shows the data that is available in 2008.MAR.

Figure 135: Sample report displaying the Japanese data loaded in local currency for March 2008

Work Status Setting


Work States Setting (AppSet dependent)
The Work Status is a mechanism that allows submitted data to be tracked, approved and locked using customizable work states definitions that meet the business needs. The work status serves the need to secure the data in their application beyond access controls for users. With the release of BPC7.0, the system is capable of providing sufficient control on changing the data to database. Work status such as Unlocked, Submitted, and Locked etc. can be set on a data set, which could be based on dimensions of the data. The term locking is generically used to describe data that is not available for change either on a temporary or permanent basis. During the specific business process, end users can use the work states to apply a label to a specific current view intersection for the purpose of locking data so it can be reviewed, approved, etc. This is actually a very common requirement, for example, during month-end close business process requires that a specific set of data is locked down so that accurate month-end reports can be created. After a data submission, the owner can set the status of the data to 'Submitted.' This locks the data intersection from subsequent submissions. In the other hand the locking strategy of the data is also possible for user to customize according to various business needs. For example, between bottom up and top down data processing model, user can have the flexibility to work with the system on how the locking logic applies. Login to BPC Admin Console -> Work States Setting -> Add the states according the business needs -> Set for different interface for the Approval privilege level for each work states just created -> Set appropriate privilege for changing work states.

Figure 36: Defining Work States

Work Status Setting (Application Dependent)


At specific application level work status can be configured by user according the specific requirement. At application level, the system provides user the interface to define below settings, 1) Approval organization: work status can be configured by dimensions. User can decide which dimension contains the approval organization. The approval organization is the hierarchy for which user could track the status of the deliverables. 2) Rules: Top down or bottom up? The default rule for managing work status is bottomup method. That is, the status of a parent cannot be higher than the status of its children. Of course user can set work status to top-down. For bottom-up behavior, the maximum state a parent can be set to is the lowest state of its immediate children. The minimum state a child can be set to is the state of its immediate parent. For example, if the parent state is Submitted, the child state must be at least Submitted. 3) Within the interface of application work status setting, all the dimensions included in the application are also available for user to pick up to be used to track work status setting. If user decides not to use certain dimension to track work status, that dimension must contain a member that is included in the validation process of work status to make sure the data is validated before being locked. Login to BPC Admin Console -> launch the application -> Work Status Setting-> Set the lock dimension and owner dimension.

Note: Owner dimension must contain the owner property dimension, which hierarchy controls the work states change hierarchy. Requirement to define a dimension with an owner property, this dimension must also contain a hierarchy to enable the pushing of the work status. The dimension with the owner property will drive parent/child relationship for setting status. In addition to the customizing functionality, the work status combines the above states with specific functionality based on owner property defined in a specified dimension. The user must define either top down or bottom up rules to apply to an application (currently an application setting).

Figure 37: Defining Work States at Application level

Journal Template and Validation Setting


Journals basically allow users to make adjustments to data in the database, typically as part of the month-end or quarter-end process. During review and analysis step, journals allow user to capture an audit trail of the changes/adjustments made to the database. Here is an example to explain the possible journal process during company closing.

- After loading general ledger data into an application using Data Manager and then the processor should be able to review the data and use journal entry to make adjustments if there is any correction/reclassification needed. - When journal entries are saved and posted, all adjustments to data can be tracked and reported on. For example, it is possible to run reports on the changes by amount, date, user, and several other properties to review and analyze. Validations on the other hand are designed to prevent incorrect records from being saved to the cube. The user controls what is deemed an incorrect record. An example of an incorrect record is one where you have specified an intercompany Account, but left the Trading Partner dimension empty. Please note that in BPC 5 and 7M, validations have been implemented but only Journals data is checked for validation. Therefore, it is very easy to end up with invalid records in your application as all other modules (Excel, Web, Data Manager, etc) will not be validated. The existing Journals validation functionality is not implemented in BPC 7 for SAP NetWeaver. Instead, this module is intended to supersede this functionality. In BPC 7, it is not possible (or supported) to get data into a cube without going through the Write-Back module. Therefore, we implemented the validations in writeback, to ensure that invalid records can not get into the cube from any source including journals, all Data Manager Packages, and manual data input.

Journal Template
The primary requirement for Journals is to track changes to data after the initial source data is input into the application. For example, the general ledger information is loaded into the application via Data Manager. The application users can adjust this data but also track and report on the changes by amount, date, user, etc. To create the journal template login to BPC Admin Console -> launch the application -> Journals -> to create a journal template. Once the template is created, the dimension in an application cant be deleted from the application any more as well as all data.

Figure 38: The journal template allows users to enter journal entries in BPC to adjust the source data loaded

Caution: If you have already created a journal template, creating a new template that changes the structure of the journal entries deletes the old template and all journal entries associated with that template. This removes your audit trail, even though changes made to the application data through posted journal entries are maintained. If you recreate the journal template, but do not change the structure of the template keeping all header and detail dimensions the same then you have the option to keep the existing journal entries

Validation Setting
Validations are designed to prevent incorrect records being saved to the cube. In BPC 7, it is not possible (or supported) to get data into a cube without going through the Write-Back module. Therefore, we implemented the validations in write-back, to ensure that invalid records can not get into the cube from any source not only for journals, but also for all DM package and manual data input. An example for this is if a specified intercompany account with empty Trading Partner dimension will be blocked from writing into the cube. To customize Validation, Go to SAP ABAP systems with GUI UI -> go to Transaction code UJ_VALIDATION to configure the validation framework and customize the validation rules according business requirement. Refer to the How To do Breakdown Validation in BPC for SAP NetWeaver on this for detail steps on how to setup the validation.

Figure 39: Transaction code "UJ_VALIDATION" allows you to turn on the validation rules

The validation rules are defined in the configuration screen according to the business requirements Please refer to the How to guide on Validation setup in BPC 7.0 for SAP NetWeaver for detail steps on how to setup the validation.

Figure 40: Validation Maintenance screen to create the rules

Rule Description: Intercompany accounts require Trading Partner. Assigned Members: All Intercompany accounts.

Validation Logic: INTCO Dimension for Dimension <> for Operator I_NONE for Members.