How To Setup a Legal Consolidation Application using SAP...

SAP Business Objects EPMHow-to Guide

How To Setup a Legal ConsolidationApplication using SAP BPC 7.0version 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 ortransmitted in any form or for any purpose without theexpress permission of SAP AG. The information containedherein may be changed without prior notice.

Some software products marketed by SAP AG and itsdistributors contain proprietary software components ofother software vendors.

Microsoft, Windows, Outlook, and PowerPoint areregistered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, ParallelSysplex, 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 aretrademarks or registered trademarks of IBM Corporation.

Adobe, the Adobe logo, Acrobat, PostScript, and Readerare either trademarks or registered trademarks of AdobeSystems Incorporated in the United States and/or othercountries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registeredtrademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame,WinFrame, VideoFrame, and MultiWin are trademarks orregistered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks orregistered trademarks of W3C®, World Wide WebConsortium, 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 andimplemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAPNetWeaver, and other SAP products and servicesmentioned herein as well as their respective logos aretrademarks or registered trademarks of SAP AG inGermany and in several other countries all over the world.All other product and service names mentioned are thetrademarks of their respective companies. Data containedin 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 affiliatedcompanies ("SAP Group") for informational purposes only,without representation or warranty of any kind, and SAPGroup shall not be liable for errors or omissions withrespect to the materials. The only warranties for SAPGroup products and services are those that are set forth inthe express warranty statements accompanying suchproducts and services, if any. Nothing herein should beconstrued as constituting an additional warranty.

These materials are provided “as is” without a warranty ofany kind, either express or implied, including but notlimited to, the implied warranties of merchantability,fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind includingwithout limitation direct, special, indirect, or consequentialdamages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of theinformation, text, graphics, links or other items containedwithin these materials. SAP has no control over theinformation that you may access through the use of hotlinks contained in these materials and does not endorseyour use of third party web pages nor provide any warrantywhatsoever relating to third party web pages.

SAP NetWeaver “How-to” Guides are intended to simplifythe product implementation. While specific productfeatures and procedures typically are explained in apractical business context, it is not implied that thosefeatures and procedures are the only approach in solving aspecific business problem using SAP NetWeaver. Shouldyou wish to receive additional information, clarification orsupport, please refer to SAP Consulting.

Any software coding and/or code lines / strings (“Code”)included in this documentation are only examples and arenot intended to be used in a productive systemenvironment. The Code is only intended better explain andvisualize the syntax and phrasing rules of certain coding.SAP does not warrant the correctness and completeness ofthe Code given herein, and SAP shall not be liable forerrors or damages caused by the usage of the Code, exceptif such damages were caused by SAP intentionally orgrossly negligent.

Disclaimer

Some components of this product are based on Java™. Anycode change in these components may cause unpredictableand severe malfunctions and is therefore expressivelyprohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is onlyto be used by SAP’s Support Services and may not bemodified or altered in any way.

Document HistoryDocument Version Description

1.10 << Enter your summary of changes in this version >>

1.00 First official release of this guide

Typographic ConventionsType Style Description

Example Text Words or characters quotedfrom the screen. Theseinclude field names, screentitles, pushbuttons labels,menu names, menu paths,and menu options.Cross-references to otherdocumentation

Example text Emphasized words orphrases in body text, graphictitles, and table titles

Example text File and directory names andtheir paths, messages,names of variables andparameters, source text, andnames of installation,upgrade and database tools.

Example text User entry texts. These arewords or characters that youenter in the system exactly asthey appear in thedocumentation.

<Exampletext>

Variable user entry. Anglebrackets indicate that youreplace these words andcharacters with appropriateentries to make entries in thesystem.

EXAMPLE TEXT Keys on the keyboard, forexample, F2 or ENTER.

IconsIcon Description

Caution

Note or Important

Example

Recommendation or Tip

Table of Contents

1. Business Scenario ..........................................................................................................2

2. Background Information .................................................................................................3

3. Prerequisites....................................................................................................................3

4. Step-by-Step Procedure ..................................................................................................4Application Set Creation ....................................................................................................4

Login in to Apshell ....................................................................................................4Create Appset ...........................................................................................................5Set AppSet Parameters ............................................................................................6

Master Data (Dimensions) Set-up ......................................................................................7Set-Up Dimensions in Dimension Library ..................................................................8

Required Dimension properties ........................................................................................ 12Account Dimension ................................................................................................. 12Category Dimension ............................................................................................... 13Data Source Dimension .......................................................................................... 15Entity Dimension ..................................................................................................... 16Currency/Group Dimension(s) ................................................................................. 16Flow Dimension ...................................................................................................... 19Maintain property .................................................................................................... 20Maintain dimension members ................................................................................. 21

Create/Modify the Application .......................................................................................... 23Rate application: ..................................................................................................... 24Ownership application: ............................................................................................ 25Consolidation (Main) application: ............................................................................ 28

Set the Application Parameters ........................................................................................ 34YTDINPUT setting .................................................................................................. 36

Business Rules Interface ................................................................................................. 37Customizing for Table Driven ABAP Program.......................................................... 37

Execute consolidation task .............................................................................................. 38Add the data Manager Packages for consolidation application. ............................... 39Create Script Logic files (LGF) ................................................................................ 41Maintain the business rule table .............................................................................. 43

Loading data ................................................................................................................... 44Loading exchange rate to rate application ............................................................... 44Input ownership data and calculate ultimate ownership ........................................... 45Loading the Financial data ...................................................................................... 48

Work Status Setting ......................................................................................................... 50Work States Setting (AppSet dependent) ................................................................ 50Work Status Setting (Application Dependent) .......................................................... 51

Journal Template and Validation Setting .......................................................................... 52Journal Template .................................................................................................... 53Validation Setting .................................................................................................... 54

1. Business Scenario

When closing a financial period, the finance department faces the task of consolidating theirnumbers 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 Ultimate ownership calculationo elimination entries for intercompany revenue, investments and profit in

inventoryo adjusting entrieso re-classificationso minority calculations

other calculations Final Validation Report generation

The Legal application as well as all the legal/statutory consolidation business rulesfunctionality that enables our customers to perform many of the “number-crunching” activitiesrequired in the generation of consolidated statements of a group of legal entities need to bebuilt

Please note that not all of the above mentioned functions will be covered in detail in thisdocument.This “How to Guide” focuses specifically on the dimension properties and relevant settingrequired for the various dimension, application and task in order to successfully performLegal consolidation using BPC 7.0 for SAP NetWeaver. This guide will also briefly describehow to setup the Currency translation, inter unit elimination, COPY opening etc. using theBusiness Rules tables and script logic using the “BPC Admin”. Furthermore, it will be shownhow 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 mathematicalfoundation for the BPC application thus allowing users to manage both - management andlegal consolidation reporting.

