SAP® BUSINESS PLANNING AND CONSOLIDATION 10.0, …

SAP® BUSINESS PLANNING AND CONSOLIDATION 10.0, VERSION FOR SAP NETWEAVER

STARTER KIT FOR US GAAP, SP02 Configuration Design Document

STARTER KIT FOR US GAAP – CONFIGURATION DESIGN DOCUMENT

2

Table of Contents

A. COMMON DESIGN PRINCIPLES .......................................................................................................... 5 1. General Reporting Principles .....................................................................................................................5 1.1. Reporting Cycle .............................................................................................................................................5 1.2. Reporting Indicators .......................................................................................................................................7 1.3. Sign Convention.............................................................................................................................................8 2. Consolidation Principles .......................................................................................................................... 10 2.1. Consolidation Type ..................................................................................................................................... 10 2.2. Consolidation Methods and Rates .............................................................................................................. 10 2.3. Foreign Currency Conversion ..................................................................................................................... 11 3. Intercompany Reconciliation ................................................................................................................... 12 3.1. Example of the Reconciliation Process ...................................................................................................... 13 3.2. Configuration Principles .............................................................................................................................. 13 3.3. Reconciliation reports ................................................................................................................................. 14 4. Manual Journal Entries ............................................................................................................................ 15 4.1. Audit IDs ..................................................................................................................................................... 15 4.2. Account Total and Interco Breakdown ........................................................................................................ 16 5. Working Languages.................................................................................................................................. 16 6. Business Workflows and Security .......................................................................................................... 16 6.1. Security by Dimension ................................................................................................................................ 16 6.2. Teams ......................................................................................................................................................... 16 6.3. Workflow Management ............................................................................................................................... 16 6.4. Security Settings by Team of Users ........................................................................................................... 18 7. Integration with ERP ................................................................................................................................. 19 7.1. Transactional data flow ............................................................................................................................... 19 7.2. Transformation and conversion files ........................................................................................................... 19 7.3. Transactional data load .............................................................................................................................. 21

B. CONSOLIDATING ACTUALS ............................................................................................................. 22 1. Dimensions and Properties ..................................................................................................................... 22 1.1. Accounts ..................................................................................................................................................... 22 1.2. Flows ........................................................................................................................................................... 22 2. Logic Scripts ............................................................................................................................................. 23 2.1. Default Script .............................................................................................................................................. 23 2.2. Manual Journal Entry Script ........................................................................................................................ 23 2.3. Consolidation Script .................................................................................................................................... 23 2.4. ICMatching Scripts ...................................................................................................................................... 24 3. Business Rules ......................................................................................................................................... 24 3.1. General Principles....................................................................................................................................... 24 3.2. Currency Translation Rules ........................................................................................................................ 27 3.3. Eliminations and Adjustments Rules .......................................................................................................... 28 3.4. Account Based Calculation Rules ............................................................................................................... 36 4. Controls ..................................................................................................................................................... 38 4.1. Set of Controls for Actual ............................................................................................................................ 38 5. Reports ...................................................................................................................................................... 39 5.1. Input Forms ................................................................................................................................................. 39 5.2. Reports ....................................................................................................................................................... 40 6. Business Process Flows .......................................................................................................................... 42


3

C. APPENDIX ............................................................................................................................................ 45 1. Input form - Example of F15-Net Variation Control ............................................................................... 45 2. Example of INPUTFLOWS Property Values ........................................................................................... 45 3. Consolidation.lgf Logic Script ................................................................................................................. 46 4. Default.lgf Logic Script ............................................................................................................................ 48 5. Journal.lgf Logic Script ............................................................................................................................ 49 6. Copy_Opening.lgf Logic Script ............................................................................................................... 50 7. Push_To_ICMatching Logic Script ......................................................................................................... 51 8. Conversion_ICData Logic Script ............................................................................................................. 52 9. Carry Forward Rules ................................................................................................................................ 53 10. Naming Convention for Method-based Multipliers ............................................................................... 54


4

Foreword This document describes how the SAP® Business Planning and Consolidation (BPC) 10.0 Starter Kit for US GAAP on SAP Netweaver was designed.

The Starter Kit for US GAAP is created to deliver business logic on top of a unified Corporate Reporting application for Legal consolidation, using both product and functional best practices.

This pre-configuration assists you in setting up your Legal consolidation application in order to adhere to US GAAP, while accelerating and securing the implementation project.

The contents provided in the Starter Kit consist of reports, controls and rules for performing, validating and publishing a Legal consolidation in accordance with US GAAP.


5

A. COMMON DESIGN PRINCIPLES

1. General Reporting Principles

1.1. Reporting Cycle The Starter Kit for US GAAP is designed to support a full consolidation scenario for actual data. The reporting cycle encompasses preparatory tasks, data entry tasks, consolidation tasks, and data retrieval through a library of reports.

1.1.1. Models

Model Name Use Data Entry Mode

Consolidation models

CONSOLIDATION Reference Financial data Year-To-Date

Financial models

ICMATCHING Intercompany Reconciliation Year-To-Date

Non Reporting models

OWNERSHIP Consolidation Scopes: methods and consolidation rates by Entity

Year-To-Date

RATES Currency Translation Rates Year-To-Date

1.1.2. Dimensions

Dimension Type Use Cons IC Own. Rates

VERSION C-Category

Reporting type / cycle: Actual, Budget, etc.

X X X X

TIME T-Time Time period X X X X

ENTITY E-Entity Reporting entity / (Legal/Management unit)

X X X

CURRENCY R-Currency

Consolidation Currency X X

ACCOUNT A-Account Financial and Statistical accounts X

FLOW S-Subtable

Positions (Opening/Closing) and detail of movements

X X

AUDIT_TRAIL D-Audit Business origin of the data X

INTERCO I-Interco Transaction Partner or held company in the group

X X X


6

SCOPE G-Group Consolidation perimeter X X

ICACCOUNT A-Account Account for IC matching X

ICAUDITID D-Audit Audit ID for IC matching X

OWNACCOUNT A-Account Ownership account X

INPUTCURRENCY R-Currency

Input currency X

FXRATENTITY E-Entity Rate per entity X

FXRATE A-Account Rate ID X

The Starter Kit provides the following versions. Please note that only the ACTUAL version is configured with any content in the Starter Kit:

Version Description Use

ACTUAL Actual from GL Legal Consolidation

BUDGET Annual Budget Budget


7

1.2. Reporting Indicators

1.2.1. Reference Indicators

1.2.1.1. Chart of Accounts

The Chart of Accounts includes balance sheet (BS) accounts, income statement (IS) accounts, cash flow statement (SCF) accounts, comprehensive income statement (SCI) accounts and changes in equity statement (SCE) accounts.

The Statement of Financial Position (SFP) - or Balance Sheet - distinguishes between the following items:

Non-current / current items

Gross values / depreciation and impairment / net values

The Income Statement (IS) is disclosed by function and composed of the following blocks of accounts:

Operating income and Non-operating income

Income (Loss) from continuing operations, before taxes

Income Tax expense

Income (Loss) from discontinued operations

Gain (Loss) from extraordinary items

The Statement of Cash Flows discloses cash effects from operating, investing and financing activities, and includes accounts to hold differences that require analysis.

The Statement of Comprehensive Income details Net Income and other comprehensive income

The Statement of Changes in Equity details the movement in equity accounts, including opening balances

1.2.1.1.1. Structure of the Chart of Accounts

The chart of accounts is organized into hierarchies. Accounts are always assigned to a parent member account by populating the PARENTH1 field in the ACCOUNT dimension.

The following hierarchies are defined:

Balance Sheet: includes Asset, Liability and Equity accounts

Net income (loss) attributable to parent: includes all P&L accounts

Statement of Cash Flows: includes all SCF accounts

Statement of Comprehensive Income: includes al SCI accounts

Statement of Changes in Equity: includes all SCE accounts

Technical Accounts: includes any technical accounts

1.2.1.1.2. Codification

The codification principle allows the user to do the following:

identify the account type: o ‘1’ = Assets o ‘2’ = Liabilities/Equity o ‘3’ = Profit and Loss o ‘4’= Statement of Cash Flows o ‘5’= Statement of Comprehensive Income o ‘6’= Statement of Changes in Equity o ‘9’= Technical

sort accounts in logical order in reports, notably in the balance reports (assets base members, liabilities and equity base members)

In addition, for “total” accounts, the prefix ‘T’ allows the user to distinguish between total accounts and leaf-level accounts.


8

1.2.1.2. Flows

The FLOW dimension allows detailing of the value change between the opening balance (F00) and the closing balance (F99) for balance sheet accounts. All flows, excluding F99, are assigned to a parent member “Period End Closing” (END) in order to:

Easily check that the sum of the opening balance and the period movements is equal to the closing position in reports (END = F99)

Dynamically select the opening flow and the movement flows in reports.

For Income Statement accounts, a single flow is used: F10 – Net Profit (Loss) for the period. (This corresponds with the flow value used to post Income into Equity).

Cash Flow and Comprehensive Income accounts use the single closing flow F99; and Changes in Equity accounts use a dedicated set of flows (‘T’ flows) which distinguish the type of equity affected in that statement.

1.2.1.3. Local Audit IDs

Reported data is consolidated according to US GAAP. Local data can be collected following US GAAP, or by following local GAAP and subsequently adjusting to US GAAP in input forms.

Local data is stored on the INPUT AuditID (audit-type dimension). Subsequent local adjustments in input forms are stored on the LOCAL_ADJ AuditID.

