You are on page 1of 60

SAP Business Objects EPM How-to Guide

SAP Business Objects EPM How-to Guide How To Setup a Legal Consolidation Application using SAP BPC
SAP Business Objects EPM How-to Guide How To Setup a Legal Consolidation Application using SAP BPC

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

7.0 version for SAP NetWeaver Applicable Releases: SAP BusinessObjects BPC 7.0 for SAP NetWeaver Version 1.1

© 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 SAP’s Support Services and may not be modified or altered in any way.

delivered with this product is only to be used by SAP’s Support Services and may not

Document History

Document Version

Description

1.10

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

1.00

First official release of this guide

<< Enter your summary of changes in this version >> 1.00 First official release of this

Typographic Conventions

Type Style

Description

Example Text

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

Example text File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools.

Example text User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example

Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system.

text>

EXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER.

Icons

Icon

Description

CautionKeys on the keyboard, for example, F2 or ENTER . Icons Icon Description Note or Important

Note or ImportantTEXT Keys on the keyboard, for example, F2 or ENTER . Icons Icon Description Caution Example

ExampleKeys on the keyboard, for example, F2 or ENTER . Icons Icon Description Caution Note or

Recommendation or TipEXAMPLE TEXT Keys on the keyboard, for example, F2 or ENTER . Icons Icon Description Caution

the keyboard, for example, F2 or ENTER . Icons Icon Description Caution Note or Important Example

Table of Contents

1. Business Scenario

2

2. Background Information

3

3. Prerequisites

3

4. Step-by-Step Procedure 4

Application Set Creation Login in to Apshell Create Appset 5

4

4

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

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

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

Ultimate ownership calculation

o

elimination entries for intercompany revenue, investments and profit in inventory

o

adjusting entries

o

re-classifications

o

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

(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 customer’s 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.

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.

be able to log on Admin Console with the AppSet –ApShell. Figure 1: ApShell Application Set

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

1: ApShell Application Set within BPC 7.0 for SAP NetWeaver Tip : To check that the

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.

ABAP server from GUI and run the transaction “RSA1” to check the BI Infoprovider “APSHELL” and

Create Appset

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

as a starting point to begin building out your appset. Figure 2: Copying ApShell as a

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

Copying ApShell as a starting point for Legal Consolidations Note: If you already have an existing

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.

consolidations allows you to share the relevant dimensions – such as account - with your consolidation

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

Description

ALLOWEXTENSIONS

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)

ALLOW_FILE_SIZE

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

AVAILABLEFLAG

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)

AVAILABLEMSG

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)

AVAILABLEURL

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.

LANDINGPAGEITEM

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.

LOGLEVEL

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.

MAXLRCOLUMNS

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.

MAXLRROWS

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

SMTPAUTH

2 = NTLM

  The authentication method of the SMTP server. (Required) 0 = Anonymous 1 = Basic SMTPAUTH
 

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.

SMTPPASSWORD

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

SMTPPORT

Port number for your SMTP email server. Default is port 25, the default SMTP server port number. (Required)

SMTPSERVER

The name or TCP/IP address of the SMTP email server the system uses to send email. (Required)

SMTPUSER

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)

TEMPLATEVERSION

You can also reset the template version from the Admin Console.

SYSTEM

BPC 7 Internal system Parameter, default value = 1

MESSAGE

BPC 7 Internal system Parameter, default value = Blank

STATUS

BPC 7 Internal system Parameter, default value = 1

STATUS BPC 7 Internal system Parameter, default value = 1 Figure 3: Appset parameters Tip: In

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

named as desired. Within the same AppSet, multiple MAIN applications may exist, each one pointing to

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

it is mandatory that the dimension types match with the ones described in this guide for

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.

currency hence there is no need to have another dimension. Note: However if the requirement is

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.

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

case you have to use the group type dimension in Ownership application which is available as

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

The following table gives a summary of what dimension is required in which application:

Name

Type

Legal

Ownership

Rate

C_Acct

A

X

IC_Acct

A

O_Acct

A

X

R_Acct

A

X

Flow

S

X

C_Category

C

X

X

X

Entity

E

X

X

R_Entity

E

X

Intco

I

X

X

Time

T

X

X

X

Group

R

X

X

InputCurrency

R

X

C_DataSrc

D

X

Figure 4: Dimension in application matrix

Note: IC_Acct dimension shown here is used when separate application is created for Intercompany Matching. Please 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.

Go to dimension library. In the action pane, click on option “Add a new dimension” to
Figure 5: Creating a new dimension in the BPC admin console Required Dimension properties When

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.

O_Acct used in the Ownership application, P_ACCT used for planning Application and R_ACCT used in Rate

Property Name

Length

Description of appropriate property value

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 in Business Rules. For example : using the DIMLIST property value can help reducing the size of the FXTRANS table

RATETYPE