Following steps outline what is being covered in this guide in order to set up yourconsolidation 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 Setprovided 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 ApShellstraight and reflect the baseline requirement for customer to start a new implementation andensure there is nothing that will have to be re-engineered that is related to the customer’smaster/meta data, on the other hand, need minimize the “taken off” work on ApShell atcustomers.

This document is intended for consultants or administrators who understand the basicelements that need to be set up in order to make the consolidation engine work. It alsoprovides 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 BPCconsolidation engine to meet certain legal requirements such as accounting principles likeIFRS 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 dimensionsproperly. This document walks through the required dimensions and properties for setting upthe legal consolidation framework.

Application Set Creation

Login in to ApshellOnce installation and ApShell activation have been completed, you should be able to log onAdmin 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 onAdmin Console or access ABAP server from GUI and run the transaction “RSA1” to check theBI Infoprovider “APSHELL” and its structure.

Create AppsetIn Admin Console, Copy ApShell into the target AppSet as a starting point to begin buildingout 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 applicationset for planning or reporting as a basis to build consolidations allows you to share therelevant dimensions – such as account - with your consolidation environment.

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

Key ID Description

ALLOWEXTENSIONS

Defines the file extensions the system permits users to upload to theapplication, data manager files, content library files, web ready files,and library files. When set to ALL, BPC allows all extensions. Thedefault value is ALL. (Required)

ALLOW_FILE_SIZEThe maximum file size BPC permits users to upload. The defaultvalue is 100 MB. (Required)

AVAILABLEFLAG

Controls whether the system is offline or not. Yes means the systemis online and available for sending data to the database. You cantake the system offline by changing the value to No. (Required)

AVAILABLEMSG

The message that displays to users who try to access an applicationthat is offline (AVAILABLEFLAG = No). (Required) Example: The message could be “BPC is temporarily unavailabledue to scheduled maintenance. Please try again later.”

AVAILABLEURL

The name of the Web page to display to users who try to access anapplication that is offline (AVAILABLEFLAG = No). (Required) Example: The url could be /osoft/NotAvailable.asp.

DEFAULT_EXTENSIONS

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.

LANDINGPAGEITEMTo customize the Getting Started page on BPC Web, contact yoursystem administrator.

LOGLEVEL

Used by application set to control the level of the ABAP log, whichyou 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.

MAXLRCOLUMNS

The maximum number of columns to display in a live report in BPCWeb. The value includes header and data columns. Example: If you specify a value of 5, one heading column and fourdata columns are displayed.

MAXLRROWS

The maximum number of rows to display in a live report in BPCWeb. The value includes header and data rows. For example, if youspecify a value of 5, one heading row and four data rows aredisplayed. Example: If you specify a value of 5, one heading row and four datarows are displayed.

SMTPAUTH

The authentication method of the SMTP server. (Required)0 = Anonymous1 = Basic2 = NTLM

This setting does not change the method on the SMTP server, butmust match the type of authentication enabled on it. Failure to setthis appropriately can result in errors from the email server.

SMTPPASSWORDThe password for the user name defined as the SMTPUSER(Required)

SMTPPORTPort number for your SMTP email server. Default is port 25, thedefault SMTP server port number. (Required)

SMTPSERVERThe name or TCP/IP address of the SMTP email server the systemuses to send email. (Required)

SMTPUSERThe user name from which email from the system originates.(Required)

TEMPLATEVERSION

Current version number of the dynamic templates in your applicationset. Whenever you add to or change your input schedule or reportdynamic templates, you should increment this version number sothat users will automatically get the new templates downloadedwhen they log on to this application set. (Required)You can also reset the template version from the Admin Console.

SYSTEM BPC 7 Internal system Parameter, default value = 1MESSAGE BPC 7 Internal system Parameter, default value = BlankSTATUS 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 toretrieve the information necessary to perform its calculations.

The Legal or Main application - This Consolidation Type Application is the applicationwithin which the respective consolidation entries for e.g. currency conversion orintercompany eliminations are written

The RATE application - The currency conversion process uses a RATE application, tolook up the appropriate exchange rates for each relevant currency.

The OWNERSHIP application - The Consolidation process uses an OWNERSHIPapplication, to store the definitions of each consolidation perimeter. In particular, suchdefinitions 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 orOWNERSHIP applications, if appropriate.

The RATE application associated to a given application is defined when a new MAINapplication is being created.

The OWNERSHIP application associated to a given application is identified using anapplication parameter as follows:

OWNERSHIP_APP = {app name}If this parameter does not exist, the consolidation procedure will by default search for anapplication named OWNERSHIP.

Each one of the above listed applications must contain some required dimensions, whilesome 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 businessrules. Other dimensions can co-exist in a reporting application but do not impact thebusiness rule function.

All applications must contain the four required ENTITY, CATEGORY, TIME and ACCOUNTdimensions (albeit named as desired). The CURRENCY / GROUP dimension must be sameused in the Ownership application as well as the Main application. Here are some of thecommon member requirements between these dimensions for Legal consolidationenvironment setup described below: The CATEGORY and TIME dimensions can be thesame across the Main, Rate and Ownership applications, or they must contain theappropriate matching members if different.

The ENTITY dimension of the Main application can be the same used in the Ownershipapplication or at least it must contain the appropriate matching members if different.

The CURRENCY / GROUP dimension of the Main application (see Currency/GroupDimension(s)) must be same used in the Ownership application or at least it must contain theappropriate matching members.

In most cases it is preferred to use the same dimensions across applications as it is easier tomaintain.

Note: The Rate application is delivered with Apshell. Most dimension propertiesrequired for the consolidation setup are pre-delivered with the dimensions withinApshell. However it is recommended to verify that before proceeding further.

Set-Up Dimensions in Dimension LibraryFor the consolidation application, the following listed dimensions are mandatory requirements.Therefore, it is advisable to double check that all the dimensions are available in theDimension Library of your consolidation Application Set created from ApShell as describe inthe previous in section

Note: While the dimension names can be chosen as desired it is mandatory that thedimension types match with the ones described in this guide for the correspondingapplications.

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 tosegregate 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 processDepending on your application design, the Entity type can be an operating unit, acost 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 localcurrency and translated values. The currency-type dimension was also usedfor storing the group component of legal consolidation. The group representsthe relationship of entities for a given consolidation result. This group isconsolidated in a single currency hence there is no need to have anotherdimension.