The Input forms for Balance Sheet and Profit and Loss are created to dynamically include all members assigned to the parent member “ALL_INPUT” in the form. In the Starter Kit, this means that the Input form includes a column for both the INPUT AuditID and the LOCAL_ADJ AuditID, within the same worksheet. Opening (F00) and closing (F99) flow values are also available for input.

The Input forms for Intercompany and Balance Sheet by Flow allow the user to choose an AuditID from the Context setting for use in the specific instance.

Thanks to a specific Data Access Profile, (named “Entry Level”) only “Input” AuditIDs (base members of “ALL_INPUT”) can be used by local end users; moreover, in the Context Default settings, the input AuditID is pre-defined as “INPUT” for any Web forms.

It is therefore possible to dynamically enhance the list of local AuditIDs available in input forms by assigning the same property value and hierarchical node to the new AuditID(s).

1.3. Sign Convention

In order to fully leverage the software’s data storage engine as well as the calculation engine of “total” accounts, values for closing balances are entered as positive amounts for all account types.

Assets

Equity & Liabilities Gross values

Amortization & Depreciation

Increase Decrease Increase Decrease Increase Decrease

Entry + - + - + -

Display 100 (100) 100 (100) 100 (100)

The ACCOUNT dimension is defined with the ACCTYPE property. Thanks to this property, values are automatically recorded with the appropriate sign for the account.


9

Accounts are defined with the following ACCTYPE values:

AST: Asset accounts. Default sign is positive (debit).

LEQ: Liability and equity accounts. Default sign is negative (credit)

INC: Income and SCF accounts. Default sign is negative (credit)

EXP: Expense accounts. Default sign is positive (debit)

To calculate values for display on parent members (total accounts), the ACCTYPE property is also taken into account. The calculated value will be displayed following the ACCTYPE property.


10

2. Consolidation Principles

2.1. Consolidation Type

The Starter Kit follows the direct consolidation approach, where Entities are attached directly to the main parent company of the consolidation perimeter.

In the CONSOLIDATION model, consolidation flows (such as F02 -Change in consolidation method, F92 -Change in consolidation rate) are not available in input forms.

NOTE: Sub-scope Management

The consolidation engine natively handles sub-consolidations; that is, consolidations of groups hierarchically organized into structures and sub-structures. The prerequisites are as follows:

Consolidation ownership structure organized hierarchically via the PARENT_GROUP property of the SCOPE dimension

Entities attached to sub-structures or directly to the top structure in the Ownership Manager.

The following options must be activated so that the aggregated amounts of possible sub-consolidations are stored in the fact table:

STORE_ENTITY property set to ‘Y’ (Yes)

ENTITY property set to a dedicated Entity ID which the aggregated value of the structures and sub-structures should be recorded onto.

2.2. Consolidation Methods and Rates

2.2.1. General Principles

The following consolidation methods are supported in the Starter Kit:

Full method (purchase method)

Equity method

The consolidation process uses the following rates:

Consolidation rate

Ownership rate

The consolidation ownership structure is entered manually (see Ownership Model). The Starter Kit does not include any process for determining the consolidation method by Entity automatically, nor calculating the consolidation rate and ownership rate.

2.2.2. Ownership Model

Consolidation methods and Ownership groups are stored in the OWNERSHIP model. They are used to define the consolidation ownership structure via the Ownership Manager.

The list of available consolidation groups is maintained in the group-type dimension named SCOPE.


11

2.2.2.1. Rates

The rates used correspond to the following ownership accounts (OWNACCOUNT) in the OWNERSHIP model:

PCON: Consolidation rate

POWN: Ownership rate (group share)

These rates are defined with the property IS_INPUT=Y.

2.2.2.2. Methods

The consolidation methods are defined in relation to the OWNACCOUNT dimension, on the METHOD member. The different values are as follows:

Description Method Code

Holding (Main Parent) [Method ID=10] This method must be assigned to the consolidating

company for which no equity elimination is booked.

Full (Purchase method) [Method ID = 20]

Equity [Method ID = 30]

Note: Other values also exist in order to deal with scope changes.

2.2.2.2.1. Equity Method

Equity method postings are handled within most rules along with the full and holding methods; exceptions exist for Equity method Investments, Dividends and Net Income, which are all discussed in the “Eliminations and Adjustments rules” chapter of this document.

The INTEGRATION consolidation rule, in conjunction with an Equity method assignment to a relevant Entity, is defined make sure that only Full and Holding method entities are included in group reporting. This rule is also discussed later in the document.

2.3. Foreign Currency Conversion


Income Statement

Accounts are converted using the average rate of the reporting period.

Balance Sheet (Statement of Financial Position)

Most of the accounts (except equity and investments accounts) are converted using the period-end rate at closing position

Movements are translated using average rate.

Investments and equity accounts are maintained at their historical acquisition value (currency translation differences are recorded in a dedicated account in the reserves, account 24161)

As some transaction values need to be converted at a specific rate (such as dividends distribution and the balance sheet position of incoming units), the definition of currency rate per Entity is required.


12

2.3.2. Rates Definition and Input Forms

The following FXRATE dimension members have been defined, and associated values per period must be entered in the RATES Model:

AVG: average rate

END: closing rate

DIV: dividends rate

INC: incoming rate

The Starter Kit provides 1 input form. This is reached from the Start page of the Web Client, in the PUBLIC folder of the Library. This input form, Rates-input by currency/entity, is based on the FXRATENTITY dimension:

The form displays each INPUTCURRENCY member, by FXRATENTITY member (with the member GLOBAL listed first; this represents the default rate for the particular currency)

The currency conversion rules apply the specific rate for one Entity if such a rate exists. If not, it will default to the general currency rate input on the GLOBAL member.

2.3.3. Reminder: Entering Specific Rates by Entity

In order for the conversion engine to apply specific rates by Entity, it is necessary to input the specific rate for the Entity (FXRATENTITY dimension), not only against its respective local currency (INPUTCURRENCY dimension), but also against the consolidation currency. This is because the conversion engine will not refer to the default rate stored on the GLOBAL FXRATENTITY member in the case of a specific rate for one Entity.

3. Intercompany Reconciliation Accounts for which a breakdown by Intercompany is entered are reconciled:

Intercompany accounts of the Balance sheet

Intercompany accounts of the Income statement

Amounts are reconciled based on converted amounts. Consequently, no input in transaction currency is required at the local level.

A dedicated ICMATCHING Model is created for this process. Creating a dedicated model also contributes to optimizing the system performance by separating the calculations and processes from the CONSOLIDATION Model.


13

3.1. Example of the Reconciliation Process

(1) Data is input and/or loaded from source systems (2) Actual IC local data is loaded into ICMATCHING Model in order to reconcile intercompany declarations (package:

Interco Matching preparatory package) (3) Currency translation of local data using Actual rates (included in package: ICDATA) (4) Creation of data required for the matching on four specific AuditIDs (included in package: ICDATA) (5) Identification of intercompany mismatches in reports

a. For one entity b. For the Group

3.2. Configuration Principles

3.2.1. Dimensions

The ICACCOUNT dimension is created to bring the following advantages from a user-friendliness and system-performance perspective:

Limit the list of members only to accounts with intercompany breakdown

Define a 2-level hierarchy distinct from the hierarchical in the financial chart of accounts. This hierarchy will be used to group accounts to be reconciled together in the reconciliation reports. It is not necessary to calculate the financial total accounts for the reconciliation process.

The ICAUDITID dimension is created to:

Limit the list of members to the AuditIDs used to enter IC declaration locally (INPUT, LOCAL_ADJ) or centrally (ADJ_LC_M)

Add specific AuditIDs (namely DEBIT1, CREDIT1, DEBIT2, and CREDIT2) to duplicate and invert the Entity’s and the partner’s ID information in order to allow each Entity to view the amounts that other Entities have declared against it. This is necessary during the reconciliation process, due to the data access profile definitions.


14

A property IC_ORIGINE takes the value ‘I’ for all AuditIDs used originally to declare the intercompany operations, and specific values D1, C1, D2, C2 are used by the script ICDATA to generate the data required for reconciliation.

3.2.2. Logic Scripts

The logic scripts used during the IC process are the following:

The script PUSH_TO_ICMATCHING, defined in the CONSOLIDATION Model, is used to transfer data to reconcile from the CONSOLIDATION Model to the ICMATCHING Model. It is triggered via the IC Matching preparatory package.

The script CONVERSION_ICDATA is defined in the ICMATCHING Model. It is triggered via the ICDATA package. The purpose is to run the CURR_CONVERSION program in order to convert local data, and then run the ICDATA program that populates the following AuditIDs:

TOTAL1 Difference at seller Debit 1: My Assets / Income Credit 1: Their Liabilities / Expenses

TOTAL2 Difference at buyer Debit 2: Their Assets / Income Credit 2: My Liabilities / Expenses

3.3. Reconciliation reports

Example:

Local data transferred from the CONSOLIDATION model and converted via the CURR_CONVERSION program

Entity Interco AuditID ICAccount Flow LC USD AccType

E6 I0 INPUT - Input 32112 - Interest Income F10 200 200 INC

E0 E6 INPUT - Input 32122 - Interest Expense F10 200 200 EXP

Rows generated on new AUDITIDs via the ICDATA program


E6 I0 DEBIT1 - My assets/income 32112 - Interest Income F10 200 200 INC

E6 I0 CREDIT1 - Their liabilities/expense 32122 - Interest Expense F10 200 200 EXP E6 can retrieve

E6 I0 TOTAL1 - Difference at seller INTEREST - Interest Inc/Exp F10 0 EXP mismatching vs. E0