10

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.

or the like) or adding an extra dimension to the MAIN cube, where all the simulated

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

Length

Description of appropriate property value

FX_SOURCE_CATEGORY

20

The category for the source (LC) data. If blank, it is the current category.

RATE_CATEGORY

20

The category from which the rates are read

RATE_YEAR

4

The year from which the rates are read. The value can be absolute (2005, 2006) or

relative value (-1, -2, +1, + 2). If blank it is the same as the source.

a

RATE_PERIOD

10

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.

FX_DIFFERENCE_ONLY

1

If

= Y, only the difference between the

default values and the simulated values is

stored.

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

Length

Description of appropriate property value

CATEGORY_FOR_OPE

20

Blank: the category for the opening balances is the same Non-blank: the ID of the category where to read the opening balances from

OPENING_YEAR

4

Blank: the prior year Non-blank: the year where to read the opening balances from. It can be an absolute or a relative amount

OPENING_PERIOD

10

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

of the year Non-blank: the period where to read the opening balances from. It can be

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 natio n b usiness rule s Option alfo r the cur ren cy busi ness ulesr

Mand atory fo r th eco nsolida tion busin ess r ules, it is requir e as the results des tinati on

Property Name

Length

Description of appropriate property value

IS_CONVERTED

1

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.

IS_CONSOL

1

Blank for management Application

Y

for Consolidation

DATASRC_TYPE

1

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.

COPYOPENING

1

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

OPENING_DATASRC

20

Blank: same as the source member Non-blank: the ID of the desired destination DATASRC for the copy

20 Blank: same as the source member Non-blank: the ID of the desired destination DATASRC for

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

Length

Description of appropriate property value

CURRENCY

20

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.

INTCO

20

Used to link intercompany counterpart ID for elimination. Also known as Trading Partner.

This ID must be defined in the IntCo dimension.

OWNER

60

Used for work status

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

Length

Description of appropriate property value

GROUP_CURRENCY

20

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

reporting currency. Used for currency Conversion This property can only be used on CURRENCY members with

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.

PARENT_GROUP

20

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.

ENTITY

20

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.

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

If

STORE_GROUP_CURR

1

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

STORE_ENTITY

1

Y

or blank: Y if you want to store in the id

filled in the entity property.

STAGE_ONLY

1

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

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

can only take the three values Y, E or N (blank). The required properties for a

Property Name

Length

Description of appropriate property value

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

ENTITY

20

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.

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

If

CURRENCY_TYPE

1

Can be: L = Local Currency

 

R

= Reporting Currency

T

= Transaction Currency

G

= Group

 

Used for the currency Conversion

GROUP_CURRENCY

20

Can be a valid reporting Currency. Used for currency Conversion

STORE_GROUP_CURR

1

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.

STORE_ENTITY

1

Y

or blank:

 

Y

if you want to store in the id filled in the

entity property.

STAGE_ONLY

1

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

in case of a multi-level conversion of groups. This property can only take the three values

Property Name

Length

Description of appropriate property value

FIRST_CONS_DATE

10

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

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.

Flow is similar to the movement type in SAP ERP.

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

Property Name

Length

Description of appropriate property value

FLOW_TYPE

12

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

DIMLIST

20

Used to group the Flows for several Business Rules

IS_INPUT

1

Y

if the flow is an input one

N

if the flow is not an input one

for several Business Rules IS_INPUT 1 Y if the flow is an input one N if

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.

option “Maintain dimension property” in action pane. Figure 6: Property Maintenance in the BPC administration

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:

dimension property ” you will see the properties associated with this dimension similar to the one
Figure 7: Property Maintenance in the BPC administration Console Maintain dimension members 1. Maintain dimension

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.

left click to select a dimension in dimension library -> find option “Maintain dimension member” in
Figure 8: Maintaining dimension members and their properties Here is an example of the Entity

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

up when you click on “ Maintain dimension members ”. Figure 9: Example of Member sheet

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.

issues might be resulted. For consistency reasons it is recommended to use only upper case for

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

percentages Rate Contains all currency exchange rates for the different rate types like average, sport rate

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.

are specific and utilized only by Rate Application. Figure 10: The rate application R_Acct is utilized

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

rates, if desired, otherwise the R_Entity dimension may just be limited to one dummy member, typically

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.

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 ,

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:

Secured button and verify that your screen looks similar to the following: Figure 12: the Ownership

Figure 12: the Ownership dimension selection

Secured button and verify that your screen looks similar to the following: Figure 12: the Ownership

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)

% of control (how much they are controlled by the group) Figure 13: the Ownership application

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.

recommended values that should be set through the Web Admin. Please refer to the Admin guide

Key ID

Description

ORG_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 the ownership application if using dynamic hierarchies.

ORG_ACCOUNTOWN

The default value is PGROUP.