Note: However if the requirement is to have consolidated results in multiple groupcurrencies within a single entity structure, then the customer can continue to use thecurrency 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.).



Entity dimension (R_Entity in ApShell) of Type ‘E’ – Entity.

- This is used to store multiple tables of rates, if desired, otherwise theR_Entity dimension may just be limited to one dummy member, typicallynamed GLOBAL.

Currency dimension (InputCurrency in ApShell) of Type ‘R’ – Currency.

– This dimension is utilized to store for each applicable local currency.



Note: Time and Category dimensions must be shared by all the application involvedin 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” (consolidationmethod), “POWN” (ownership percentage), “PCON” (control percentage ) etc



Entity dimension (Entity in ApShell) of Type ‘E’ – Entity dimension

- Contains the business units that are used to drive the business processDepending on your application design, the Entity type can be an operatingunit, 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



Currency dimension (Groups in ApShell) of Type ‘R’ – Currency dimension- Here the currency-type dimension is used for storing the group component oflegal consolidation. The group represents the relationship of entities for agiven consolidation result. This group is consolidated in a single currencyhence there is no need to have another dimension.

Note: If the requirement is to have consolidated results in multiple group currencieswithin a single entity structure, then the customer can continue to use the currencytype dimension for this purpose or a separate dimension for the group. Groupprovides multiple currencies for a group member. In this case you have to use thegroup type dimension in Ownership application which is available as of BPC 7.5 forSAP NetWeaver

Caution: An appset copied from ApShell will already have the Rate application. Youshould ensure sure to replace the Rate Category dimension with the ConsolidationC_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 Type Legal Ownership RateC_Acct A XIC_Acct AO_Acct A XR_Acct A XFlow S XC_Category C X X XEntity E X XR_Entity E XIntco I X XTime T X X XGroup R X XInputCurrency R XC_DataSrc D X

Figure 4: Dimension in application matrix

Note: IC_Acct dimension shown here is used when separate application is createdfor Intercompany Matching. Please refer to the “How to guide on how to setupIntercompany Matching” for more details.

To create a new dimension, go to the Admin Console -> Go to dimension library. In theaction 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 createdautomatically based on the dimension type. But in order to ensure that consolidation andrelated processes work (such as currency conversion, simulation, automatic adjustment etc.)additional dimension properties are needed to achieve the filter, flagging and calculation ofthe target data. Therefore, we need make sure those properties are maintained with theexpected values for the consolidation process according business requirement.

The following subsections discuss all additional dimension properties (attributes) needed toenable the consolidation process.

These property-lists are check lists for the completeness of master data settings to enable abase line consolidation process.

Account DimensionThe Account dimension defines the chart of accounts for your application, and how thoseaccounts are calculated and aggregated. Any dimension that is assigned the type A isconsidered an Account dimension. Each application can have only one Account-typedimension.

In Apshell we will have four Account type dimensions C_ACCT used in the consolidationapplication, O_Acct used in the Ownership application, P_ACCT used for planningApplication and R_ACCT used in Rate application.

Property Name Length Description of appropriate propertyvalue

ACCTYPE 3 INC for Income,

EXP for Expense,

AST for Asset,

LEQ for Liabilities & Equity.

Note: signed Data = - signed Data when‘ACCTYPE’ = INC or LEQ.

DIMLIST 20 Used to group the accounts for using inBusiness Rules. For example : using theDIMLIST property value can help reducingthe size of the FXTRANS table

RATETYPE 10 Used by the currency conversion businessrules. This determines the business rules tobe applied in translating any given accountfrom local to reporting/group currency.Value is optional.

All ACCOUNTS with no RATETYPE(RATETYPE = blank) will be translated witha factor of 1All ACCOUNTS with the reserved RATETYPE =NOTRANS will not be translated

ELIMACC 20 Used in the Elimination process; whichrepresents the “difference” account, whichthe accounts to be eliminated will be postedinto.

Category Dimension

All applications require a category type dimension. The properties required in this dimensionas described below are for two business rules – currency translation and copy openingbalances.

For simulation purposes, or to analyze the variances from one set of data to another, it isvery often necessary to mix-and-match different rates and values of different data categoriesfrom different time periods. For example a user might want to compare ACTUAL withBUDGET values when both are translated at the ACTUAL rates, or this year ACTUALS withlast year ACTIUALS, both translated using last year rates, etc.

This can be done by either creating some additional simulation CATEGORY (likeActual_at_Budget_rate or the like) or adding an extra dimension to the MAIN cube, where allthe simulated cases can be stored.

The beauty of our solution is that for all the desired simulations there is no need to copyaround any of the input values. A few definitions, stored in some specialized properties of theCATEGORY (or the FX simulation) dimension will tell the translation procedure where toread 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 alsopossible to tell the system to only store the difference between the “default” results and thesimulated scenarios.

When using the simulation categories in the Main cube, simulated translations are stored inadditional members of the CATEGORY dimension. These categories will have non-blankvalues in one or more of the following properties:


FX_SOURCE_CATEGORY 20 The category for the source (LC) data. Ifblank, it is the current category.

RATE_CATEGORY 20 The category from which the rates are readRATE_YEAR 4 The year from which the rates are read.

The value can be absolute (2005, 2006) ora relative value (-1, -2, +1, + 2). If blank it isthe same as the source.

RATE_PERIOD 10 The period from which the rates are readThe value can be absolute (DEC, FEB) or arelative value (-1, -2, +1, + 2). If blank it isthe same as the source.

FX_DIFFERENCE_ONLY 1 If = Y, only the difference between thedefault values and the simulated values isstored.

The business rules for copying opening balances can be controlled by assigning somespecial properties to the category dimensions. If existing, these properties affect theexecution.


CATEGORY_FOR_OPE 20 Blank: the category for the openingbalances is the sameNon-blank: the ID of the category where toread the opening balances from

OPENING_YEAR 4 Blank: the prior yearNon-blank: the year where to read theopening balances from. It can be anabsolute or a relative amount

OPENING_PERIOD 10 Blank: the last period of the yearNon-blank: the period where to read theopening balances from. It can be anabsolute or a relative amount

Data Source Dimension

The data source dimension type is an optional application dimension. However, it hasbecome a best practice standard dimension. The name of dimension can be customized asappropriate for the customer.

Mandatory for the elimination business rules. The DATASRC dimension is requiredfor elimination and/or consolidation business rules. For example the automaticelimination will work only if you have be a base level value and has to have thedatasource type A for it to work.