E0 I6 DEBIT2 - Their assets/income 32112 - Interest Income F10 200 200 INC

E0 I6 CREDIT2 - My liabilities/expense 32122 - Interest Expense F10 200 200 EXP E0 can retrieve

E0 I6 TOTAL2 - Difference at buyer INTEREST - Interest Inc/Exp F10 0 EXP mismatching vs. E6


15

This structure of the information enables you to retrieve:

Discrepancies at a group level by seller for subtotals

Discrepancies at group level sorted by seller when retrieving Debit1, Credit1 and Total1 in Local Currency and Group currency

4. Manual Journal Entries

Manual journal entries may be used to book elimination entries or other consolidation entries in the Starter Kit, if required.

4.1. Audit IDs

Manual journal entries can be manually booked using predefined AuditIDs with property DATASRC_TYPE = M. Several AuditIDs have been created to allow the local user or the consolidation manager to book entries which may be required to complete the consolidation, or to complement automatic entries. For instance, the manual journal entry-type AuditID ADJ_ELI_M is available in addition to the automatic AuditID IC_ELIM to book entries related to eliminations.


16

4.2. Account Total and Interco Breakdown

If a manual journal entry should impact both the account total and one or several group partners, one journal row must be defined to record the impact on I_NONE, in addition to the journal row(s) recording the impact on the group partner(s).

5. Working Languages The Starter Kit handles English as unique language.

6. Business Workflows and Security

6.1. Security by Dimension User can only enter data on their own Entity. The Starter Kit security set up allows differentiating data entry and consolidation manager profiles.

Secured dimensions are set up as follows:

- Consolidation model: “ENTITY”, “AUDIT_TRAIL”, “SCOPE” - ICMatching model: “ENTITY” - Ownership model: “ENTITY”, “SCOPE” - Rates model: “VERSION”

In three of the models, the dimensions that stand for “Entity” drive the dimensional security (the RATES model has only VERSION as a secured dimension). AUDIT_TRAIL has been added for the CONSOLIDATION model, for the “Entry Level” data access profile, which requires a more restricted access. SCOPE has been added to the CONSOLIDATION and OWNERSHIP models, again to support more restricted access.

6.2. Teams

In addition to the standard ‘ADMIN’ team, 3 teams that reflect business roles have been defined in the Starter Kit:

Consolidation managers team (CONSOLIDATION MNGR)

Data entry users team (DATA ENTRY USERS)

Report viewers team (REPORT VIEWERS)

Depending on the team to which a user is assigned, an entire security configuration applies automatically.

6.3. Workflow Management A user managing a group of reporting entities can check whether the data entry related tasks have been performed, and assign the appropriate level of process status: Started, Submitted, Rejected, and Approved.

6.3.1. Entity specific properties

Even though users that are registered as Owner in the Entity dimension are likely to be changed after the Starter Kit is restored in a new environment, the way they are hierarchically organized illustrates how Work Status and BPF workflows should be designed with the Starter Kit.


17

This recommended configuration assigns the same user to both the roles of Work Status Manager (Owner of a parent Entity (1)) and the role of BPF Approver (Reviewer of a child Entity (2)).

Example of the Entity dimension:

ID DESCRIPTION OWNER REVIEWER

ALL_ENTITIES All Entities CONSOMNGR (1)

NA

E0 Entity 0 USD LOCALUSER CONSOMNGR (2)

E1 Entity 1 USD LOCALUSER CONSOMNGR

CONSOMNGR belongs to the CONSOLIDATION MNGR Team

LOCALUSER belongs to the DATA ENTRY USERS team

6.3.2. Business Process Flow (BPF)

Business process flows are defined to manage each reporting cycle. They are organized around the criteria of Central tasks vs. Local tasks.

Note: Mirroring roles (work status manager=BPF approver):

This mirroring structure should be replicated with actual users as part of the implementation project in order to keep BPFs and Workflows settings both consistent and quickly usable. The Starter Kit, specifically the BPFs, is not configured for distinct reviewers/approvers. (e.g. “CONSOMNGR” is reviewer of “E0” but the Work Status manager of “E0” is “LOCALUSER”).

6.3.3. Work Status

In terms of Work status, four levels have been defined. By default, the data is always set to the “Started” status. Once the data is entered and controlled, both the owner and the manager are allowed to change the work status to “Submitted”. From this point on, the manager only can change data using journals or input forms. When the status is set to “Approved”, only the manager can set the work status back to “Rejected” or reset it to “Started” if necessary. As long as the status is “Approved”, no data can be modified using input forms, but Journals and Data Manager are still possible for the Manager.

For all work states, creation or modification of comments and documents is possible.

Work state Data Manager

Journals Manual entry

Comments Documents Controlled By

Started All All All All All Both

Submitted Manager Manager Manager All All Both

Rejected Owner Owner Owner All All Both

Approved Manager Manager Locked All All Manager


18

6.4. Security Settings by Team of Users

Team Local Users Consolidation Managers

Report viewers ADMIN

Task Profiles

Entry Tasks

Key settings: - Only “view” rights in Web Admin - Only “view” rights on Journals - Access to Reports and Input

Forms allowed - Run controls and packages

enabled

Conso Tasks

Key settings: All rights, but only view rights on Model administration and system administration

Data View Tasks

Key settings: Can run documents using EPM client and Web reports. (Use of BPF can be added in the security settings)

ALLTASKS

Key settings: All tasks allowed (latest tasks from new product releases should be added manually in this profile)

Team Local Users Consolidation Managers

Report viewers ADMIN

Data access profiles

Entry Level

READ & WRITE Consolidation model

- ENTITY [ALL] - AUDITID [ALL_INPUT] - SCOPE [S_NONE]

READ ONLY

Consolidation model

- SCOPE [ALL] ICMatching model

- ENTITY [ALL] Ownership model

- ENTITY [ALL] - SCOPE [ALL] Rates model

- VERSION [ALL]

All Members

READ & WRITE Consolidation model

- ENTITY [ALL] - AUDITID [ALL] - SCOPE [ALL]

ICMatching model

- ENTITY [ALL] Ownership model

- ENTITY [ALL] - SCOPE [ALL] Rates model

- VERSION [ALL]


19

7. Integration with ERP

7.1. Transactional data flow The Transactional Data Flow is shown in the following diagram:

More information regarding Data Source, Data Store Object and InfoCube is included in the EPM RDS for Financial Close and Disclosure Management documentationat http://www.sap.com//solution/rapid-deployment.html. This chapter only focuses on the last part of the data flow: it explains the configuration objects available in the EPM Excel Add-In to launch Data import.

7.2. Transformation and conversion files The starter kit includes two transformation files: ECC GL Data (enables data import for Balance sheet accounts)

ECC GL Data PL (enables data import for P&L accounts)

The transformation files provided in the starter kit are based on a BW staging cube “PKG/FC_C01” delivered with the EPM RDS Financial Close & Disclosure Management. The BW system has been connected to an ECC source system where financial data from the US baseline (SAP General Ledger) has been loaded.

http://www.sap.com/solution/rapid-deployment.html

http://www.sap.com/solution/rapid-deployment.html


20

Transformation files enable Actual local data import. Therefore, the following dimension members are pre-defined in the mapping: - VERSION: ACTUAL - CURRENCY: LC - Local Currency - SCOPE: S_NONE – Not Consolidated - AUDIT_TRAIL: INPUT Each transformation file is also linked to a conversion file: ECC GL Conversion (for Balance sheet accounts)

ECC GL Conversion PL (for P&L accounts)

Conversion files include the following conversion tables:

- INTERCO - ENTITY - ACCOUNT - FLOW - TIME (only for ECC GL Conversion PL file) Interco and Entity conversion tables are filled in with the entities/interco created in in our BW staging cube for testing purpose. These conversion tables should be cleared and replaced with the list of FI/CO Company codes mapped with the members created in the ENTITY and INTERCO BPC NW dimensions. The Entity mapping table could be deleted if the FI/CO Company codes are the same in the BPC NW ENTITY dimension. The Account conversion table is based on the FI/CO US baseline (SAP General Ledger) mapped with the BPC NW starter kit for IFRS chart of accounts. This conversion table should be updated if data source is not based on the US baseline and if the IFRS starter kit chart of accounts has been enhanced. The Flow conversion table is based on FI/CO movement types mapped with the BPC NW starter kit for IFRS list of flows. This conversion table should be updated according to FI/CO enhancements and/or IFRS starter kit list of flows update.

The Time conversion table is required for P&L data because it is stored on a periodic basis in our BW staging cube whereas balance sheet data is stored on a year to date basis. This storage principle could be different in your customer environment and could require an update of the transformation files. For instance, if Balance sheet and P&L data is stored on a YTD basis, it would be easier to include P&L accounts conversion table into the Balance sheet accounts conversion table and to delete the transformation and conversion files dedicated to P&L.

The Time conversion table provided in the starter kit enables data load on 2012.12 period. This period has been chosen for testing purpose and should be manually updated according to the data import period . For instance, to load P&L data on February 2012, the Time conversion table should be the following:


21

7.3. Transactional data load Transactional data load can be done by running the Package “Load Transaction Data from BW InfoProvider UI” and selecting the appropriate info provider and transformation file. This package should be run two times to load Balance sheet and P&L data.


22

B. CONSOLIDATING ACTUALS

1. Dimensions and Properties

1.1. Accounts

ACCOUNT dimension properties used in the Starter Kit:

Property Specific use

ACCTYPE Identifies account type (AST, LEQ, INC, EXP) and therefore treatment of values in reports