OWNERSHIP_APP

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

The default value is METHOD,POWN,PCON.

ORG_PARENTPROPERTY

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.

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

Figure15: Naming the Consolidations application

Figure15: Naming the Consolidations application Figure 16: selecting the right application type: Consolidations

Figure 16: selecting the right application type: Consolidations

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

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: To calculate and store amounts which are required for purposes of

US Eliminations: Specifically designed to address the posting of inter-company

account transformation. Intercompany bookings: Matching of inter-company transactions.

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

processing of data to render a consolidated set of financial statements. This is commonly thought 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.

Step 4, uncheck the dimensions check as shown in order to select the desired dimensions required
Figure 4: De-select the dimensions box to allow you to specify the relevant dimensions for

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.

the consolidation application and also set the secured dimension to control the security via BPC member
Figure 5: Selecting the dimensions for your consolidations application Normally the Entity and Category dimension

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.

into the destination currency. On the other hand, this dimension is required for the consolidation procedure

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.

the Legal Application created with all the dimensions shown. Figure 20: The dimensions of the consolidation

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

APPROVALORG

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.

BPC_STATISTICS

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.

UJ0_STAT_HDR and UJ0_STAT_DTL. You can use this information to monitor system performance. Valid values are ON

CALCULATION

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

 

Allows the use of the Intercompany booking business rule tables. Default =

INTCOBOOKINGS

1

VALIDATIONS

Allows the use of the validation business rule tables. Default = 1

USELIM

Allows the use of the business rule tables for US Eliminations. Default = 1

FXTRANS

Allows the use of the currency conversion business rule tables. Default = 1

OPENINGBALANCE

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

ORG_OWNERSHIPCUBE

Name of the linked Ownership application. The default value is OWNERSHIP.

ORG_INTCO

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.

ORG_ACCOUNTOWN

Member id of the ownership account that specifies the Position of a consolidation 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 hierarchy editor. The default value is METHOD,POWN,PCON.

ORG_PARENTPROPERTY

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.

OWNERSHIP_APP

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.

YTDINPUT

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

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

“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

Value

APPROVALORG

H1

FXTRANS

1

INTERCOMPANY

1

JRN_BALANCE

1

JRN_POST_OVERWRITE

Y

OPENINGBALANCE

1

ORG_ACCOUNTLIST

METHOD,PCON,POWN

ORG_ACCOUNTOWN

PGROUP

ORG_INTCO

I_NONE

ORG_OWNERSHIPCUBE

OWNERHSIP

ORG_PARENTPROPERTY

PARENT_GROUP

OWNERSHIP_APP

OWNERSHIP

VALIDATIONS

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

Periodic

100

200

0

100

YTD

100

300

300

400

  January February March April Periodic 100 200 0 100 YTD 100 300 300 400

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:

of the currency conversion business rule table shown below: To run these programs, you must use

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.

Consolidation Task

Process Chain Name

Script Logic Files Name

Business Rule Table Name

Balance Carry

/CPMB/OPENING_BA

   

Forward

LANCES

COPY_OPENING.LGF

Carry-forward rules

Validation

/CPMB/VALIDATIONS

VALIDATION.LGF

Validation rules and

COPY_OPENING.LGF Carry-forward rules Validation /CPMB/VALIDATIONS VALIDATION.LGF Validation rules and
     

Validation details

 

/CPMB/FX_RESTATM

 

Currency Conversion Rules

Currency Conversion

ENT

FXTRANS.LGF

Intercompany

     

Reconciliation

/CPMB/ICDATA

ICDATA.LGF

No rules needed

Intercompany

     

Balance Booking

/CPMB/ICBOOKING

ICBOOKING.LGF

Intercompany booking

Legal Consolidation (Elimination and Adjustment)

/CPMB/LEGAL_CONS

 

Automatic Adjustments and Automatic Adjustment Details

OLIDATION

CONSOLIDATION.LGF

Account Calculation (Cash Flow functioned)

/CPMB/RUNCALCAC

   

COUNT

CALCACCOUNT.LGF

Account Transformation

US widely used Intercompany Elimination

/CPMB/IC_ELIMINATI

   

ON

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.

applications and dimensions. Data Manager Packages allows the user to manage data within BPC applications and

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

Process Chain

Description

Technical Name

Template

BPC: Default

This package executes default formulas stored in your default.xls file.

/CPMB/DEFAULT_FORMULAS

Formulas Logical

BPC: Allocation

The package runs the Allocation logic.

/CPMB/ALLOCATION

BPC: Calculate

The package runs the CalcOwnership logic.

/CPMB/OWNERSHIPCALC

Ownership

BPC: FX

This package is used for currency translation. The package runs the FXTrans logic.

/CPMB/FX_RESTATMENT

Restatement

BPC: IC

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

/CPMB/IC_ELIMINATION

Elimination