Optional for the currency business rules as it is not used in the business rules forcurrency 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 Datasource under which the resultant postings shall be posted.

Mand atory fo r th e elimi natio n b usiness rule sOption al fo r the cur ren cy busi ness rulesMand atory fo r th e co nsolida tion busin ess r ules, it is requir e as the results des tinati on


IS_CONVERTED 1 Y if the datasrc has to be convertedN id the datasrc has not to be convertedG If you want to convert the datasrc from acurrency group to a group currency i.e. themembers are copied from the reportingcurrency of the GROUP being translatedinto the currency member corresponding tothe given group. This obviously appliesonly if the translation is run for a GROUPand not for a reporting currency.

IS_CONSOL 1 Blank for management ApplicationY for Consolidation

DATASRC_TYPE 1 I for InputM for manual journal entryA for automatic generated journalL for Level - This is used in consolidationby level to move prior level eliminationsinto a datasrc with propertyDATASRC_LEVEL=Y in the Groupdimension.

COPYOPENING 1 Blank or “Y”: this member is copied“N”: this member is not copied

OPENING_DATASRC 20 Blank: same as the source memberNon-blank: the ID of the desired destinationDATASRC for the copy

Entity Dimension

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


CURRENCY 20 Local Currency used by the Entity.

This currency must be defined in theInputCurrency dimension.

FX_TYPE 20 Special rate for Entity used by the currencyconversion business rules.

Value is optional.

INTCO 20 Used to link intercompany counterpart IDfor elimination. Also known as TradingPartner.

This ID must be defined in the IntCodimension.

OWNER 60 Used for work status

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

Currency/Group Dimension(s)

The currency type dimension is required if the customer reports on local currency andtranslated values. The currency-type dimension is also used for storing the groupcomponent of legal consolidation. The group represents the relationship of entities for agiven consolidation result. This group is consolidated in a single currency hence there is noneed to have another dimension. As of BPC 7.5 customers can continue to use the currencytype dimension for this purpose or they can split it into a Group dimesion (Type G) and apure currency dimension (Type R) in order to allow reporting in multiple group currencies.

The required properties for a separate group dimension are:


GROUP_CURRENCY 20 Can be a valid reporting currency. Used forcurrency ConversionThis property can only be used onCURRENCY members with the property

Property Name Length Description of appropriate propertyvalueCURRENCY_TYPE= G and in this case itmust contain a valid ID from theCURRENCY dimension with the propertyCURRENCY_TYPE = R.

PARENT_GROUP 20 Must be a valid Id from the Groupsdimension.If you want to do the consolidation by level,you must indicate here the higher level fromthe group.If you want to use this property to define thehierarchy, enter the same code as the Id foryour “Top group”. If this property is blank,the “dynamic hierarchy” from the Ownershipapplication is used.

ENTITY 20 Blank or a valid Entity ID.Is used to define the link between theGroup and the Entity and / or to indicate theentity where the aggregation should bestored.If this property is filled with valid Entity id,and the property STORE_ENTITY is set to“Y”, the results of the currency conversionfor the current GROUP will also be copiedinto this ENTITY

STORE_GROUP_CURR 1 Used for currency ConversionValues = Y or N or BlankBy default the results of the conversion intoa GROUP currency are written in both theGROUP member and in the CURRENCYmember of the currency dimension. If onlythe GROUP member is to be stored, theadministrator can set this property to “N”.

STORE_ENTITY 1 Y or blank: Y if you want to store in the idfilled in the entity property.

STAGE_ONLY 1 This property controls the way theconverted values must be saved in case ofa multi-level conversion of groups.This property can only take the three valuesY, E or N (blank).

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


PARENT_GROUP 20 Must be a valid Id from Groups dimension.If you want to do the consolidation By level,you must indicate here the higher level fromthe group.If you want to use this property to define thehierarchy, enter the same code as the Id foryou “Top group”. If this property is blank,the “dynamic hierarchy” from theOWNERSHIP cube is used.This property can only be used onCURRENCY members with the propertyCURRENCY_TYPE= G and in this case itmust contain a valid ID from theCURRENCY dimension.

ENTITY 20 Blank or a valid Entity id.Is used to define the link between theGroup and the Entity and / or to indicate theentity where the aggregation should bestored.If this property is filled with valid Entity id,and the property STORE_ENTITY is set to“Y”, the results of the currency conversionfor the current GROUP will also be copiedinto this ENTITY

CURRENCY_TYPE 1 Can be: L = Local Currency R = Reporting Currency T = Transaction Currency G = GroupUsed for the currency Conversion

GROUP_CURRENCY 20 Can be a valid reporting Currency. Used forcurrency Conversion

STORE_GROUP_CURR 1 Used for currency ConversionY=When you run the conversion for a groupCurrency, the procedure also stores theresults in the correspondingGroup_currency. N=The GROUP_CURRENCY is not storedin the database.

STORE_ENTITY 1 Y or blank:Y if you want to store in the id filled in theentity property.

STAGE_ONLY 1 This property controls the way theconverted values must be saved in case ofa multi-level conversion of groups.This property can only take the three valuesY, E or N (blank).


FIRST_CONS_DATE 10 Blank for management ApplicationYYYY.MON for Consolidation

Flow DimensionThe flow type dimension is optional but its use is highly recommended. This dimensionallows for a customer to track changes within the account activities, such as openingbalance, additions, subtraction and currency translation adjustments. If the customer doesnot require this level of detail, the business rule tables should be left blank for the sub-tablefield.. 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 ratesand (2) by the consolidation procedure to detail the eliminations applied to the movements ofthe balance sheet accounts.

If the customer choices to use a flow type dimension the following properties are required:


FLOW_TYPE 12 OPENING : openingTRANSLOPE : Change Diff On openingALLOCINC : AllocationMERGER : mergerINCOME : Net Income From The periodCHANGE: Variation.TRANSFER : transferTRANSFLOW : Translation Change onFlowVARSCP : Variation In Scope (Generic)VARSCPMETH : Variation In ScopeMethodVARSCPPERC : Variation In ScopepercentageVARSCPNEW : Variation In Scope newCompanyVARSCPLEAV : Variation In Scope SoldCompanyCLOSING : ClosingNONE : No FlowBlank : all other Flows

DIMLIST 20 Used to group the Flows for severalBusiness Rules

IS_INPUT 1 Y if the flow is an input oneN if the flow is not an input one

Maintain property