DIMLIST_FS Used to calculate values for use in Business Rules used to populate SCF, SCI and SCE accounts

ELIMACC Used to define the respective elimination account to be populated as balancing for the journal entry

GROUP Used in the Logic Scripts to distinguish between Account Types (ASSETS, EQ_LIAB, IS).

INPUTFLOWS Used to define which flows may be used for the account in Input forms

ISINTERCO Used to determine whether the account needs additional input by Partners in Input forms

RATETYPE Used in the currency conversion rules

STYLE Used to define formatting for each type of account in the hierarchy

TYPELIM Used to select accounts in Business Rules

1.2. Flows

In order to be able to calculate the Statement of Cash Flows items and to produce the Statement of Changes in Equity, changes in the BS items are captured or calculated as follows:

For current assets and liabilities (Gross value), the net variation is calculated and displayed in input forms

For other BS accounts, a detailed analysis of movements is required

Specific operations are identified separately for all BS accounts: Reclassification, Changes in accounting policies

Opening balances are automatically calculated from the closing balance of the previous year.

The following common flows are valid for all BS accounts:

Positions: F00-Opening, F99-Closing

Flows for current transactions: F15 - net variation, F20 - increase, F25 - impairment, F30 – decrease, F55 - fair value adjustment.

Specific flows (except for some equity accounts): F50-Reclassification, F05-Change in accounting policies


23

Relevant flows allowed for use in postings depend on the account. This “allowance” is defined in the INPUTFLOWS Account property (See Appendix C.1). This property is used to ‘stripe’ cells that correspond to inconsistent account-flow crossovers in input forms.

For P&L accounts, only flow F10-Net profit (loss) is used.

Flow properties used in the Starter Kit are listed below:

Property Specific use

DIMLIST_CALC Used to indicate whether a flow is a movement or balance flow, for use in calculating the F15-Variation flow during data entry

DIMLIST_CONV Used to indicate the Rate Type to be used for the flow in currency conversion

FLOW_TYPE Used by the consolidation engine to select and process carry over and scope variation flows

2. Logic Scripts All of the following logic scripts used for Actual data processing are stored in the CONSOLIDATION Model.

2.1. Default Script

The real time calculations triggered by the Default.lgf logic script, when data is input in forms or imported through files, are the following:

Calculation of the income of the period in the balance sheet (Account 24140 / F10)

Calculation of the net variation flow (F15) o For all BS accounts, the net variation (i.e. closing balance – [opening balance + specific flows]) is calculated in flow F15-Variation. o For non-current accounts, the net variation must be distributed on relevant flows in the Balance Sheet by Flow input form. When saving new values, the variation flow (F15) is calculated again and must be zero in the form when distributions are complete; controls are performed during the data validation via specific controls rules to insure the zero value is true. The flow F15 is then highlighted in input forms (See Appendix C.1). o For current accounts (excluding provision and allowance accounts) the net variation amount is not distributed on flows, and may remain on the net variation flow (F15).

The detailed logic script is available (See Appendix C.4).

2.2. Manual Journal Entry Script

The real time calculations triggered by the Journal.lgf logic script when a manual journal entry is booked are the following:

Any impact from P&L is posted to BS Equity (account 24140 / flow F10)

Carry-over of specifically posted flows to the closing flow (F99)


2.3. Consolidation Script

The first part of this script corresponds to standard conversion and consolidation programs. The VERSION, the SCOPE and the TIME are configured with the syntax “%_SET%” so that the user can select the appropriate members when running the associated package (namely Consolidation stored in the Consolidation Model > Financial processes package group).


24

In the second part, the script refers to the Account-based Calculations rules to be triggered in order to automatically calculate the consolidated Statement of Cash Flows, Statement of Comprehensive Income, and Statement of Changes in Equity.


2.4. ICMatching Scripts

The ICMatching scripts are described in the Intercompany Reconciliation, Section A.3.2.2 of this document.

The detailed logic script is available (See Appendix C.7 and C.8).

3. Business Rules

3.1. General Principles

3.1.1. Balance Carry Forward

The Starter Kit allows the user to populate the opening balance of the current period from the prior year-end closing balance in order to ensure the flow consistency over time periods. This applies to the various amount types: Input data, manual journal entries (MJE) and automatic journal entries (AJE).

Opening balances of the current year result from the carry forward of closing balances from the previous year. This calculation is defined and executed in the following steps:

Balance Carry Forward of Data Input and Manual Entries:

For all AuditIDs with the property DATASRC_TYPE = I (for data input) and M (for Manual Entries), opening balances are calculated using the data manager package “CopyOpening” with the Carry Forward Rules defined as follow:

Source account: T0000 (all BS accounts) o Source flow: END-Period end Closing o Destination flow: F00-Opening o Audit type: A-All (meaning “input” and “manual”, but not “automatic”)

Calculation of the Consolidated Opening Balances (Automatic Entries):

The carry forward rules do not apply to automatic entries (AuditIDs with property DATASRC_TYPE = A). Instead, during processing of the consolidation package, the consolidation engine calculates the consolidated opening balances (flow F00) of the current year by copying the closing balance (flow F99) of the previous year.

The Carryforward rules are available (See Appendix C.9)

3.1.2. Flow-Based Consolidation

For manual and automatic journal entries, the closing position is always calculated from movements. This contributes to the consistency of the closing position and movements over time periods, notably for the calculation accuracy of the Statement of Cash Flows and the Statement of Changes in Equity.

Automatic and manual journal entries must be booked on movement flows. The impact on the closing balance (flow F99) is calculated automatically.


25

This calculation is defined in one of three places:

In the elimination and automatic adjustments rules (“Force closing” option) for all automatic entries that impact BS movement flows

In the Journal.lgf logic script for manual journal entries (See Appendix C.5)

In the Copy_Opening.lgf logic script for manual journal entries from the previous year (See Appendix C.6)

3.1.3. Balanced Entries

In the consolidation, manual and automatic journal entries are booked by ENTITY according to a contributive approach, not booked in adjustment or elimination entities. This is because it must be possible to retrieve the net contribution to the group consolidated figures by Entity. This principle also facilitates the audit trail since the origin Entity of the elimination is identified.

Manual and automatic journal entries must be balanced by Entity and AuditID.

Elimination accounts are created in the Balance Sheet and the Income Statement. They are used as off-setting accounts to balance elimination postings by Entity (e.g. the Entity remains in balance). Automatic journal entries will populate these elimination accounts as defined in the Elimination and Adjustment Rules. It is also possible to use these elimination accounts for manual entries.

3.1.4. Using the Breakdown by Partner

Intercompany accounts are collected by Group partner, so that it is possible to use the partners’ position in the consolidation scope, along with the elimination rules, to trigger the eliminations accordingly. The breakdown by partner is maintained in elimination entries for audit trail purposes, making it possible to explain the total amount eliminated.

The accounts for which intercompany values are possible (property ISINTERCO = ‘IC’ or ‘ICM’) are used as follow:

Company data is reported globally (Interco = I_NONE) and broken down by partner in a dedicated input form

Elimination entries are booked both by partner and globally (Interco = I_NONE). This is done by using the ‘Force intco member’ option in the elimination and adjustments rules

As a consequence, the detail of eliminations by partner is available for audit trail purposes. This logic is illustrated in the table below.

Automatic adjustment rules are based on Method-based Multiplier rules in which the Interco method, in addition to the entity method, is chosen. As a consequence, no elimination will occur when the INTERCO member corresponds to a non-consolidated entity.


26

Elimination by partner and on the grand total

Comment ENTITY ACCOUNT FLOW INTERCO AUDITID …. Amount

Account total

-Input data E0 Interest Income F10 I_NONE INPUT … 50

Partner breakdown (1)

-Input data E0 Interest Income F10 I2 INPUT … 40

Partner breakdown (2)

-Input data E0 Interest Income F10 I3 INPUT … 10

Elimination by partner E0 Interest Income F10 I2 ADJ_ELIM_AUTO … -40

Elimination by partner E0 Interest Income F10 I3 ADJ_ELIM_AUTO … -10

Total Elimination E0 Interest Income F10 I_NONE ADJ_ELIM_AUTO … -50

3.1.5. Analysis of Changes from Local to Consolidated Value

The preparation and validation of consolidated figures, including analysis of changes from local to consolidated values, is facilitated thanks to a business classification of all consolidation steps and calculations (manual entries, automatic eliminations…).

A dedicated audit-type dimension called Audit_Trail is defined to classify data from local to consolidated figures. This dimension is defined with a hierarchy in order to distinguish the different main transformation steps of amounts in the consolidation process and to retrieve these steps in reports.

3.1.6. Leveraging the Built-in Scope Change Calculation

Effects of ownership structure changes on consolidated statements must be disclosed on specific flows, depending on the type of the scope change (incoming, rate change, method change…).

For Balance Sheet accounts, Elimination and Adjustment Rules based on the current ownership and consolidation rates apply not only to movement flows, but also to the opening balance F00. This is because the consolidation engine is able to automatically identify and calculate the effect due to changes in the current structure by the difference between the carry forward of the automatic entry from the prior year-end period on the one hand, and the newly calculated automatic entry elimination for the opening balance F00 on the other hand.

Example:

December, Prior Year

Current Time Period

POWN 0.8 0.9

Audit IDs … F99-Closing

F00-Opening

Scope

variation*

F99-Closing

INPUT – Input data … 100 100 100

CONS_EQ – Automatic adjustment based on POWN

… 80 80 10 90