BPC: ICBooking

The Package runs the ICBooking logic.

/CPMB/ICBOOKING

BPC: ICData

The Package runs the ICData logic.

/CPMB/ICDATA

BPC: Legal

The Package runs the LegalConsolidation logic.

/CPMB/LEGAL_CONSOLIDATION

Consolidation

BPC: Opening

The Package runs the OpeningBalances logic.

/CPMB/OPENING_BALANCES

Balances

BPC: Run

The Package runs the CalcAccount logic.

/CPMB/RUNCALCACCOUNT

CalcAccount

BPC: Clear the Journal Tables

Clears Journal tables and creates an output file.

/CPMB/CLEAR_JOURNALS

BPC: Export the Journal Tables

Exports Journal tables to an output file

/CPMB/EXPORT_JOURNAL

BPC: Restore

Allows you to load Journal tables from a File

/CPMB/RESTORE_JOURNALS

Journal Tables

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.

Add a data Package-> look for the consolidation task related pre-delivered SAP BI Process Chain and
Figure 6: Adding the Balance Carry forward package The DM package could also be modified

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

of the table driven program used scripts logic file (LGF). Figure 7: Modifying the delivered Data

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

should be prompted up -> Click “Advance” button -> Edit the script of dynamic selection screen
Figure 8: The underlying code of the data manager package Create Script Logic files (LGF)

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

-> Go to Script Logic Editor -> Create an LGF file by using K2 script supported
Figure 9: Script Logic Note: All consolidation logic file (LGF) examples are stored in the

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:

from scratch. These script logic files can be accessed through T-Code “UJFS“ for File Service UI:
Figure 10: Transaction UJFS allows you to access the File Service Note : The K2

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:

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

US Eliminations: Specifically designed to address the posting of inter-company

purposes of account transformation. Intercompany bookings: Matching of inter-company transactions.

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.

the content of the rules according business requirements. Figure 11: Business Rule Editor Loading data Loading

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.

on how to load the rates. Please also refer to the How To load exchange rates

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.

be saved as a template in library for sharing and reuse. Figure 30: Dynamic Input Schedule

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.

(most often “LC” could be used) by category and time. Member “POWN” in O_Acct dimension stores
Figure 31: Maintaining ownership %, consolidation method, and consolidation group assignment for each entity Step2

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:

method and positioning in a consolidation group. Both of the factors can be maintained with using
Figure 312: Maintaining Position in group, consolidation method assignment for each entity Step4 : Run

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 group- own-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

TIME

CURRENCY

ACCOUNT

ENTITY

INTCO

VALUE

ACTUAL

2009.JAN

LC

POWN

A

I_B

0.8

ACTUAL

2009.JAN

LC

POWN

A

I_C

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

TIME

CURRENCY

ACCOUNT

ENTITY

INTCO

VALUE

ACTUAL

2009.JAN

CG1

METHOD

A

I_NONE

90

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

METHOD A I_NONE 90 Here ‘90’ is the value corresponding to the consolidation method for the

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

TIME

CURRENCY

ACCOUNT

ENTITY

INTCO

VALUE

ACTUAL

2009.JAN

CG1

POWN

A

I_NONE

1

ACTUAL

2009.JAN

CG1

POWN

B

I_NONE

0.8

ACTUAL

2009.JAN

CG1

POWN

C

I_NONE

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 group- own-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).

after running the Group Share Calculation (DM package). Figure 33: Checking the Ultimate Ownership calculation

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.

for the Japanese Entity and the reporting currency is USD. So we will show the source

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.

that the LC is populated and USD will be displayed as 0.00. Figure 34: Report Parameters

Figure 34: Report Parameters

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

report that shows the data that is available in 2008.MAR. Figure 135: Sample report displaying the

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

2008

is available in 2008.MAR. Figure 135: Sample report displaying the Japanese data loaded in local currency

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.

the Approval privilege level for each work states just created -> Set appropriate privilege for changing
Figure 36: Defining Work States Work Status Setting (Application Dependent) At specific application level work

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 bottom- up 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.

Admin Console -> launch the application -> Work Status Setting-> Set the lock dimension and owner

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

apply to an application (currently an application setting). Figure 37: Defining Work States at Application level

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.

made to the database. Here is an example to explain the possible journal process during company

- 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 write- back, 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 can’t be deleted from the application any more as well as all data.

template is created, the dimension in an application can’t be deleted from the application any more
Figure 38: The journal template allows users to enter journal entries in BPC to adjust

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.

the “How To do Breakdown Validation in BPC for SAP NetWeaver” on this for detail steps
Figure 39: Transaction code "UJ_VALIDATION" allows you to turn on the validation rules 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.

NetWeaver for detail steps on how to setup the validation. Figure 40: Validation Maintenance screen to

Figure 40: Validation Maintenance screen to create the rules

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

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.

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