To maintain the property of a dimension, Go to Admin Console - > left click to select adimension 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 theproperties associated with this dimension similar to the one listed below:

Figure 7: Property Maintenance in the BPC administration Console

Maintain dimension members1. Maintain dimension members and their property values.

To maintain the dimension member of a dimension, go to Admin Console - > left click toselect a dimension in dimension library -> find option “Maintain dimension member” in actionpane.

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 NetWeaverversion, which means if upper case and lower case written are recognized as two differentmembers. But for RATE cube and Ownership cube, we strongly recommend that not set twomembers just with different cases, for example R_ACCT dimension “AVG” and “Avg” could betwo different members to store the AVG exchange rate, this is not recommended to be usedfor storing exchange rate and ownership details, as both script logic and consolidationprogram 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 thesystem which properties to associate with the application.

In BPC, an application is either “Reporting” or “Non-reporting”. Non-reporting applications aredesigned 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 currencyconversions, intercompany eliminations, etcThis application must reference a Rate-type application.

Consolidation: performs legal consolidations. Similar to Financial applications, butwith legal consolidation rules instead of managementThis application must reference an Ownership-type application and a Rate-typeapplication.

Generic: has no special requirements (other than to include the four minimallyrequired 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 andconsolidation type applications. The two types of non-reporting applications are:

Rate: stores exchange rates that support currency conversions for reportingapplicationsThis application must include a Currency-type dimension to store the exchange ratesby currency.

Ownership: Stores information such as the consolidation methods, ownershippercentages, and group rollup information used for legal consolidation.

Within the same application set, multiple reporting applications may exist, each one pointingto its own Rate and/or Ownership applications. Multiple reporting applications can also sharethe same Rate or Ownership applications, if appropriate.

The Rate and/or Ownership application associated to a given reporting application is definedwhen a new consolidation type application is created.

Note: You can report on non-reporting application data, but you cannot assign work statuscodes to the data. In addition, you cannot define business rules to these application types. Allapplications require at least the four main dimension-types: Entity, Account, Time, andCategory.

In SAP BPC, as mentioned in section 4.2 a consolidation application requires at least 3applications:

LegalMain Application containing all financial data. All consolidation postings suchas eliminations, minority interest calculations etc are posted in this application

OwnershipUsed to manage the organization structure and ownership percentages

RateContains 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 conversionapplies to both Financial and Legal Consolidation Applications to which a correspondingRate Application has been referenced and that the reporting application must contain acurrency (type R) dimension.

Rate application:

A rate application is a supporting application for financial and consolidation reportingapplications. It is used to store exchange rates that support currency conversion inConsolidation applications. ApShell comes with a rate application already, so you canleverage 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 therate application to store their foreign currency exchange rates and must have the samecategory member IDs.

This application must include a currency dimension detailing the exchange rates by eachinput currency. The currency dimension in a rate application does not need to have theREPORTING property. The Currency conversion process makes use of a RATE application,where the appropriate exchange rates will be searched for each relevant currency. This cubecan 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 aredifferent compared to C_Acct used in the Main application, R_Acct (Account Dimension forRATE application) and R_Entity (Entity Dimension for RATE application) are specific andutilized 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_Entitydimension 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 beapplied, 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 inconsolidation.

Ownership application:Any consolidation type application must refer to a RATE and OWNERSHIP application. Asmentioned before Apshell comes only with Planning and Rate application, the ownershipapplication needs to be created before we can create the Consolidation application. Pleaserefer to the steps wizard of creation process.The business rule process makes use of an Ownership type application when calculating theultimate ownership or during the minority interest calculation. This application must beassociated to a Consolidation type application. The ownership application will contain thevalues 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 Ownershipapplication, 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 anapplication 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 dimensionsto the Application Dimensions area. Remove the InputCurrency, R_ACCT, and R_Entitydimensions from the Application Dimensions area. Then select the Entity dimension row andclick 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 NewApplication.

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 isOwnership Account (O_Acct) to be used BPC consolidation engine to get the informationlisted above. In order to pass the information, we have to set up several required members,which include,

1. Method, defines consolidation method2. POWN, defines % of ownership (how much they are owned by the group)3. PCON, defines % of consolidation4. 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 steps1. 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 theOwnership application in the top right corner of the Action Pane. You may need to clickon “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 beset through the Web Admin. Please refer to the Admin guide on how to set these values.

Key ID DescriptionORG_OWNERSHIPCUBE The default value is OWNERSHIP.ORG_INTCO The default value is I_NONE, which should also

be a member ID in the INTCO dimension in theownership application if using dynamichierarchies.

ORG_ACCOUNTOWN The default value is PGROUP.OWNERSHIP_APP The name of the Ownership application. If this

parameter does not exist, the consolidationprocedure will by default search for anapplication named OWNERSHIP.

ORG_ACCOUNTLIST The default value is METHOD,POWN,PCON.

ORG_PARENTPROPERTY This parameter is used with dynamic hierarchystatutory applications when defining fixedhierarchies. The value must match the value inthe ParentProperty property value of entities inthe statutory application's supporting ownershipapplication.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. Goingforward we will use the ones created in the previous step. Please refer to the steps wizard ofcreation process.

Create a new application, name it and select the application “Consolidation”. Assign thecorresponding 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 consolidationapplication

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 reportingcurrencies.Calculations: To calculate and store amounts which are required for purposes ofaccount transformation.Intercompany bookings: Matching of inter-company transactions.US Eliminations: Specifically designed to address the posting of inter-companyeliminations in simpler scenarios where a full legal consolidation application is notrequired.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 thedesired groups of entities (eliminations, adjustments, re-classifications, minoritycalculations, etc.)

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

investments in subsidiaries, adjustments of minority interest, reclassifications and any otherpostings depending on the nature of the consolidation methodologies required. The enablingof 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 beactivated and shown from Admin Console UI, which includes Method Library, EliminationRule and Rule formula tables, as only Automatic Adjustment (such as Minority posting,Investment adjustment) utilize those Elimination rules and formulas for the calculation ofactual postings.

Before the consolidation type application is created, from UI of BPC, the user will not be ableto display the rules and the pre-delivered library tables content are stored in following ABAPdatabase 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 dimensionsrequired for legal consolidation.

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

In this step, set dimensions to be included in the consolidation application and also set thesecured 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 memberaccess control.For Group dimension here, it stores both group currency and reporting currency and alsoconsolidation groups. The MAIN cube must contain a CURRENCY dimension to store the translatedamounts. The consolidation entries, as generated by the consolidation process, will also be stored byGROUP in the same CURRENCY dimension (this is why we refer to it as the CURRENCY / GROUPdimension). The reason for this overlapping of dimensions is that, in the great majority of cases, theCURRENCY dimension and the GROUP dimension do not intersect. In other words the Entity detailsare either in local currency - LC - or in a reporting currency – say USD – or are consolidated into agiven GROUP – say G1 - in which case specifying the group is enough to identify its currency. As aresult of this, we can simply define the intersections ENTITY / LC, ENTITY / USD and ENTITY / G1, tobe able to store all required information.Any additional dimension is optional in the MAIN cube, as far as the currency translation isconcerned. 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 Consolidationprocedure to work, unless some elimination rule makes an explicit reference to thisdimension.

The application may have a FLOW dimension. This dimension is optional, but, if it exists, itcan be used

(1) By the currency translation procedure, to detail the changes in the balance sheetgenerated by fluctuations in the exchange rates

(2) By the consolidation procedure to detail the eliminations applied to the movements of thebalance sheet accounts.

A DATASRC dimension may exist in the MAIN cube, but it is not required by the currencytranslation. If it exists, however, the currency translation will be able to recognize whichmembers of such dimension should be translated and which ones should be just copied asthey are into the destination currency. On the other hand, this dimension is required for theconsolidation 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 torecognize their existence and take them into account in the process, and even apply somecustom 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 howapplications are used. The Legal application is an excellent example because it requiresquite a few settings. In this case, some of the more important parameters are used todetermine how organizational information from the ownership application is used.

Go to BPC Administration (Web) -> Set Application Parameters -> Change the current viewand set to the consolidation cube

Here is the table of the business rule activation during the creation of Consolidation typeapplication.

Key ID Description

APPROVALORG

If you want to use the work status feature, you must use this field to identifythe hierarchy level (H1, H2, H3, ..., Hn) for which you want to track thework status of deliverables. You can define only one hierarchy for eachapplication within an application set. For alternate organizations, “NoStatus” displays when viewing those members in the work status screen. Ifthis field is blank, work status tracking is disabled.

BPC_STATISTICS

When set to ON, various BPC modules write detailed runtime statistics totables UJ0_STAT_HDR and UJ0_STAT_DTL. You can use this informationto monitor system performance. Valid values are ON and OFF.

CALCULATION Allows the use of the Calculation business rule tables. Default = 1

INTCOBOOKINGSAllows the use of the Intercompany booking business rule tables. Default =1

VALIDATIONS Allows the use of the validation business rule tables. Default = 1USELIM Allows the use of the business rule tables for US Eliminations. Default = 1FXTRANS Allows the use of the currency conversion business rule tables. Default = 1OPENINGBALANCE Enables the business rule table for balance carry forward. Default = 1

JRN_REOPEN_PROPERTY

A custom Journal module assumes that the property named UB must bepresent 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 accountdimension.

ORG_OWNERSHIPCUBEName of the linked Ownership application. The default value isOWNERSHIP.

ORG_INTCO

The 3rd party member in the Intercompany dimension to which allownership calculations are posted.The default value is I_NONE, which should also be a member ID in theINTCO dimension in the Ownership application if using dynamichierarchies.

ORG_ACCOUNTOWN

Member id of the ownership account that specifies the Position of aconsolidation entity within the group.The default value is PGROUP.

ORG_ACCOUNTLIST

Member ids of the ownership account dimension that store methods, %con(% consolidation), %own. These will appear in the dynamic hierarchyeditor.The default value is METHOD,POWN,PCON.

ORG_PARENTPROPERTY

The property name in the Groups dimension to define the hierarchy used inthe dynamic hierarchy editor. The Group property that will contain the legalrollup members.This parameter is used with dynamic hierarchy statutory applications whendefining fixed hierarchies. The value must match the value in theParentProperty property value of entities in the statutory application'ssupporting Ownership application. The default value is PARENT_GROUP.

OWNERSHIP_APP

The consolidation logic requires the Ownership application to be listed hereas well.The name of the Ownership application. If this parameter does not exist,the consolidation procedure by default searches for an application namedOWNERSHIP.

YTDINPUT

This parameter controls whether data is input in year-to-date format. Validoptions are 1, which means YTD format; or 0, which means periodicformat. (Optional)

Figure 21: Application parameters

To set the Application parameters for the LEGAL application do the following steps1. 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 theOwnership application in the top right corner of the Action Pane. You may need to clickon “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 beset through the Web Admin. Please refer to the Admin guide on how to set these values.

Key ID ValueAPPROVALORG H1FXTRANS 1INTERCOMPANY 1

JRN_BALANCE 1JRN_POST_OVERWRITE Y

OPENINGBALANCE 1ORG_ACCOUNTLIST METHOD,PCON,POWNORG_ACCOUNTOWN PGROUP

ORG_INTCO I_NONEORG_OWNERSHIPCUBE OWNERHSIPORG_PARENTPROPERTY PARENT_GROUP

OWNERSHIP_APP OWNERSHIPVALIDATIONS 1

WORKSTATUSVALIDATE Yes

YTDINPUT Yes

Figure 22: Consolidation Application parameters

YTDINPUT setting

One of the most important application parameter in web admin parameter that should beset is YTDINPUT. This defines the application type whether it is periodic or YTD (Year toDate). This parameter plays important role since it controls how the data is stored in thecube.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 foryear-to-date reporting (except for Balance Sheet accounts, which gets the value from thelast period).However, in some business cases, calculations should occur on a year-to-date basis. IfYTD is required, applications can store the data on a YTD basis. When data is enteredinto YTD, its periodic values used for reporting purposes, are calculated as the differencebetween the current period and the last period (again, Balance Sheet accounts wouldsimply take the value from the last period).

January February March AprilPeriodic 100 200 0 100YTD 100 300 300 400

Figure 23: Year to Date vs. Periodic

By default, applications are PERIODIC. You can change the YTDINPUT parameter to avalue of “1” to turn it into an YTD storage type.

Business Rules InterfaceSAP Business Planning and Consolidation delivers pre-defined functions designed tocalculate 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 ProgramIn order to give our customers the flexibility to customize these functions to meet theirspecific requirements “table-based” logic is applied. For each pre-defined data packages andscript logic, one or more “Business Rule tables” exist in which the business user canconfigure rules. The consolidation engine uses the Table Driven ABAP Programs to performall the appropriate calculations on a user-selectable region of data, and write the calculatedresults into the database

Table based logic (Business Rules) provides the flexibility for a customer to customizecertain delivered functions (logic), to meet their specific business needs, without having tounderstand 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 SAPBI Process Chains to invoke the Programs directly from the K2 scripts logic file and pass theappropriate parameters to the data package. Here is the full list of consolidation process thatBPC7 supports with its BI Process Chain and Script File and corresponding Business Rules.

Consolidation Task Process Chain NameScript Logic FilesName

Business Rule TableName

Balance CarryForward

/CPMB/OPENING_BALANCES COPY_OPENING.LGF Carry-forward rules

Validation /CPMB/VALIDATIONS VALIDATION.LGF Validation rules and

Validation details

Currency Conversion /CPMB/FX_RESTATMENT FXTRANS.LGF

Currency ConversionRules

IntercompanyReconciliation /CPMB/ICDATA ICDATA.LGF No rules needed

IntercompanyBalance Booking /CPMB/ICBOOKING ICBOOKING.LGF Intercompany booking

Legal Consolidation(Elimination andAdjustment)

/CPMB/LEGAL_CONSOLIDATION CONSOLIDATION.LGF

Automatic Adjustmentsand AutomaticAdjustment Details

Account Calculation(Cash Flowfunctioned)

/CPMB/RUNCALCACCOUNT CALCACCOUNT.LGF Account Transformation

US widely usedIntercompanyElimination

/CPMB/IC_ELIMINATION ICELIM.LGF US Elimination

For each process, the pre-defined Data Manager Packages with their associated logic scriptsand rule tables are executed, performing the consolidation task according to the businessrule customization. Any specific business requirement needs to be configured incorresponding Business Rule Tables.

With this approach the customer has the possibility to freely decide when and how a processshould be triggered. We can, for example, invoke a currency conversion directly from theDEFAULT logic, whenever a value has changed via Web, Excel or via a data load, or we candecide to run one or more consolidation processes in a batch mode, using some customizeddata package that invokes an appropriately-designed logic file. Also, we can combine one ormore of these specialized processes with other custom-defined calculations, like allocationsor modeling formulas or whatever else may be defined using our general-purpose logicscripting technique.

The details steps of how to execute each tasks is described in separate How to Guideavailable in the SDN such as

How To setup Currency translation for Consolidation Application using BPC for SAPNetWeaver

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 chainsand allow you to do common data manipulation activities. The packages that come with BPC7.0 are designed to be dynamic so that you do not need to modify the packages in order forthem to work with your applications and dimensions.Data Manager Packages allows the user to manage data within BPC applications anddimensions.

Here are Financial Packages that can be used for the consolidation process apart from theStandard and Administrative Packages.

Process ChainTemplate

Description Technical Name

BPC: DefaultFormulas Logical

This package executes default formulasstored in your default.xls file.

/CPMB/DEFAULT_FORMULAS

BPC: Allocation The package runs the Allocation logic. /CPMB/ALLOCATION

BPC: CalculateOwnership

The package runs the CalcOwnership logic. /CPMB/OWNERSHIPCALC

BPC: FXRestatement

This package is used for currencytranslation. The package runs the FXTranslogic.

/CPMB/FX_RESTATMENT

BPC: ICElimination

This package is used to Perform Inter-Company eliminations. The Package runsthe ICElim logic.

/CPMB/IC_ELIMINATION

BPC: ICBooking The Package runs the ICBooking logic. /CPMB/ICBOOKING

BPC: ICData The Package runs the ICData logic. /CPMB/ICDATA

BPC: LegalConsolidation

The Package runs the LegalConsolidationlogic.

/CPMB/LEGAL_CONSOLIDATION

BPC: OpeningBalances

The Package runs the OpeningBalanceslogic.

/CPMB/OPENING_BALANCES

BPC: RunCalcAccount

The Package runs the CalcAccount logic. /CPMB/RUNCALCACCOUNT

BPC: Clear theJournal Tables

Clears Journal tables and creates an outputfile.

/CPMB/CLEAR_JOURNALS

BPC: Export theJournal Tables

Exports Journal tables to an output file /CPMB/EXPORT_JOURNAL

BPC: RestoreJournal Tables

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 dataPackage-> look for the consolidation task related pre-delivered SAP BI Process Chain andselect to add.

Figure 6: Adding the Balance Carry forward package

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

Figure 7: Modifying the delivered Data Manager package

To Modify DM Package, Go to BPC for Excel Interface -> eData-> Organize Data PackageList -> Select the package and right click -> Modify Package -> Click View Package fromModify Package Screen -> The Dynamic Script Editor for Data Manager should be promptedup -> 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 BusinessPlanning and Consolidation 7.0 members and data.You can create two different types of logic:

Dimension Member FormulasScript 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 LogicEditor -> 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 whenit comes to understanding the K2 syntax. These examples can be copied and reused in acustomer 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: asshown 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 datapackage.

Maintain the business rule table

SAP Business Planning and Consolidation delivers certain pre-defined functions designed tocalculate and post amounts required to support common accounting activities such as:

Currency translationMatching and elimination of inter-unit balances.

In order to allow a customer the flexibility to customize these functions to meet their specificrequirements “table-based” logic is applied.For each pre-defined function, one or more “Business Rule tables” exist in which thebusiness 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 datasource does one wish to post the calculated amount under).