The scope variation flow member populated by the consolidation engine depends on the status of the Entity and/or the partner (Interco) in the consolidation perimeter: incoming, change in consolidation rate or change in consolidation method.


27

3.2. Currency Translation Rules


Currency Translation Differences

For equity and investment accounts, which are kept at historical exchange rates, the currency difference resulting from the translation of movements at specific rate (historical, average, opening) is recorded in a dedicated equity account 24161-Foreign Currency Translation Adjustment on flow F80-Currency Translation adjustment.

For other BS accounts, the currency difference resulting from the translation of movements at average rate, and the translation of closing balance at closing rate, is recorded in the original account on flow F80-Currency Translation adjustment.

Account selection

The RATETYPE property of the ACCOUNT dimension is used to dynamically associate groups of accounts to identical conversion behaviors.

Flow selection

The FLOW dimension ‘DIMLIST_CONV’ property is leveraged in the currency conversion rules in order to dynamically associate groups of flows to one given conversion behavior, within one account set, associated with one RATETYPE property.

Audit ID behavior

The currency translation process applies only to AuditIDs identified by the ’Y’ value of the IS_CONVERTED

property. Consequently this value has been assigned to AuditIDs intended for input and adjustments in the Starter Kit.

Flows DIMLIST_CONV property

Flows translated using the closing rate of the previous period OPE

Flows translated using the average rate AVG

Flows translated using the dividends Entity rate DIV

Flows translated using the incoming Entity rate INC


28

3.2.2. List of Rules Definition

The Currency Translation Rules are configured as follows:

3.3. Eliminations and Adjustments Rules

The list of the Eliminations and Adjustments Rules of the Starter Kit and their purpose is presented in the table below:

Rule ID Purpose Ref.

DIVIDENDS Dividends elimination 3.3.2

DIVIDENDS2 Balancing F80 against net variation cash (conversion of dividends at a specific rate)

3.3.2

EM_INV Equity Method Investments 3.3.3

EM_INV_DIVIDENDS Equity Method Dividends 3.3.2

EM_INV_NETINCOME Equity Method Net Income 3.3.5

EQUITY Consolidation of Equity accounts 3.3.5

GOODWILL1 Goodwill (I_NONE value) 3.3.4

GOODWILL2 Goodwill (interco value) 3.3.4

ICELIM Intercompany elimination 3.3.1

INVESTMENTS Investments elimination 3.3.3

INTEGRATION Integration of Holding and Full methods 3.3.6

Accounts Currency Translation Rule RATETYPE Property

IS accounts Average rate (AVG) AVG

BS accounts (except Equity and Investment)

Closing balance: closing rate (CLO) Movements: average rate (AVG) CTA calculation on flow F80 account by account

CLO

Equity and Investment accounts Maintained at their historical value: opening balance is not changed (AS_IS formula), other movements are translated using their respective rate (AVG, DIV, CLO, OPECLO). The “ForceClosing” Option is used so that the converted closing position equals the sum of converted flows. CTA calculation on flow F80 of the currency conversion reserve account 24161.

HIST

Currency translation account (24161)

The opening balance is maintained at the converted value of the prior year end (AS_IS formula)

HIST

Technical accounts

All balances are kept at prior converted values (AS_IS formula)

TECH


29

3.3.1. Intercompany Account Eliminations

Rule: ICELIM

3.3.1.1. Functional Requirements

Intercompany accounts are eliminated against dedicated elimination accounts (clearing accounts). As a consequence, any balances in these elimination accounts show the intercompany mismatch at group level.

Intercompany amounts are eliminated between entities consolidated using the full method. The elimination accounts are part of the account hierarchy, and consequently are included in consolidated statements.

At group level, elimination accounts show the intercompany differences, resulting from a mismatch in the intercompany amount reported by entities

At entity level, elimination accounts balance the elimination postings

3.3.1.2. Rule Configuration

Account selection/destination

Within the chart of accounts, there are dedicated accounts for recording most intercompany transactions. The exceptions to this rule are for Dividends Paid/Received; these accounts may also hold 3

rd party postings.

Several groups of intercompany accounts are defined.

Balance Sheet: o Receivables and payables, current o Financial assets and liabilities, current o Receivables and payables, non-current o Financial assets and liabilities, non-current

Income Statement: o Revenues / Cost of sales o Operating income / expenses o Non-Operating income / expenses o Interest income/expense

To facilitate the maintenance of the chart of accounts and business rules, intercompany eliminations are defined using the following account dimension properties:

Property Purpose

ISINTERCO

Used to indicate in input forms that an account can be used in the Intercompany Input form. For these

accounts, the Intercompany Input form may be accessed directly from the appropriate “balance” entry

Input form.

TYPELIM

Used to select accounts in the consolidation rules

Example: The accounts “Interest Income” and “Interest Expense” have the property TYPELIM =

CO_IC_IS

ELIMACC

Used to define the respective elimination account to be populated as offset on the journal entry at Entity

level

Example: The account “2111B” is defined in the property ELIMACC for the accounts “Intercompany

Receivables, Current” and “Intercompany Payables, Current”


30

Audit ID destination

The ICELIM Eliminations and Adjustment rule records intercompany eliminations on the AuditID IC_ELIM.

Method-based Multiplier

Intercompany eliminations are performed using the Consolidation Package, which triggers the Eliminations and Adjustments rules combined with the Method-based Multipliers.

For intercompany eliminations, several Method-based Multipliers are defined:

II10: consolidation methods for the ENTITY and INTERCO dimensions are: Holding (10), Full (20, 28)

II18: rules applicable when either the Entity or the partner has been defined as ‘divested during the year’ with method Full (28); triggers movement on FLOW dimension to F98

II19: rules applicable when either the Entity or the partner has been defined as ‘divested last year end’ with method Full (29); triggers movement on FLOW dimension to F98

These consolidation rules are defined with consolidation formula of “1” in all cases.

Explanations regarding the naming convention of the Method-based multipliers are available in Appendix C.100.

The main processing rows of the ICELIM Elimination and Adjustment rules define the following eliminations (additional rows for CO_IC_BS deal with divestitures, if they exist):

Source account

Source flow

Dest. All account

Dest. group account

Dest. flow Multiplier Applies to

CO_IC_BS All flow included in END

CO_IC_BS PROP(ELIMACC) Same as the source flow

II10 BS accounts Holding and Full methods

CO_IC_IS F10-Net Income (loss)

CO_IC_IS PROP(ELIMACC) Same as the source flow

II10 IS accounts Holding and Full methods

CO_IC_ SALES

F10-Net Income (loss)

CO_IC_ SALES

PROP(ELIMACC) Same as the source flow

II10 Revenue accounts Holding and Full methods

CO_IC_ SALES

F10-Net Income (loss)

31121 – Cost of Sales

PROP(ELIMACC) Same as the source flow

II10 Reverse value from above step, with “Swap Entity/Interco” designation


31

Automatic Interco Elimination: Example for Intercompany Receivables/Payables

11212 Intercompany Receivables, Current 2111B Receivables and Payables, Balancing

① Interco "B" 130 Interco "B" 130 ② ② Interco "B" 130

21112 Intercompany Payables, Current 2111B Receivables and Payables, Balancing

③ Interco "S" 120 Interco "S" 120 ① Interco "S" 120 ③

① Input Amounts

② Elimination at Seller

③ Elimination at Buyer

SELLER Entity "S"

BUYER Entity "B"

3.3.2. Elimination of Dividends

Rules: DIVIDENDS, EM_INV_DIVIDENDS


Dividends paid and received are automatically eliminated based on the receiver’s declaration. The elimination journal entry is posted in the receiver’s accounts (P&L and equity).

The impact on reserves / net income is shared between the group and non-controlling interests, based on the ownership rate of the receiver company. NCI is moved from the dividends received account into an NCI account on the P&L.

A manual adjustment journal entry can be posted if the declarations from the payer and the receiver do not match.

3.3.2.2. General Principles

Dividends are eliminated based on the detail reported by the receiving company in the dividends received P&L account (32210 / F10). Breakdowns by partner must be entered in order for eliminations to process; the Intercompany input form is used for this task.

In the equity section of the Balance Sheet, dividends paid can be reported by the subsidiary on the Retained Earnings account 24140, on flow F06-Dividends. Again breakdowns by partner must be entered; the Intercompany input form is used for this task also.

Any impact related to non-controlling interests is recorded by the DIVIDENDS Elimination and Adjustment Rule. Values for NCI are moved within the P&L prior to the elimination by partner(s).


32

3.3.2.3. Foreign Currency Conversion

On the payer’s side, the flow F06 is converted using the dedicated rate type, DIV (see FXRATE dimension in the RATES model). This rate can be populated in the rate table, and should be equal to the payer’s currency exchange rate at the date when the dividend was agreed by at the annual general meeting.

Using this rate will make the reconciliation of dividends paid/received easier, especially when the receiver’s reporting currency is the same as the consolidation currency.

When payer’s and receiver’s currencies are different, flow F80 – Currency translation adjustment is unbalanced: the difference is equal to dividend paid converted at DIV rate minus dividend received converted at the average rate.

The DIVIDENDS2 Elimination and Adjustment Rule balances flow F80 against flow F15 - Net variation on account A2610 - Cash on hand.

3.3.2.4. Dividends for an Equity Method Entity

EM_INV_DIVIDENDS: in case of an Equity Method entity, the Dividends Paid account is first apportioned by Group and NCI shares, in order that the DIVIDENDS rule will correctly offset any Group share of dividends received by the parent. The F06- Dividends flow value in account 24140- Retained Earnings is affected, thereby lowering the value available for elimination.