Table based logic (Business Rules) provides the flexibility for a customer to customizecertain delivered functions (logic), to meet their specific business needs, without having tounderstand 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 reportingcurrencies.Account Transformation: To calculate and store amounts which are required forpurposes of account transformation.Intercompany bookings: Matching of inter-company transactions.US Eliminations: Specifically designed to address the posting of inter-companyeliminations in simpler scenarios where a full legal consolidation application is notrequired.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 desiredgroups 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 examplethe Currency conversion can be check with How to do Currency Translation for ConsolidationApplication in BPC for SAP NetWeaver, How to setup Breakdown validation using BPC 7 forSAP NetWeaver, How to use COPYOPENING using BPC 7 for SAP NetWeaver etc.

Login to the BPC Admin Console -> Expand Consolidation Application -> Go to BusinessRule Editor -> Select the rule table to create the content of the rules according businessrequirements.

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. Thereare several ways to upload the data to rate application, such as utilize the data managerpackage – Import, or use dynamic templates to send data from the input schedule. Pleaserefer to the How to do Currency Translation for Consolidation Application in BPC for SAPNetWeaver for detail steps on how to load the rates. Please also refer to the How To loadexchange rates from TCURR table that is available in SDN.

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

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

Input ownership data and calculate ultimate ownershipAs the consolidation scope (such as ownership percentage, group/unit hierarchy) is timedependent and given the fact that the dynamic hierarchy editor is not available in BPC 7.0 forSAP NetWeaver, our recommendation is to leverage the steps suggest below on howupdating the ownership cube with ownership details. (Note that BPC 7.5 for SAP NetWeaveroffers 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) undera 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 groupassignment 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 thedetails including the consolidation method and positioning in a consolidation group. Both ofthe 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 theultimate ownership that is calculating how much each consolidation group owns of eachentity. 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 group-own-entity value described above.