3.3.3. Elimination of Investments

Rules: INVESTMENTS, EM_INV


The internal investments in subsidiaries are automatically eliminated against equity during the consolidation.

The Starter Kit supports the automatic calculation of non-controlling interests in the investments when the owned-Entity is not 100% owned by the group.

3.3.3.2. Rule Configuration

Investments in subsidiaries (account 11213-Investments in subsidiaries) are recorded, and detailed by owned entities, using the Interco dimension.

The automatic elimination of group investments is triggered by the INVESTMENTS Elimination and Adjustment Rule. It is posted on a dedicated AuditID, INVESTMENTS- Elimination of investments.

Distinguishing the Impact on Flows by Operation Type o Any purchase or disposal of investments is dealt with in the rule by specifically by selecting F20 and F30 respectively, and defining F00 as the destination flow. Flow F98 is impacted depending on whether the held entity leaves the scope. o For other flows the destination is identical to the source (F01, F02, F15, F50) o Processing rows are also defined on the opening flow F00 in order to calculate possible changes in the consolidation rates or financial interest rates.

Balanced Entries at Both the Owner Company and the Held Company The elimination journal entry impacts both the owner and the held companies:

o Owner company (parent): the investment values are eliminated against the elimination account 1221B (owner company) at the ownership rate (POWN).


33

o Held company (subsidiary): the rule for elimination of investments triggers an entry on the group retained earnings, against the elimination account 1221B (held company). In case there are indirect non-controlling interests in the owner company, the impact on the retained earnings is split between group and non-controlling interest, based on the group’s share of the owner, and therefore calculated respectively with the POWN and 1-POWN formula used in the IS20, IS21 or IS23 Method-based Multipliers.

3.3.3.3. Equity Method Investments

Investments recorded for Equity method Entities (11212- Equity Method investments) are handled separately within rule EM_INV. This major difference in the two rules is that EM_INV also has rows that read/record values related to the technical account 91221-Techinical: Equity method investments, which keeps track of historical changes to the investment account for Equity method investments. This is required because these investments are typically written up (or down) for the owner’s share of the subsidiaries net income, and/or for dividends paid out from the subsidiary.

3.3.4. Goodwill (Interco Treatment)

Rules: GOODWILL1, GOODWILL2


Goodwill is booked in the local data, and as such is included in the INPUT AuditID when data is loaded. Intercompany breakdowns should be done as required for Goodwill as required; this may be done via the Input Form “Intercompany”, or included in Import files.

Based on this information, an automatic journal entry impacts the goodwill (assets) against the equity at the subsidiary level. If needed, the impact on the equity is split between the group and non-controlling interests based on the group’s share in the owner company.

3.3.4.2. Automatic Journal Entries

Automatic journal entries are posted at the subsidiary using the CONS_EQ AuditID, triggered by Eliminations and Adjustments Rules:

Goodwill treatment – Non-controlling interests

This automatic entry is triggered if an Entity reflects Goodwill related to an investment by a parent that has less than a 100% Ownership rate in said subsidiary. In this case, any Goodwill related to the investment must be apportioned in the equity section between Group share and NCI share.

Three rules are used in this case, as Goodwill reflecting a partner of I_NONE must be treated separately from Goodwill reflecting a real interco partner.

The Method-based Multipliers used in the full goodwill adjustment rules simply apply factor 1 to the selected amount since the amount declared in the journal entry is fully attributable to the non-controlling interests in this case.

3.3.5. Consolidated Equity Calculation

Rules: EQUITY, EM_INV_NETINCOME

3.3.5.1. Group and Non-Controlling Interests Split


34

The equity of consolidated companies is split between the group and non-controlling interests according to the following principle:

The accounts 24110-Preferred Stock, 24120-Common Stock, and 24130-Additonal Paid in Capital are transferred to the group retained earnings (24140) and retained earnings of non-controlling interests (24210) for any entity except the parent company of the group

For other equity accounts, the group share is maintained on the original account, and the non-controlling interest share is calculated on the related non-controlling interests account.

The relationship between source equity accounts and non-controlling interest equity accounts is summarized in the table below:

Group equity account (selection) NCI equity account (destination)

24110 Preferred Stock value, issued 24210 NCI - reserves and retained earnings

24120 Common Stock value, issued 24210 NCI - reserves and retained earnings

24130 Additional Paid in Capital 24210 NCI - reserves and retained earnings

24140 Retained Earnings (accum deficit) 24210 NCI - reserves and retained earnings

24150 Treasury Stock, value 24220 NCI – Treasury Stock, value

24161 OCI (loss), Foreign currency translation adjustment

24231 NCI - OCI (Loss), Foreign currency translation adjustment

24162 OCI (Loss), Available-for-sale securities adjustment

24232 NCI - OCI (Loss), Available-for-sale securities adjustment

24163 OCI (Loss), AFS securities, other than temp imp losses

24233 NCI - OCI (Loss), AFS securities, other than temp imp losses

24164 OCI (Loss), HTM securities, other than temp imp losses

24234 NCI - OCI (Loss), HTM securities, other than temp imp losses

24165 OCI (Loss), Cumulative gain (loss) from cash flow hedges

24235 NCI - OCI (Loss), Cumulative gain (loss) from cash flow hedges

24166 OCI (Loss), Pension and other post-retirement benefit plans

24236 NCI - OCI (Loss), Pension and other post-retirement benefit plans

Equity consolidation postings mentioned above are triggered by the following Eliminations and Adjustments rules:

EQUITY adjustment rule

Selects accounts via the CO_EQUITY1 and CO_EQUITY2 TYPELIM account property values. For accounts in the CO_EQUITY1 group, these accounts are cancelled out (see Destination “ALL” account) against the group retained earnings account and non-controlling interests retained earnings, accounts 24140 and 24210, used as destination in the Destination group account and Destination minority account columns. For accounts in the CO_EQUITY2 group, the accounts are cancelled out again themselves only for the portion that should be moved to dedicated NCI accounts for each equity account.

Note: for Equity method Entities, the rules essentially calculate and post the “net assets” as seen through the equity accounts, except the posting to Destination “ALL” is always to the asset account 11212- Equity method investments. This essentially “reinstates” the value of the investment at the net asset value of the Entity overall (remember, the Investment itself was eliminated in the INVESTMENTS rule). Any NCI is set aside in the appropriate equity accounts, as detailed above, and the income statement is also adjusted for any NCI effects.


35

Selects accounts via the CO_GOODWILL TYPEELIM account property values. Goodwill for Full method entities is posted related to the Asset value recorded, by flow when applicable, between group and NCI equity.

For that purpose, several Method-based Multipliers are used here so that for CO_EQUITY1, the original account is completely cancelled out (1 formula) and the group retained earnings and non-controlling interests retained earnings populated with the group share (POWN) and non-controlling interests share (1-POWN) respectively; but for CO_EQUITY2 and CO_GOODWILL, there is only movement in the original account and NCI accounts at formula 1-POWN.

These entries are booked on the CONS_EQ AuditID.

EM_INV_NETINCOME adjustment rule

Selects values in account 11212- Equity method investments / flow F10- Net Income (loss). These values are posted in local accounts when the Equity investment is written up for the parent’s share of the subsidiaries income. The values are cancelled out from the original account, and against group retained earnings (24140) and NCI (24210) as appropriate, based on Method based Multiplier IS20.

A reverse amount is also posted against Income Statement values for Income from equity method investments (33100) and Income attributed to non-controlling interests (37100), as appropriate.

The IS20 Method-based Multiplier applies the 1-POWN formula - that is, the original value is cancelled out (formula ‘1’), and the group and NCI interests are based upon POWN and 1-POWN, respectively.

These entries apply to all consolidation methods except the holding (main company), that is not only to full but also to the equity method (see below).

3.3.6. Integration: treatment of Holding, Full vs. Equity methods

Rule: INTEGRATION