The pre-delivered DM package “Calculate Ultimate Ownership” basically runs based on whatthe Direct Percent Ownership is entered into a selected account for each “owner” entity andfor each “owned” intercompany entity. For example if, in period 2009.JAN for categoryACTUAL, entity A owns the companies B and C by 80% and 30% respectively, the followinginformation should be entered:

CATEGORY TIME CURRENCY ACCOUNT ENTITY INTCO VALUEACTUAL 2009.JAN LC POWN A I_B 0.8ACTUAL 2009.JAN LC POWN A I_C 0.3

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

CATEGORY TIME CURRENCY ACCOUNT ENTITY INTCO VALUEACTUAL 2009.JAN CG1 METHOD 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 memberI_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 inthe following example

CATEGORY TIME CURRENCY ACCOUNT ENTITY INTCO VALUEACTUAL 2009.JAN CG1 POWN A I_NONE 1ACTUAL 2009.JAN CG1 POWN B I_NONE 0.8ACTUAL 2009.JAN CG1 POWN C I_NONE 0.3

If the business users prefer to enter the ultimate share directly – rather than inputting theownership percentages of the direct parent, then, the only step required is to input the group-own-entity value for POWN, PGROUP, and METHOD under I_NONE under IntCodimension.

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 thenumbers loaded reconcile with the numbers in the source system. In the followingexample data was loaded for 2008.MAR for the Japanese Entity and the reportingcurrency 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 thecolumn and Account in the row. Here is an example to validate the data loaded forMAR 2008.