Entities accounted for using the Equity method are handled by calculating the net assets, and posting those on the dedicated “equity method investment” account in the assets (11212, counterpart “retained earnings” in the net equity (24140). This is accomplished by the EQUITY rule as described above. In order to handle the fact that all local data cannot be included in reporting (data for equity method entities is not relevant in group reporting), the Starter Kit CONSOLIDATION model has been enhanced to use “integration rules”. This allows an Eliminations and Adjustments rule to be flagged as an “integration rule”, and this rule determines which entities should be “integrated” for group reporting.

Source account T0000- Balance Sheet (END flow) and account T3000 (F10 flow) are used, with a Destination “group” account and flow of the same values.

Method-based multiplier I000 imparts the formula of “1” for Group, and no other values. As a consequence of this “integration” rule, along with the CONSOLIDATION model setting of “use integration rules”, only those entities that use the methods indicated in I000 (holding, full) will be included in “group” reporting.

3.3.7. Ownership Changes

To produce the Statement of Cash Flows and the Statement of Changes in Equity, the impacts of status changes for entities in the ownership structure, such as incoming and divested companies, are tracked separately from other changes.

3.3.7.1. Defining dedicated Flows and Audit IDs


36

With an adapted configuration, the consolidation engine is able to automatically populate distinct flows with the amount of ownership change effects, depending on the changes in the Entity’s and/or the Interco’s status in the consolidation ownership structure. These flows are identified using the FLOW_TYPE property of the FLOW dimension.

This process is triggered on automatic-type AuditIDs for divestitures; the postings are included in all of the rules above for flow F01, F02, F92 or F98 as appropriate.

The Flows, flow types, and identification process are summarized in the following table:

Flow FLOW_TYPE Property

Entity Identification process by the consolidation engine

F01-Incoming units

VARSCPNEW Entity not included in the prior ownership structure

F02-Change in consolidation method

VARSCPMETH Current consolidation method is different from prior ownership structure

F92-Change in interest / consolidation rate

VARSCPPERC Current consolidation rate / interest rate is different from prior ownership structure

F98-Outgoing units

VARSCPLEAV Appropriate divestiture method assigned to the entity (see below)

3.3.7.2. Outgoing Units – General Case

For all outgoing units, the reversal of the closing position is identified to show and calculate the impact of outgoing balance sheet items. For Entities leaving the consolidation ownership structure at the beginning of the period, possible reported balance sheet movements and income statement items have no impact on the financial statements.

The following consolidation methods are created in the Business Rules in order to trigger the built-in process:

28 – Full, Divested last year end

29 – Full, Leaving during current year

38 – Equity, Leaving last year end

39 – Equity, Leaving during current year

The different Eliminations and Adjustments rules trigger the movement of the closing position of all outgoing units from flow F99 to flow F98. In addition, for Entities leaving the consolidation ownership structure at the beginning of the period, method “28 or “38” cancels out balance sheet flows and income statement items.

3.4. Account Based Calculation Rules Account Based Calculation Rules are used to build the Statement of Cash Flows, the Statement of Comprehensive Income, and the Statement of Changes in Equity.

The Statement of Cash Flows, which is retrieved according to the indirect method, derives from the Balance Sheet flows and the Income Statement accounts. It discloses cash effects from operating, investing and financing activities as required by US GAAP.


37

Specific accounts, whose ID begins with ‘4’, have been created to store the items of the Statement of Cash Flows. This makes it possible to post manual journal entries to correct the Statement of Cash Flows, using a dedicated AuditID “FS_ADJ – Adjustment on Financial Statements SCF, SCI, SCE”. These ‘5xxxx’ accounts are populated during the consolidation process by account-based calculation rules which:

Select financial accounts (BS and some of the P&L) via values in the property DIMLIST_FS

Select the relevant flows

Select all AuditIDs except the FS_ADJ AuditID

Generate the SCF account on flow F99, keeping the source AuditID.

Using the property DIMLIST_FS enables you to update easily the configuration when adding a new balance sheet account or relevant P&L account.

For example, the item 44111 – Repayments of debt, is generated within account-based calculation rule SCF, which aggregate the amounts stored on flow F30 – decrease of all accounts, where DIMLIST_FS is equal to FS-FIN-L1, FS-FIN-L2 and FS-DEBT-L1.


38

4. Controls

4.1. Set of Controls for Actual

To insure the correctness of consolidated statements, including the Statement of Cash Flows and the Statement of Changes in Equity, the quality of reported data is checked at the local level (Entity by Entity) for AuditIDs posting in LC (INPUT, LOCAL_ADJ, ADJ_LC_M).

The following groups of controls are performed via the Controls Monitor:

Balance Sheet: assets = liabilities + equity, balance of the opening and closing position, consistency of the gross value / amortization and impairment, net income in equity vs. P&L

Flows: authorized flows, balancing flows

Intercompany accounts (partner validity and breakdowns)

All the controls are grouped into several sets of controls:

A_FIRSTCONSO_CLOSING: no controls related to detailed flow reporting, and period = first consolidation for version

A_CLOSING: no controls related to detailed flow reporting

A_FIRSTCONSO_INFLOW: controls related to detailed flow reporting, and period = first consolidation for version

A_INFLOW: controls related to detailed flow reporting

Controls are divided into six types of controls:

Controls for prior year closing vs. current year opening flows (named A0_xx). For the balance sheet by account, and then for each intercompany account by partner, these controls check both opening balance and closing balance for consistency across years. These controls are broken down by AuditID to ensure the consistency of each input level.

Controls for balance analysis for Gross/Net accounts (named A1_xx). For accounts which have Gross and net components (such as PP&E), these controls check that the Gross component is greater than or equal to the net component, at both Opening (F00) and closing (F99). In addition, Total Assets and Total Liabilities are also checked for this control.

Controls for interco analysis (named A2_xx). For all interco accounts (B/S and P&L), controls check that the sum of interco amounts (I_ALL) is lower than or equal to the total amount (I_NONE).

Controls for Flow analysis (named A3_xx). For each account for which a flow analysis is required, these controls check that the Net variation flow (F15) is equal to zero. Several controls also check that the total value of some specific flows is balanced (“F50-Reclassification”, “F05-Change in accounting policies”, “F01-Incoming”). These controls are broken down by AuditID to ensure the consistency of each input level.

Controls for interco by flow analysis (named A4_xx). For certain interco accounts, controls check interco changes do not have a residual value in the Net variation flow (F15); in other words, at each partner that flow equals zero.

Flow consistency (named T_00). Checks that for each B/S account, the closing balance (flow=F99) equals the sum of opening balance and the movements (calculated in the END parent member). This control is broken down by account and AuditID. Although the Starter Kit calculations ensure that the F99 flow equals the END flow when using Input forms and when importing files, the user can still deactivate the default logic upon import of a file. Because the default logic triggers the calculation of the Net Variation flow (F15): this would result in a mismatch of the F99 flow and the END flow.


39

All controls are assigned the “Blocking” type. Therefore the control status is checked when the work status is changed in the Consolidation Monitor.

5. Reports

Input forms and Reports are defined by using the EPM Office Excel Add-In.

5.1. Input Forms

The Actual version data entry is performed using several input forms, located here: ‘Server Input Form Folder > ACTUAL > INPUT FORMS’.

Input form name Use

10 Balance Sheet.xlsx Allows entering BS data (opening and closing balances)

20 Profit and Loss.xlsx Allows entering P&L data (closing balances)

30 Intercompany.xlsx Allows the user to input details by interco partner for one account selected in the EPM context.

40 Balance Sheet by Flow.xlsx Allow entering details by flow for the BS

5.1.1. Members Selection

Dimension members are selected in the input forms using the Member Selector features. The selections are defined using the hierarchy PARENTH1, base members, properties, or a combination of these. To ease the enhancement of the Starter Kit configuration, selections are “dynamic” so that new members will be automatically inserted in the forms and reports provided that these members are assigned the correct parent member and properties.

The tables below list the properties used for the members selection in the Input forms.

Dimensions Property Examples

Account INPUTFLOWS F20 F30 F25 F00 F99 F05 F50

ISINTERCO IC, ICM

5.1.2. Formatting

Formatting of the Input forms is defined in Formatting Sheets.

Depending on the formatting requirements of the Input form, several Formatting Sheets have been defined:

Input (which applies to the Balance Sheet and Income Statement input forms)

InputFlow (which applies to Balance Sheet by flow input form)

Intercompany (which applies to Intercompany input form)


40

Formatting is based on the vales defined in the account property Style (N, T7…), and can be defined by specific members/property values:

5.1.3. Specific Settings

Intercompany Input Form

To enable the insertion of new interco members by the user, the EPM function “Activate Member Recognition” is selected in the Sheet Options.

Flow Analysis Input Form

Excel conditional formatting is also used in the formatting sheet to stripe the cells which correspond to an incorrect Account / Flow combination. This is defined as follow:

In the report, a local member is defined, with the EPMMemberProperty, to fetch the INPUTFLOWS property which contains the list of possible flows for each account. This property is then used in the conditional formatting formula. However, the value of the INPUTFLOWS property is not visible, because of a specific format applied to this local member.

In the Formatting Sheet, an Excel conditional formatting is defined for the “base level” row. This conditional formatting is based on a formula which checks that the flow ID in the column header is included in the INPUTFLOWS property value of the account in the row. When this is not true, the cell is striped.

This conditional formatting works if the following conditions are met: o The flow ID must be 3 digits long (example: F50) o The cell named “col_inputflows” must contain the column number with the INPUTFLOWS property (column 4 in the delivered input forms) o The cell named “row_flow” must contain the row number of the flow (row 7 in the delivered input forms)

5.1.4. Workbook Protection

Input forms (but not reports) are password protected. Password protection prevents users from changing, moving, or deleting important elements of the workbook. In this Starter Kit, the password is SAP.

To remove the password, select EPM > Options > Sheet Options, then select the Protection tab and enable the No Protection option.

Choose a password that is easy to remember, because if you lose the password, you can no longer access the protected worksheet or workbook.

For more information about password protection, see the EPM Add-in and Microsoft Excel documentation.

5.2. Reports

5.2.1. List of Reports

Actual reports provided in the Starter Kit are located in two places:

Server Input Form Folder > ACTUAL > LOCAL REPORTS > detailed reports

Server Report Folder > ACTUAL > detailed reports, in folders for Financial Reports, Analysis Reports, Breakdown Reports, and Control Reports


41

Reports in the Server Report Folder are listed below:

Subfolder Report name Content

10 Financial Statements

10 Income Statement.xlsx

11 Statement of Other Comprehensive Income.xlsx

12 Statement of Financial Position.xlsx

13 Statement of Cash Flows.xlsx

14 Statement of Changes in Equity.xlsx

These are the US GAAP Financial Reports

20 Analysis Reports

20 IS by AuditID.xlsx

21 IS by Entity.xlsx

22 SCI by AuditID.xlsx

23 SCI by Entity.xlsx

24 BS by Flow.xlsx

25 BS by AuditID.xlsx

26 BS by Flow and AuditID.xlsx

27 BS by Entity.xlsx

28 SCF by AuditID.xlsx

29 SCF by Entity.xlsx

These reports provide additional details of the B/S and I/S by Flow, AuditID, Entity.

30 Breakdown Reports

30 BKD by Entity.xlsx

31 BKD by AuditID and Interco.xlsx

These reports provide the details of an account balance by entity or partner. The account is selected in the EPM Context.

40 Control Reports

40 Dashboard.xlsx

41 A=L by AuditID.xlsx

42 BS = IS by AuditID.xlsx

43 Flow Balance by AuditID.xlsx

44 A=L by Entity.xlsx

45 BS = IS by Entity.xlsx

46 Flow Balance by Entity.xlsx

47 Opening Balance Integrity.xlsx

These reports provide additional controls, such as clearing accounts, flows that should be balanced, controls by AuditID...


42

Local Reports in the Server Input Form Folder are below:

Subfolder Report name Content

Local Reports

90 Statement of Financial Position.xlsx

91 Income Statement.xlsx

92 Intercompany Control Report.xlsx

93 Consistency between opening balance and previous year closing.xlsx

94 Statement of Cash Flows.xlsx

These are reports that can be used by local users to verify and validate data prior to

submission

5.2.2. Members Selection

The tables below list the properties used for the members selection in the Reports.

Dimensions Property Examples

Account STYLE N, T7…

ISINTERCO IC, ICM

For period comparison, the member selection for the TIME dimension is defined using the Offset function.

5.2.3. Formatting

Depending on the formatting requirements of the Reports, several Formatting Sheets have been defined.

Formatting Sheets “Format R1” and “Format R2” are most commonly used.

5.2.4. Drill Down

Financial Statement Reports are built with the ability, when applicable, to drill down directly from a cell into another, more detailed report (an Analysis or Control report, for instance). Colored marks on a cell will indicate that you may drill down from that cell.

6. Business Process Flows

The consolidation scenario for actuals is divided into 2 main Business Process Flow (BPF) types:

INPUT tasks: Load files or manual entry of balance sheet, income statement, breakdown by movement and intercompany; run data validation; view local reports; and data submission.

CONSOLIDATION tasks: Exchange rates; consolidation ownership structure; copy opening balances; run preliminary checks, post manual journal entries; run consolidation; check the consolidation dashboard; view financial reports; view analysis reports; view breakdown reports; view control reports

There are 2 versions of each of the BPF types noted above:

Version 1 (denoted _CLOSING) is used when there is no need for detailed FLOW reporting within the group. This version eliminates tasks where accounts are broken down by detailed flows, and also does not include SCF, SCI or SCE reporting

Version 2 (denoted _INFLOW) is used when detailed FLOW reporting is required, and includes all tasks required to accomplish this, including SCF, SCI and SCE reporting


43

The INPUT BPF is designed for local users, whereas the CONSOLIDATION BPF is designed for central users. One consolidation process is defined for all consolidation frequencies (monthly, quarterly…).

The high-level process, across the two BPFs, is shown below:

CONSOLIDATION

Exc

hang

e Rat

es

Owne

rship

Chan

ges

Copy

Ope

ning

Work

Sta

tus

Ck

INPUT

Ent

er D

ata

Validat

e Dat

a

Run

loca

l rep

orts

CONSOLIDATION

Man

ual J.E

.'s

Inte

rco Rec

on

Gro

up

INPUT

Inte

rco Rec

on

Loca

l

Sub

mit Data

CONSOLIDATION

Cons

olidat

ion

Cont

rol R

eports

Ana

lysis

Repo

rts

Bre

akdow

n

Repo

rts

Finan

cial

Repo

rts


44


45

C. APPENDIX

1. Input form - Example of F15-Net Variation Control

2. Example of INPUTFLOWS Property Values


46

3. Consolidation.lgf Logic Script

*RUN_PROGRAM CURR_CONVERSION

CATEGORY = %VERSION_SET%

GROUP = %SCOPE_SET%

TID_RA = %TIME_SET%

//OTHER = [ENTITY=%ENTITY_SET%]

FXRATENTITY = GLOBAL

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// The automatic adjustments process is handled by a program called CONSOLIDATION. This program is typically launched using the

following logic statement:

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*RUN_PROGRAM CONSOLIDATION


GROUP = %SCOPE_SET%

TID_RA = %TIME_SET%

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating Consolidated Financial Statements (SCF, SCI, SCE)

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*RUN_PROGRAM CALC_ACCOUNT.LGF


//CURRENCY = %CURRENCY_SET%

TID_RA = %TIME_SET%

CALC = SCF

OTHER = [GROUP = %SCOPE_SET%]

*ENDRUN_PROGRAM




TID_RA = %TIME_SET%

CALC = SCI


*ENDRUN_PROGRAM



47



TID_RA = %TIME_SET%

CALC = SCE


*ENDRUN_PROGRAM


48

4. Default.lgf Logic Script

// This script contains the logic which is executed whenever data is entered and sent

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating Account 24140 " Retained earnings" - Flow F10 "Net income of the period" in the balance sheet

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*RUN_PROGRAM CALC_ACCOUNT


CURRENCY = LC

TID_RA = %TIME_SET%

OTHER = [INTERCO=I_NONE]

CALC = NETINCOME

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating F15 - net variation as the difference between closing and the sum of other balance sheet flows

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



CURRENCY = LC

TID_RA = %TIME_SET%

CALC=FLOW_CALC

*ENDRUN_PROGRAM


49

5. Journal.lgf Logic Script

// This script prevents the application from running the default logic in manual journal entry context

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating Account 24140 " Retained earnings" - Flow F10 "Net income of the period" in the balance sheet

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



TID_RA = %TIME_SET%

OTHER = [INTERCO=I_NONE]

CALC=NETINCOME

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating flow F99 as being the sum of opening flow + movements in the balance sheet

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



TID_RA = %TIME_SET%

CALC=JRN_CLOSING_BAL

*ENDRUN_PROGRAM


50

6. Copy_Opening.lgf Logic Script

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// COPY OPENING PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*RUN_PROGRAM COPYOPENING


CURRENCY = %CURRENCY_SET%

TID_RA = %TIME_SET%

OTHER = [ENTITY = %ENTITY_SET%]

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating F15 - net variation as the difference between closing and the sum of other balance sheet flows

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*SELECT (%AUDIT_TRAIL_I,"[ID]",AUDIT_TRAIL,"[DATASRC_TYPE] = 'I'")



CURRENCY = LC

TID_RA = %TIME_SET%

OTHER = [ENTITY = %ENTITY_SET%,AUDIT_TRAIL=AUDIT_TRAIL_I]

CALC=FLOW_CALC

*ENDRUN_PROGRAM

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Calculating flow F99, for journal entries, as being the sum of opening flow + movements in the balance sheet

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*SELECT (%AUDIT_TRAIL_M,"[ID]",AUDIT_TRAIL,"[DATASRC_TYPE] = 'M'")



TID_RA = %TIME_SET%

OTHER = [ENTITY = %ENTITY_SET%,AUDIT_TRAIL=AUDIT_TRAIL_M]

CALC=JRN_CLOSING_BAL

*ENDRUN_PROGRAM


51

7. Push_To_ICMatching Logic Script

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// PUSH DATA TO ICMATCHING MODEL

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Synchronize the ICMatching data with the Consolidation model

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

*DESTINATION_APP = ICMatching

*RENAME_DIM AUDIT_TRAIL = ICAUDITID

*RENAME_DIM ACCOUNT = ICACCOUNT

*SKIP_DIM = SCOPE

*SELECT(%INTERCOACCOUNTSACT%,"[ID]", "ICACCOUNT","ISINTERCO = 'Y' )

*XDIM_MEMBERSET ACCOUNT = %INTERCOACCOUNTSACT%

*WHEN VERSION

*IS ACTUAL

*WHEN INTERCO

*IS <> I_NONE

*WHEN CURRENCY

*IS = LC

*REC(FACTOR = 1)

*ENDWHEN

*ENDWHEN

*ENDWHEN

*COMMIT


52

8. Conversion_ICData Logic Script


//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

// Currency conversion is handled by a program called CURR_CONVERSION. This program is launched using the following logic

statement

//------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



GROUP = %SCOPE_SET%

TID_RA = %TIME_SET%

OTHER = [ENTITY=%ENTITY_SET%]

FXRATENTITY = GLOBAL

*ENDRUN_PROGRAM


53

9. Carry Forward Rules


54

10. Naming Convention for Method-based Multipliers

Digit 1 2 3 4

Possible

Values Entity Interco Formula Variation in Scope

1 H: Holding 0: all 0: 0/1/0 (integration rules)

0: Entity and Interco: including divested during

current year

2 F: Full F: Full 1: 1/1/1

1: Entity: including divested during current year,

Interco: including divested during current year

and divested last year end

3 I: Holding+Full I: Holding+Full 2: 1/POWN/1-POWN

2: Entity and Interco: including divested during

current year and divested last year end

4 E: Equity E: Equity 3: 1-POWN/0/1-POWN


Interco: not divested

5 S: Full+Equity S: Full+Equity 4: PCON/POWN/1-POWN


Interco: divested

6 6: 1-I_POWN/0/1-I_POWN

7: Entity: divested, Interco: including divested

during current year and divested last year end

7

8: Entity or/and Interco: divested during current

year

8 9: Entity or/and Interco: divested last year end


55

© 2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, 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 other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and

other Business Objects products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP

company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein

as well as their respective logos are trademarks or registered

trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are

registered trademarks of Crossgate AG in Germany and other

countries. Crossgate is an SAP company.

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.

www.sap.com