Note: The exchanges rate was loaded for 2007.DEC and 2008.MAR in the Rateapplication.

.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 March2008

Work Status Setting

Work States Setting (AppSet dependent)

The Work Status is a mechanism that allows submitted data to be tracked, approved andlocked using customizable work states definitions that meet the business needs. The workstatus serves the need to secure the data in their application beyond access controls forusers.With the release of BPC7.0, the system is capable of providing sufficient control on changingthe data to database. Work status such as “Unlocked”, “Submitted”, and “Locked” etc. can beset on a data set, which could be based on dimensions of the data. The term locking isgenerically used to describe data that is not available for change either on a temporary orpermanent basis. During the specific business process, end users can use the work states toapply a label to a specific current view intersection for the purpose of locking data so it canbe reviewed, approved, etc. This is actually a very common requirement, for example, duringmonth-end close business process requires that a specific set of data is locked down so thataccurate month-end reports can be created. After a data submission, the owner can set thestatus of the data to 'Submitted.' This locks the data intersection from subsequentsubmissions. In the other hand the locking strategy of the data is also possible for user tocustomize according to various business needs. For example, between bottom up and topdown data processing model, user can have the flexibility to work with the system on how thelocking logic applies.

Login to BPC Admin Console -> Work States Setting -> Add the states according thebusiness needs -> Set for different interface for the Approval privilege level for each workstates 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 specificrequirement. At application level, the system provides user the interface to define belowsettings,

1) Approval organization: work status can be configured by dimensions. User candecide which dimension contains the approval organization. The approvalorganization 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 bottom-up method. That is, the status of a parent cannot be higher than the status of itschildren. Of course user can set work status to top-down. For bottom-up behavior, themaximum 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. Forexample, 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 inthe application are also available for user to pick up to be used to track work statussetting. If user decides not to use certain dimension to track work status, thatdimension must contain a member that is included in the validation process of workstatus to make sure the data is validated before being locked.

Login to BPC Admin Console -> launch the application -> Work Status Setting-> Set the lockdimension and owner dimension.

Note: Owner dimension must contain the owner property dimension, which hierarchycontrols the work states change hierarchy.Requirement to define a dimension with an owner property, this dimension must also containa hierarchy to enable the pushing of the work status. The dimension with the owner propertywill drive parent/child relationship for setting status.

In addition to the customizing functionality, the work status combines the above states withspecific functionality based on owner property defined in a specified dimension. The usermust define either top down or bottom up rules to apply to an application (currently anapplication 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 partof the month-end or quarter-end process. During review and analysis step, journals allowuser 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 theprocessor should be able to review the data and use journal entry to make adjustments ifthere is any correction/reclassification needed.- When journal entries are saved and posted, all adjustments to data can be tracked andreported 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 savedto the cube. The user controls what is deemed an “incorrect” record. An example of anincorrect record is one where you have specified an intercompany Account, but left theTrading Partner dimension empty. Please note that in BPC 5 and 7M, validations have beenimplemented but only Journals data is checked for validation. Therefore, it is very easy toend up with invalid records in your application as all other modules (Excel, Web, DataManager, etc) will not be validated. The existing Journals validation functionality is notimplemented in BPC 7 for SAP NetWeaver. Instead, this module is intended to supersedethis functionality. In BPC 7, it is not possible (or supported) to get data into a cube withoutgoing 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 includingjournals, 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 datais input into the application. For example, the general ledger information is loaded into theapplication via Data Manager. The application users can adjust this data but also track andreport 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 can’t be deleted from theapplication any more as well as all data.

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

Caution: If you have already created a journal template, creating a new template thatchanges the structure of the journal entries deletes the old template and all journal entriesassociated with that template. This removes your audit trail, even though changes made tothe application data through posted journal entries are maintained. If you recreate the journaltemplate, but do not change the structure of the template keeping all header and detaildimensions 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, itis not possible (or supported) to get data into a cube without going through the Write-Backmodule. Therefore, we implemented the validations in write-back, to ensure that invalidrecords can not get into the cube from any source not only for journals, but also for all DMpackage and manual data input. An example for this is if a specified intercompany accountwith 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 codeUJ_VALIDATION to configure the validation framework and customize the validation rulesaccording business requirement. Refer to the “How To do Breakdown Validation in BPC forSAP 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 businessrequirements Please refer to the How to guide on Validation setup in BPC 7.0 for SAPNetWeaver 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.

How To Setup a Legal Consolidation Application using SAP...

Documents

Transcript of How To Setup a Legal Consolidation Application using SAP...