SAP Help - bpc10 PDF

Administration
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_bpc10_nw/helpdata/en/4c/2c541197df1ca9e10000000a42189e/content.htm
Created on November 17, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2014 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose
without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE 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. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 102
Table of content
1 Administration
1.1 Environment Management
1.1.1 New Environments
1.1.2 EnvironmentShell Sample Environment
1.1.3 Environment Status
1.2 Dimension Management
1.2.1 New Dimensions
1.2.2 Dimension Types
1.2.3 Dimension Security
1.2.4 Dimension Processing
1.2.5 Dimension Member Management
1.2.6 Assignment of Dimensions to Models
1.2.7 Custom Measure Formulas
1.2.8 Dimension Properties
1.2.8.1 Owner Property
1.2.8.2 Reviewer Property
1.2.8.3 Account Dimension Properties
1.2.8.4 Category Dimension Properties
1.2.8.5 Currency Dimension Properties
1.2.8.6 Entity Dimension Properties
1.2.8.7 Group Dimension Properties
1.2.8.8 Intercompany Dimension Properties
1.2.8.9 Time Dimension Properties
1.2.8.10 User-Defined Dimension Properties
1.2.8.11 Audit Dimension Properties
1.2.8.12 Subtable Dimension Properties
1.3 Model Management
1.3.1 Reporting Models
1.3.2 Drivers and Rates Models
1.3.3 Large Key Figure Usage
1.3.3.1 Activate Large Key Figure Support in the SAP Reference IMG
1.3.3.2 Modify Existing Models for Large Key Figure Usage
1.3.3.3 Create New Models that Use Large Key Figures
1.3.4 Stabilizing Cube Names
1.4 Legal Consolidation
1.4.1 Create an Environment
1.4.2 Dimension Setup in Dimension Library
1.4.3 Create or Modify Dimension Properties
1.4.4 Master Data (Dimensions) Setup
1.4.5 Create or Modify the Model
1.4.6 Set the Model Parameters (version for the Microsoft platform only)
1.4.7 Business Rule Setting
1.4.8 Execute Consolidation Task
1.4.9 Loading Data
1.4.10 Journal Definition and Validation Setting
1.4.10.1 Example
1.5 Rules
1.5.1 Member Formulas
1.5.1.1 MDX Formula Syntax
1.5.1.1.1 Simple Rule Formula Examples
1.5.1.1.2 Advanced Rule Formula Examples
1.5.1.1.3 Nested Formulas
1.5.2 Script Logic
1.5.2.1 Library of MDX Functions
1.5.2.1.1 Custom Logic and BADI
1.5.2.2 Logic Keyword Reference
1.5.2.2.1 *ADD / *ENDADD
1.5.2.2.2 *BEGIN / *END
1.5.2.2.3 *DESTINATION_APP
1.5.2.2.4 *FOR / *NEXT
PUBLIC
Page 2 of 102
1.5.2.2.5 *FUNCTION / *ENDFUNCTION

1.5.2.2.6 *INCLUDE
1.5.2.2.7 *REC
1.5.2.2.8 LOOKUP
1.5.2.2.9 *RUNALLOCATION
1.5.2.2.10 *SELECT
1.5.2.2.11 *SELECTCASE / *ENDSELECT
1.5.2.2.12 *SUB( ) / *ENDSUB
1.5.2.2.13 *WHEN / *ENDWHEN
1.5.2.2.14 *XDIM_MEMBERSET
1.5.2.2.15 *XDIM_ADDMEMBERSET
1.5.2.2.16 *XDIM_MAXMEMBERS
1.5.2.2.17 *XDIM_PACKAGEBY
1.5.2.2.18 *XDIM_FILTER
1.5.2.2.19 *COMMIT
1.5.2.2.20 Special Keywords
1.5.2.2.21 TMVL Parameter
1.5.3 Validations as Script Logic
1.5.4 US Eliminations as Script Logic
1.5.5 Carry-Forward as Script Logic
1.5.6 Intercompany Booking as Script Logic
1.5.7 Currency Conversion as Script Logic
1.5.8 Account-based Calculations as Script Logic
1.5.9 Business Rules Management
1.5.9.1 Account-based Calculation Rule
1.5.9.2 Currency Translation Rule
1.5.9.3 Intercompany Booking Rule
1.5.9.4 Carry-Forward Rule
1.5.9.5 US Eliminations Rule
1.5.9.6 Eliminations and Adjustments Rule for Legal Consolidation
1.5.9.6.1 Method-based Multipliers and Consolidation Methods
1.5.10 Controls
1.5.10.1 Create a Control
1.5.10.2 Create a Control Set
1.5.10.3 Assign Control Sets
1.6 Business Process Flow Management
1.6.1 Creating New Process Templates
1.6.1.1 Process Settings
1.6.1.2 Activities
1.6.1.2.1 Criteria for Defining Activities
1.6.1.2.2 Defining Activity Context Criteria
1.6.1.2.3 Criteria for Opening Activities
1.6.1.2.4 Criteria for Reopening Activities
1.6.1.2.5 Owner Property
1.6.1.3 Defining Actions
1.6.2 Creating Processes
1.6.3 Process Management
1.7 Features
1.7.1 Work Status Setup
1.7.1.1 Setup of Data Locking Settings
1.7.1.2 Work Status Example
1.7.2 Journal Administration
1.7.2.1 Journal Template Creation
1.7.2.1.1 Journal Reopen Rules
1.7.2.1.2 Journal Model Parameters
1.7.2.2 Journal Security
1.7.2.3 Delete All Journal Entries from Model
1.7.2.4 Limits to Dimension Members for Journal Entries
1.7.2.5 Data Modification by Journal Entries Only
1.7.2.6 BAdI for Generating Calculated Amounts When Saving a Journal
1.7.3 Context Defaults
1.7.4 Drill-Through Setup
PUBLIC
Page 3 of 102
1.7.5 Document Types and Subtypes

1.7.6 Auditing
1.7.6.1 Activity Auditing
1.7.6.2 Data Auditing
1.7.7 Time-Dependent Hierarchies
1.7.7.1 Enabling Time-Dependent Hierarchy Functionality
1.7.8 Parallel Execution
1.7.8.1 Enabling Parallel Execution
PUBLIC
Page 4 of 102
1 Administration
Use
In the Administration screen, administrators perform setup and maintenance tasks.
Features
Setup and maintenance of Planning and Consolidation consist of the following tasks:
Environment management
Dimension management
Model management
Security management, which is explained in the Security Guide
Management of rules for member formulas, logic scripts, business rules, and controls
Set up of business process flows
Set up of work statuses
Set up of journals
Set up of context defaults
Configuration of drill-through
Management of document types and subtypes
Set up of auditing
1.1 Environment Management

Use
An environment consists of one or more models. An environment stores all the data from each model. Each model contains the master data that controls the data in
the environment. Models can share one or more dimensions with other models within the environment.
Features
Adding New Environments
Administrators create new environments by copying information from the EnvironmentShell sample environment that is delivered with Planning and Consolidation.
See New Environments.
Setting the Environment Status
The environment status determines when and how users can log on and interact with the data. See Environment Status.
Setting the Template Version
If you have made changes to any of the dynamic templates for reports or schedules, you can force an update of template files by changing the template version.
Therefore, clients that log on to the environment receive the new templates. You can set template versions by choosing Manage All Environments , selecting an
environment, then choosing Set Template Version . Increment template versions by 1.
Viewing User Activity
Planning and Consolidation logs user and administrator behavior. You can view activity logs by choosing Manage All Environments , selecting a environment,
then choosing User Activity .
Using E-Mail Notifications
Administrators can use an e-mail notification service to send e-mails to users or teams defined in the system. The appropriate SMTP parameters must be set up
correctly. For more details, see the SAP BusinessObjects Planning and Consolidation 10.0 IMG Guide .
Deleting Environments
You can delete environments after choosing Manage All Environments and selecting a environment.
Caution
You can delete an environment when it contains data. You cannot, however, delete a dimension member when there is data associated to that member in a
model.
Additional Information
The following information is important when managing environments:
An environment is equivalent to an InfoArea within NetWeaver with nearly all unique objects within this InfoArea.
No objects are shared across environments, except delivered properties such as scaling, formula, and so on. An InfoArea is like a folder, where in the case
of an environment, it is much more delineated.
You can transport environment changes between development and production systems. For more information, see the operations guide on SAP Service
Marketplace at http://service.sap.com/instguidesEPM-BPC .
More Information
EnvironmentShell Sample Environment

PUBLIC
Page 5 of 102

Use
You create new environments by copying the EnvironmentShell sample environment or an existing environment.
Features
You can copy all the components from a source environment to the target, which includes, but is not limited to, business process flows, drill-throughs, audit,
security, work status, transaction data, documents, journals, and Library view data. You have the option to not copy database records, documents, and Library
view data. After the copying is complete, you can begin to modify the default models, add new ones, and assign users to them.
When you create a new environment, Planning and Consolidation does the following:
Copies the environment WebFolders/data within File Service and user workspaces
Creates a copy of all NetWeaver BI objects
Copies all transactional and master data from the source environment to the new environment
Copies security and Planning and Consolidation metadata
If the system encounters an error when copying a environment, it rolls back to clear the objects created during the failed copy.
Activities
You add a environment by choosing Manage All Environments , then copying an existing environment. When you create the copy, you assign a name and
description to the new environment and indicate which records you want copied from the source.
More Information
EnvironmentShell Sample Environment
1.1.2 EnvironmentShell Sample Environment

Use
You can use the EnvironmentShell sample environment to create your own environments.
Because it is a shell, it needs to be populated with publications and reports to become a fully functional environment. The EnvironmentShell sample environment
does not contain any data except Time dimension information, and has only a limited amount of master data in the form of dimension members. The dimension
master data is limited to default members in most dimensions so the environment works when an administrative task is run.
When you install a new version of Planning and Consolidation, the EnvironmentShell sample environment and its components are overwritten.
Caution
You must not modify the EnvironmentShell environment.
Features
The EnvironmentShell environment contains the following components needed to build a functioning environment:
Four sample models - Planning, Rate, Consolidation, and Ownership - that contain most of the functionality you need to start building your own environment.
The Planning model is a multi-currency financial model. It is designed, by default, to accommodate currency translation.
The Rate model, which stores the currency rates, is assigned to the Planning model as a supporting model. The combination of the two models allows
for the calculation of currency conversions.
The Consolidation model contains consolidation information, such as percent ownership, percent control, percent consolidation, and the consolidation
method to child members.
The Ownership model is a supporting model for a consolidation reporting model. It stores information such as the consolidation methods, ownership
percentages, and group roll up information used for legal consolidation.
If you need to build more complex environments, for example, for legal reporting, you can build an environment using the components included within
EnvironmentShell.
A set of dynamic report and input schedule templates
Data Manager packages
Blank documents in the Documents view and reports in the Library view
Required administration setup parameters
All required dimensions with the properties needed to create a basic planning and consolidation environment
Dimensions in the EnvironmentShell sample environment
Unified dimensions for Planning and Consolidation models
Dimensions
Models
Type ID
Dimension ID
Dimension
Planning
Consolidation
Rates
Ownership
Description
C
CATEGORY
Category
TIME
Time
ENTITY
Entity
PUBLIC
Page 6 of 102
ACCOUNT
Account
AUDITTRAIL
Audit Trail
RPTCURRENCY
Reporting Currency
INTERCO
Intercompany Partner
Dimension
Planning
Consolidation
Dimensions specific to Consolidation

Dimensions
Models
Type ID
Dimension ID
Rates
Ownership
Description
G
SCOPE
Scope
FLOW
Flow
Dimension specific to Planning

Dimensions
Models
Type ID
Dimension ID
Dimension
Description
Planning
PRODUCT
Product
Planning
Consolidation
Rates
Ownership
Consolidation
Rates
Ownership
Dimensions specific to the Rates model

Dimensions
Models
Type ID
Dimension ID
Dimension
Description
R_ACCOUNT
Rate Account
R_ENTITY
Rate Entity
INPUTCURRENCY
Input Currency
Dimension specific to the Ownership model

Dimensions
Models
Type
ID
Description
O_ACCOUNT
Ownership Account
Planning
Consolidation
Rates
Ownership
X
More Information
New Environments
Environment Management
Dimension Types
1.1.3 Environment Status

Use
An environment can have a status of either Online or Offline . A newly created environment has a status of Offline until an administrator makes it available for
use by giving it a status of Online . When an environment is offline, users may be restricted from performing data retrieval and export tasks.
Features
When users attempt to log on to an environment that is offline, the system displays a warning and may open the environment to work offline on parked or locked
documents. Users can also query the model information, but the data may not be completely up-to-date.
Activities
You can manually set the status of an environment by choosing
Manage All Environments
Change Status
You can enter a message to display to users who try to perform a restricted task while the environment is offline. We recommend including the current date and
time and giving an estimated time of when the environment will become available, if appropriate.
More Information
Environment Management
1.2 Dimension Management

PUBLIC
Page 7 of 102
Use
A dimension is a collection of related data members, which represents one aspect of a business; for example, accounts, products, or currency. You manage
dimensions to add and perform other operations on dimensions within your environments, such as defining members and assigning properties. The dimensions
can be added to one or more models in the environment.
Features
You can manage dimensions in the following ways:
Task
More Information
Adding Dimensions
You can add new dimensions to an environment to make them available for use in its
models.
See New Dimensions.
Copying Dimensions
You can copy existing dimensions to create new dimensions. When you copy a
dimension, you specify the source dimension, a new name, and a description.
See New Dimensions.
Modifying Dimensions
You can modify an existing dimension. When you modify a dimension, you can change
the name, description, dimension type, reference dimension, and dimension properties
as well as enable member formulas for the dimension.
See New Dimensions.
Processing Dimensions
When you create a dimension or make changes to an existing dimension, you need to
process the dimension.
See Dimension Processing.
Deleting Dimensions
You can delete a dimension from an environment. However, you cannot delete a
dimension when it is already assigned to a model.
You delete a dimension from an environment by selecting a dimension and choosing
Delete .
Activities
To manage dimensions, select
of the available tasks.
Dimensions and Models
Dimensions
from the Administration screen. Once you select a dimension, you can perform one
More Information
Dimension Types
Dimension Security
Dimension Processing
Dimension Member Management
Assignment of Dimensions to Models
Dimension Properties
1.2.1 New Dimensions

Use
You add dimensions to an environment to make them available for use by its models. To add a dimension to an environment, you can create a new dimension or
make a copy an existing dimension.
Features
When adding a dimension using the New Dimension wizard, you supply the following information. This information is also useful when copying or modifying a
dimension.
Field
More Information
ID
Dimension IDs are not case sensitive and display in the case you typed. They must be
unique regardless of case.
You can use any ID you want for a dimension as long as you follow these guidelines:
Do not use special characters such as accented characters or Cyrillic fonts in IDs.
Enter a maximum of 16 characters and without single quotation marks ('), double
quotation marks ("), back slashes (\), or ampersands (&).
Dimension IDs cannot contain a dash (-), but can contain an underscore (_).
Do not begin a dimension ID with a number as its first character.
Do not use the following names: App, AppAccess, AvlObject,
CategoryAccess, CollabDoc, CollabIcons, CollabRecipient,
CollabSupport, CollabType, DBVERSION, Defaults, DesktopStyleDef,
Dimension, DrillDef, DTIParam, Function, Formula, Group,
InvestParam, MemberAccess, MessageLog, Packages, PageDef,
PUBLIC
Page 8 of 102
Permission, PublishedBooks, Rate, ReportParam, SectionDef,

Status, StatusCode, TaskAccess, User, UserGroup, UserPackages,
UserPovDef, WebContents, SOURCE, SIGNEDDATA
Description
Create dimension descriptions with a maximum of 255 characters.
Type
The dimension type allows you to organize data within models based on the type of
information included.
See Dimension Types.
Referential Integrity
Referential Integrity validates the properties of the dimension with the dimension
member IDs of a different dimension.
When you process the dimension, the system checks the values of the Referential
Integrity property (see Dimension Processing). Validation does not complete if they do
not pass validation.
See the following table for the dimension validation rules.
Dimension properties
You can assign new properties to a dimension.

See Dimension Properties.
Dimension Validation Rules

Dimension Type ID - Description
Reference Type ID - Description
Property ID
Reference Property ID
A - ACCOUNT
A - ACCOUNT
RATETYPE
ID
C - CATEGORY
T - TIME
YEAR
YEAR
E - ENTITY
R - CURRENCY
CURRENCY
ID
I - INTERCOMPANY
E - ENTITY
ENTITY
ID
Activities
You can create a new dimension in the Administration screen by choosing
required data.
Dimensions
New Dimension
, then entering the
1.2.2 Dimension Types

Use
You use dimension types to organize data within models based on the type of information involved. An environment can have multiple dimensions of one type.
Each model within the environment, however, can have only one of each of the required types. For example, the environment might contain the entity dimensions
EntityB and EntityF , with the Budgeting model using EntityB and the Forecasting model using EntityF .
The following table describes the types of dimensions within Planning and Consolidation:
Type ID
Type Description
More Information
Account
Usually contains chart of accounts and other planning

assumption measures. The dimension is normally
Category
represented by a hierarchy of accounts.

This represents the versions or scenarios based on which
data would be tracked. It contains the types of data you are
going to track, such as Actual, Budget, and Forecast. You
can set up categories to store versions, such as BudgetV1,
BudgetV2, and so on.
D
Audit
This represents the various data source that could be used

to manage the main data and adjustments if any. This can
be used very effectively in calculations and in business
rules of a reporting consolidation model to segregate input
data
Entity
Represents the business units that are used to drive the

business process. Depending on your model design, the
Entity type can be an operating unit, a cost center, a
geographic entity, and so on. This represents the
organization unit, whether defined for legal purpose or
from a business angle. This could be cost center, profit
center, legal company or region. The dimension is
normally represented by hierarchy of entities.
Group
Reports consolidated results in multiple group currencies

within a single entity structure. Group provides multiple
currencies for a group member.
Note
Assign both an R and a G identifier to a consolidation
model but assign only the G identifier to the
ownership model referred from the consolidation
model. You cannot assign both an R and a G identifier
to the same ownership model.
I
Intercompany
PUBLIC
Contains the intercompany codes for the entities. This
Page 9 of 102
represents the intercompany codes for the purposes of

legal consolidation intercompany matching and
elimination.
R
Currency
Contains the currency rates for all currencies in which

your company does business. For validation purposes, all
environments must contain a Currency dimension;
however, each model within an environment is not
required to have a Currency dimension. The Currency
dimension in a Reporting model must contain the
REPORTING property; the Currency dimension in a Rate
non-reporting model does not need to contain the
REPORTING property. For information about reporting and
non-reporting models, see Model Management.
Subtables
This is used to break down the account activity or flow. For

example, some accounts, such as Fixed Assets, have a
Subtables dimension containing Opening, Additions,
Deletions, Transfers and Ending Balances. The Subtables
type dimension is important for writing business rules that
require currency translation amounts to be calculated by
account.
Time
Contains the time periods for which you store data. This
represents the time periods based on which data are
stored. The time periods could be represented in various
forms such as weekly, monthly, quarterly or custom.
User-defined
This represents any User-defined dimension that may be

required for the planning process. Referred to in the
system as U1, U2, U3, and so on.
More Information
Model Management
1.2.3 Dimension Security

Use
Security of dimensions is at the model level. You secure a dimension within a model. Dimension security controls access to dimensions and their members.
Features
You can utilize the following features to secure dimensions:
Secured and Unsecured Dimensions
You can have a mixture of secured and unsecured dimensions in a model. Securing dimensions allows you to control which users or teams have read, write or
deny access to dimensions and their members. You need to define a dimension as secured if you want to control member access by specific dimensions. All
users can access unsecured dimension members.
Data access profiles are used to grant model access. At least one dimension in a model should be secured to ensure control over model and data access. When
defining member access for secured dimensions, be sure to define access for all secured dimensions of the model. Failure to do so results in the inability to
access that model for any users or teams assigned to the member access profile. For more information about setting up member access profiles, see Member
Access Profile Setup in the SAP Planning and Consolidation NW Security Guide.
Security for Member-level Dimensions
In addition to defining dimensions as secure for individual models, you can assign write access to members within the dimension using member access profiles.
Since by default, users do not have access to any members of a secured dimension, member access profiles must be set up for the users you want to give
read-only or write access.
1.2.4 Dimension Processing

Use
When you create a dimension or make changes to an existing dimension, you must process the dimension.
Features
When you process a new dimension, its properties are saved in the database.
When you process an existing dimension, any changes you made to it are saved in the database.
You can schedule the processing of dimensions with a Data Manager package.
For information on scheduling the processing of dimension members, see the SAP BusinessObjects EPM solutions, add-in for Microsoft Office help.
Activities
You can process dimensions in the Administration screen by choosing
PUBLIC
Dimensions
, selecting one or more dimensions, then
Page 10 of 102
choosing Process .
1.2.5 Dimension Member Management

Use
You manage dimension members by adding and modifying members within a particular dimension. You add members to dimensions based on your business
needs. For example, if your company opens a new office, the financial information of that office must be part of the Entity, Category, and Currency dimensions.
Features
A dimension contains a set of predefined properties based on its type. You can add new properties by choosing Edit Structure , if desired.
You can assign dimension formulas that calculate and store information based on member values.
Adding members to dimensions
You can add members to dimensions within an environment in the Administration screen by choosing
dimension, then choosing Edit Members .
Dimensions
, selecting a
The maximum length for a member name is 32 characters. However, this limit only applies to newly created dimensions. For dimensions that were migrated from
Business Planning and Consolidation version 7.5, the previous limit of 20 characters remains for member names.
Note
If you make changes to any rules in the dimension, such as adding a new formula, you must validate and save those rules, and process the dimension.
You can also add members to dimensions in bulk using packages and process chains within Data Manager. For more information, see the SAP
BusinessObjects EPM solutions, add-in for Microsoft Office help.
Caution
You cannot rename dimension member IDs.
1.2.6 Assignment of Dimensions to Models

Use
You assign dimensions to models to make the data in those dimensions available in your model. Each model must have at least one dimension of the required
types: Account (A), Category (C), Entity (E), and Time (T). Additional dimensions may be required depending on the type of model.
Note
Use caution when adding dimensions from a model that already contains data. Assign dimensions only to new models that do not contain data. If you do add a
dimension to a model with data, the system finds the first base member alphabetically, and loads it into the Fact tables, therefore writing all of the data from
the model to that member.
Activities
To assign a dimension to a model, you modify the model as follows:
Select the model and choose Edit .
Choose Add / Remove .
Select one or more available dimensions, then choose Add , then OK .
To remove a dimension from a model, you modify the model as follows:
Select the model and choose Edit .
Choose Add / Remove .
Select one or more selected dimensions, then choose Remove , then OK .
More Information
Model Management
1.2.7 Custom Measure Formulas

Use
You use the UJA_MAINTAIN_MEASURE_FORMULA program to create and maintain custom measure formulas.
Restrictions on Maintaining Measures
Measures delivered with Planning and Consolidation cannot be deleted.
The measures PERIODIC on a Periodic cube and YTD on a YTD cube that are delivered with Planning and Consolidation cannot be changed. Other
delivered measures can be changed at your own risk.
PUBLIC
Page 11 of 102
Note
Changes made to measures delivered with Planning and Consolidation are overwritten when you make any changes to that model from the
Administration screen. We recommend that you create custom measures instead of changing the delivered measures.
Formula names cannot be duplicated.
Formula names must be entered in uppercase letters.
Parent nodes of a hierarchy cannot be used in measure formulas.
Hints for Maintaining the Formulas
Use the same formula name as you defined in the Formula Name field when you give the measure name in [MEASURES].[<measure name>].
If your formula has to refer to another measure, enter the other formula statement and new formula together in the formula statement section. For example,
refer to the formula statement of Periodic and QTD measure on model with a YTD storage type.
If you want to use a property of dimension within Measure Formula, you must include the NetWeaver Business Warehouse Technical name. You can find
this name using transaction MDXTEST, for example. In this transaction, choose InfoProvider as the catalog and then choose your model (cube). The system
displays the list of dimensions. Expand the dimension and then its properties to view the property list.
[%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/GJPDBWP ") is a syntax for using the TIMEID property of the TIME dimension.
Creating a Custom Measure Formula
1. Go to Transaction SE38 in the ABAP layer and enter UJA_MAINTAIN_MEASURE_FORMULA as the program name.
2.
3.
4.
5.
Click the Debugging button.

In the Maintain Measure Formula screen, enter the model set ID, model ID, and user ID. You must have write access to the core model to save a formula.
Click the Enter button on the System Function Bar .
In the Maintain Measure Formula screen, do any of the following:
To create a measure:
1. Click the new item button.
2. Enter a measure formula name, description, and formula.
To display a measure formula, double-click it.
To display an existing measure, place the cursor on the measure you want to display and click the Display button.
To change an existing measure, place the cursor on the measure you want to change and click the Change button.
To delete a measure, place the cursor on the measure you want to delete and click the Delete button.
Sample - YTD on YTD Model

MEMBER [MEASURES].[YTD] AS 'IIF(([%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="INC" OR
[%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="LEQ"),-([MEASURES].[/CPMB/SDATA],
CLOSINGPERIOD([%TIME%].[LEVEL02])), ([MEASURES].[/CPMB/SDATA], CLOSINGPERIOD([%TIME%].[LEVEL02])))' SOLVE_ORDER=3
Sample - PERIODIC on YTD Model
CLOSINGPERIOD([%TIME%].[LEVEL02])), ([MEASURES].[/CPMB/SDATA], CLOSINGPERIOD([%TIME%].[LEVEL02])))' SOLVE_ORDER=3##
AS 'IIF(([%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="INC" OR
[%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="EXP") AND NOT
([%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="TOTAL" OR
[%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="Q1" OR [%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="JAN"
), [MEASURES].[YTD]-([MEASURES].[YTD],[%TIME%].LAG(1)), [MEASURES].[YTD])' SOLVE_ORDER=3
Sample - QTD on YTD Model
CLOSINGPERIOD([%TIME%].[LEVEL02])), ([MEASURES].[/CPMB/SDATA], CLOSINGPERIOD([%TIME%].[LEVEL02])))' SOLVE_ORDER=3
AS 'IIF(([%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="INC" OR
[%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="EXP") AND NOT
([%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="TOTAL" OR
[%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="Q1" OR [%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/PERIOD")="JAN"
), [MEASURES].[YTD]-([MEASURES].[YTD],[%TIME%].LAG(1)), [MEASURES].[YTD])' SOLVE_ORDER=3
MEMBER [MEASURES].[QTD] AS 'IIF(([%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="INC" OR
[%P_ACCT%].CURRENTMEMBER.PROPERTIES("2/CPMB/ACCTYPE")="EXP"),IIF([%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/TILEVEL"
)="QUARTER",[MEASURES].[PERIODIC],IIF([%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/TILEVEL")="MONTH" OR
[%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/TILEVEL")="WEEK" OR
[%TIME%].CURRENTMEMBER.PROPERTIES("2/CPMB/TILEVEL")="DAY",SUM(PERIODSTODATE([%TIME%].CURRENTMEMBER.PARENT.LEVEL,
[%TIME%].CURRENTMEMBER),[MEASURES].[PERIODIC]),NULL)),[MEASURES].[YTD])' SOLVE_ORDER = 3
1.2.8 Dimension Properties

Use
By assigning properties to dimensions, you can implement powerful features in your reporting, member lookup, formulas, and Data Manager selections. You can
filter on properties in many places in the system. For example, if you want to be able to easily select entities by geographic region, you simply add a REGION
property, and enter a region value for each entity. Then you can filter and sort by region, apply account logic by region, or define a report format based on region.
The system requires various properties depending on the dimension. You can also assign additional properties for your business needs.
Many of the properties are generic, such as ID and DESCRIPTION, while others can be unique to a dimension, such as SCALING. The properties define the
behavior of members within the dimension.
Features
PUBLIC
Page 12 of 102
You can use the following features when working with dimensions:
Task
More Information
Adding properties to dimensions
You can add properties to a dimension by selecting a dimension within the dimension
library and clicking Add in the toolbar above the property list.
When you add a property to a dimension, you must specify the following:
ID - An ID for the property. The ID is not case sensitive but is displayed in the
case it is typed. The ID must be unique (regardless of case) within a dimension.
The maximum length of an ID is 20 characters. The permitted characters are: AZ,a-z,0-9,_,-,. An ID cannot contain the following invalid characters: single
quotation mark ('), double quotation mark ("), backslash (\), ampersand (&), dash
(-) The ID cannot start with a number as a first character. The ID cannot be the
same ID as that of a system-generated property. The ID cannot contain the string
of characters "PARENTH". The ID cannot be the same ID as one of the special
properties described below.
Name - A name for the property. The maximum length for a property name is 40
characters.
Number of Characters - The maximum length for values of the property. This
must be an integer greater than zero.
Adding properties to dimensions in Consolidation,Ownership, and Rates models
When you add a property to a dimension in a consolidation, ownership, or rates model,

you have the option to add the set of predefined properties for the following dimension
types:
Account
Category
Audit
Entity
Time
Currency
When you add properties to any of these dimension types, you can select to add a new
property or add the set of required properties for consolidation type models. For the
Account dimension, you can also add the set of required properties for ownership type
models.
When you add the set of predefined properties required for consolidation, ownership, or
rates models, if there is already a property with the same ID as one of the required
properties, the system handles this as follows:
The corresponding property is not added to the dimension.
If the number of characters of the existing property is greater than expected, the
system does not change it.
If the number of characters is smaller, it is updated with the default value specified
for this property in the set of predefined properties
A message is displayed at the end of the process to inform you if the system did not add
some of the properties because they already exist, and if the system changed the
number of characters.
Modifying dimension properties
You can modify a property which is not a system-generated property. You edit and change
a property directly in the property list. You cannot change a property ID after you have
saved it. However, you can change a property name and the number of characters, but
you cannot reduce the length previously specified.
Adding property values
After you add a property to a dimension, you can assign property values to members in
the dimension. You can add property values to properties by selecting the desired
dimension from the dimension library, selecting Edit Members , then adding the
desired values directly in the member grid under the appropriate property. After you are
done, you must save the changes and process the dimension.
Removing dimension properties
You can remove properties from a dimension by selecting a dimension within the
dimension library and clicking Remove in the toolbar above the property list. This
removes the property from the list. You cannot delete a system-generated property.
Limiting the number of dimension members available to users
When a user is filling a journal template, all base-level members that this user has
access to are available. You can use the "Enable journal" function to limit the number of
dimension members that are available to the users during journal entry. You can limit
journal dimension member lists by adding the property EnableJRN to each dimension
for which you want to limit the journal access. After that, in its dimension sheet, enter Y
in the EnableJRN column of the base-level members for which you want to allow users
to post journal entries. Do this for each dimension you want to limit, then process the
dimensions.
System-generated Properties
The following properties are generated for all dimension types, but are not displayed in the list of properties for a dimension.
Property
Description
DESCRIPTION
Display name of the dimension. This appears in the language specified in the
Preferences settings.
CALC
Indicates whether the member is calculated by means of a formula or is at a parent level.

The property values can be viewed in the Member Selector in the EPM add-in.
HIR
Stores the hierarchy IDs associated with the member, for example H1;H2.
Special Properties
PUBLIC
Page 13 of 102
The following are reserved IDs that you cannot enter as a property ID when adding a new user-defined dimension property:
Property
Description
SOLVE_ORDER
The SOLVE_ORDER property defines the order in which the system solves calculated
members when they intersect with other calculated members. SOLVE_ORDER
determines the order in which the system evaluates and calculates dimensions,
members, calculated members, custom rollups, and calculated cells. The system
evaluates the member with the highest solve order first, and calculates it last. Zero is the
highest priority.
Guidelines for implementing SOLVE_ORDER:
Specify up to 3 measures and 5 members within a SOLVE_ORDER property.
Specify dimensions by dimension name, making sure that capitalization is
correct.
Example
[ACCOUNT].[Account1] / [ACCOUNT].[Account2]
[PRODUCT].[Product1] + [PRODUCT].[Product2]
The only exception to this rule is that you do not need to specify an Account
dimension by name.
FORMULA
The optional property FORMULA allows you to define calculations to perform for
dimensions. This powerful feature of the system gives you the ability to customize data
management to meet your business requirements.
Select the Enable Member Formulas option for the dimension to which you want to
apply member formulas. For information about implementing formulas, see Member
Formulas.
More Information
Dimension Processing

Use
The owner designating dimension property is created in any dimension used as a driving dimension for a business process flow. You add the property to the
dimension with any name. We recommend using a naming convention that denotes the relationship to business process flow owners. A dimension can have one
or more owner designating properties as long as each is unique.
For example, if your business process dictates that an entity is the differing factor when it comes to entering data, the Entity-type dimension is the dimension that
drives the owner of the activity context. If your business process dictates that a department name is the differing factor, the Department dimension would have a
unique owner designating property that drives the owner of the activity context. The "Owner" property used for work status is a reserved property. The business
process flow owner properties must be named with a unique name.
Prerequisites
The dimension you select to drive must have at least an owner type dimension property. When more than one exists, you choose the appropriate property to use
in the business process flow.
Features
The owner designating property takes user and team names in brackets as values. You can enter multiple names and teams separated by commas. You must
also include the domain or server name in the path.
Activities
You do the following to set up an Owner property:
Set up the owner property by accessing the Dimension Library, choosing Maintain Dimension Property , and adding an owner.
Assign the owner property to a dimension by accessing Maintain Dimension Members . Define the owner property on a dimension such as Entity, then
define the property values. You can enter multiple names and teams separated by commas. You must also include the domain or server name in the path.
1.2.8.2 Reviewer Property

Use
The Reviewer property is a special property used to identify the person or team that must review an activity performed by another user in a business process
flow. This person or team member can approve or reject the action taken by the user. A reviewer can also reopen the previous step of a business process flow.
The Reviewer property must be defined prior to creating a BPF template, as the administrator is required to enter it during the setup of a business process flow
template.
Features
PUBLIC
Page 14 of 102
When defining the property, the following rules apply:

The reviewer designating property can be set up on any dimension and can be any name, such as BPF1_Reviewer. A dimension can have one or more
uniquely named properties.
You typically select a reviewer designating property when setting a drive dimension and owner property.
When defining the property values, the following rules apply:
The value can be a user ID or a team, or a combination of both.
If defining multiple property values, you must separate each entry by a comma.
A team name must be enclosed in brackets, as in [TEAM].
The reviewer property is case sensitive.
The limit is 255 characters.
A reviewer can reopen the previous step of a business process flow. The step must be defined to allow reopen.
Activities
To define a reviewer property, open the dimension that you want to designate as the driver dimension of the business process flow, then add a Reviewer property
and its property values. For more information, see Dimension Properties.
When creating a business process flow, choose Enable Reviewers , then set a Reviewer property when defining the step region criteria for a new step.
More Information
Creating Processes
1.2.8.3 Account Dimension Properties

Use
The account dimension defines the chart of accounts for your model and how those accounts are calculated and aggregated. Any dimension that is assigned the
type A is considered an account dimension. Each model can have only one account-type dimension.
Features
An account dimension has the following system-generated properties:
Property Name
Description
ACCTYPE
Account type. Can be INC for Income, EXP for Expense, AST for Asset, LEQ for Liabilities
and Equity.
The account type cannot be blank.
RATETYPE
Used by the currency conversion business rules. Value is optional.
SCALING
Scaling options are Y or N. Used by EvDRE, EPMScaleData, and Library view. Value is
optional, but if a value is not defined, scaling is unavailable for the associated member
ID.
The following property is required only if the account dimension is used in a consolidation model.
Property Name
Description
TYPELIM
Specifies that Automatic Adjustments details are created based on a generic value, rather
than mentioning the member itself. Allows you to apply the same processing to several
accounts having the same property value.
The following property is required only if the account dimension is used in an ownership model.
Property Name
Description
IS_INPUT
Flag for ownership accounts to be used in Method-based multipliers.
More Information
1.2.8.4 Category Dimension Properties

Use
The category dimension defines the groupings in which you store information in your model. Typical categories are Budget, Actual, and Forecast. Any dimension
that is assigned the type C is a category dimension. Each model can have only one category-type dimension.
Features
PUBLIC
Page 15 of 102
A category dimension has the following required properties:

Property Name
Description
YEAR
Used to assign a YEAR to the category, to be used with the EPMRetrieveData and
EPMMemberOffset functions in reporting. For more information, see the SAP
BusinessObjects EPM solutions, add-in for Microsoft Office help.
The following properties are required only if the category dimension is used in a consolidation model.
Property Name
Description
CATEGORY_FOR_OPE
Category of source data to use when performing carry forward (CopyOpening).
FX_DIFFERENCE_ONLY
Specifies whether the translation result is calculated normally (blank or N ) or if only the
translation difference with the source category is computed ( Y ).
FX_SOURCE_CATEGORY
Category of source data to be used when running currency translation on a simulation

category.
OPENING_PERIOD
Period number of source data to use when performing carry forward (CopyOpening).
This can be absolute (for example, 12 for December) or relative (for example, -1 for prior
period).
OPENING_YEAR
Year offset of source data to use when running carry forward (CopyOpening). This is
relative (for example, -1 for prior period).
OWN_CATEGORY
Category of source ownership data to be used when running consolidation on a

simulation category
OWN_YEAR
Period number of source ownership data to be used when running consolidation on a

simulation category. This can be absolute (for example, 12 for December) or relative (for
example, -1 for prior period).
OWN_PERIOD
Year offset of source ownership data to be used when running consolidation on a

simulation category. This is relative (for example, -1 for prior year).
RATE_CATEGORY
Category of source exchange rate data to use when running currency translation on a
simulation category
RATE_PERIOD
Period number of source exchange rate data to use when running currency translation
on a simulation category. This can be absolute (for example, 12 for December) or relative
(for example, -1 for prior period).
RATE_YEAR
Year offset of source exchange rate data to be used when running currency translation on
a simulation category. This is relative (for example, -1 for prior year).
STARTMNTH
Starting month.
More Information
1.2.8.5 Currency Dimension Properties

Use
The Currency dimension is required if your company reports on local currency and translated values. These dimensions store the reporting and input currencies
for your organization. Any dimension that is assigned the type R is a currency-type dimension.
Features
The following table describes the required properties of a currency dimension. If you are utilizing the legal consolidation functionality of Planning and Consolidation,
the currency-type dimension requires additional properties.
Property Name
Description
ENTITY
A 32-character field that can either be left blank or contain a valid member name of the
entity dimension associated to the current model. The ENTITY property is validated
against the entity dimension, and blank fields are allowed.
REPORTING
Specify your reporting currencies. If Y, this member is used for reporting purposes.
The following property is required only if the currency dimension is used in a consolidation model.
Property Name
Description
CURRENCY_TYPE
Identifies the local currency member (L) versus reporting currency members (R) or
transaction currency member (T).
The following property is required only if the currency dimension is used in a rate model.
Property Name
Description
PUBLIC
Page 16 of 102
Defines whether the currency exchange rate for that currency is used to multiply or divide
MD
with the local amount.
More Information
1.2.8.6 Entity Dimension Properties

Use
The entity dimension defines the organizational structure of the business units for your model and how the units aggregate. Any dimension that is assigned the type
E is an entity dimension. Each model can have only one entity-type dimension.
Features
An entity dimension has the following required properties:
Property Name
Description
CURRENCY
The currency used by the entity.
CTRL_CURRENCY_NOT_LC
Specifies the Reporting Currency dimension member against which a data control is
performed. A control is an individual check for data accuracy and consistency. Controls
are enabled or disabled at the model level.
The following are valid values:
Y - The generic LC (local currency) member is used.
N - The entity currency property is used, for example, EUR. This can be used
when loading pre-translated data from a source system where currency translation
has already been performed.
If no value is set, the default value is Y .
For more information, see Controls.
CONTROL_LEVEL
Specifies the controls that are relevant to an entity when a control set (a group of controls)
is executed.
The following are valid values:
Level 1 - Basic controls
Level 2 - Standard controls
Level 3 - Advanced controls
Level 4 - Comprehensive controls
If 4 is selected, all controls having a level from 1 to 4 are executed. If blank or 0, no
control is applicable.
For more information, see Controls.
The following properties are required only if the entity dimension is used in a consolidation model.
Property Name
Description
ELIM
Defines whether the entity is used to store the intercompany elimination for a given node
in the hierarchy. Valid values are Y or N .
FX_TYPE
Defines the subset of Currency Conversion rules to apply to the entity, where FX_TYPE
matches the Entity FX Type property of the rules.
INTCO
Defines the corresponding intercompany member for an entity.
More Information
1.2.8.7 Group Dimension Properties

Use
The group-type dimension represents the relationship of entities for a given consolidation result. This group is consolidated in a single currency, so there is no
need to have another dimension. You can continue to use the currency-type dimension for this purpose or you can split it into a group-type dimension (type G) and
use a pure currency-type dimension (type R) to allow reporting in multiple group currencies.
Note
A group dimension must be assigned to an ownership and a consolidation model. You should assign both a currency and a group dimension to a consolidation
model but you should assign only the group dimension to the ownership model referred from the consolidation model. You cannot assign both a currency and a
group dimension to the same ownership model.
Property Name
Description
CONSO_TYPE
Specifies which set of rules to apply to a group. Refers to group type filter in Adjustments
PUBLIC
Page 17 of 102
CONSO_TYPE
and Eliminations.
CURRENCY_TYPE
Used for the currency conversion.

N - Non-group
G - Group
DATASRC_LEVEL
Stores the consolidation differences resulting from different % or methods along the
group hierarchy
ENTITY
Blank or a valid entity ID. This is used to define the link between the Group and the
Entity or to indicate the Entity where the aggregation should be stored.
If this property is filled with a valid entity ID, and the property STORE_ENTITY is set to
Y, the results of the currency conversion for the current Group are also copied into this
Entity. (Length = 20)
GROUP_CURRENCY
This can be any valid reporting currency, and is used for currency conversion.
This property can only be used on Currency members with the property
CURRENCY_TYPE of G and, in this case, it must contain a valid ID from the Currency
dimension with the property CURRENCY_TYPE value of R. (Length = 20)
PARENT_GROUP
Must be a valid ID from the Groups dimension. If you want to do the consolidation by
level, you must indicate here the higher level from the group. If you want to use this
property to define the hierarchy, enter the same code as the ID for your top group. If this
property is blank, the dynamic hierarchy from the ownership application is used. (Length
= 20)
STAGE_ONLY
STORE_ENTITY
Specifies whether to store the ID entered in the Entity property.

Y - If you want to store the ID entered in the Entity property.
Blank - If you do not want to store the ID entered in the Entity property.
STORE_GROUP_CURR
Used for currency conversion.

Y - By default the results of the conversion into a Group currency are written in both the
Group member and in the Currency member of the currency dimension.
N (or blank) - If only the Group member is to be stored, set this property to N . (Length
= 1)
More Information
1.2.8.8 Intercompany Dimension Properties

Use
The Intercompany dimension defines the base members associated with the level at which Intercompany balances are tracked for Intercompany eliminations.
Features
An Intercompany dimension has the following required properties:
Property Name
Description
ENTITY
A 32-character field that can be left blank or contain a valid member name of the entity
dimension associated to the current model. The ENTITY property is validated against the
entity dimension, and blank fields are allowed.
SCALING
Scaling options are Y or N. Used by EvDRE and Library view. The property is optional,
but if a value is not defined, scaling is unavailable for the associated member ID.
More Information
1.2.8.9 Time Dimension Properties

Use
The time dimension defines the units of time for your model and how those units aggregate. Any dimension that is assigned the type T is a time dimension. Each
model can have only one time dimension.
Features
A time dimension has the following required properties:
Property Name
Description
PUBLIC
Page 18 of 102
BASE_PERIOD
A system-generated property, used by the query engine for calculations and by the
Consolidation process.
LEVEL
Time can be a year, quarter, month, week, or day. The LEVEL property is important in
defining your time periods. You must have the correct level for each member. You must
follow the chronological format throughout the time dimension. The correct format is the
following:
YEAR
QUARTER
MONTH
WEEK
DAY
PERIOD
The PERIOD property allows you to filter, sort, and report based on the period.
YEAR
The YEAR property allows you to filter, sort, and report based on the year. You should
place the YEAR properties in chronological order in the file, in order for the
EPMMemberOffset function to give offsets correctly.
The following property is required only if the time dimension is used in a consolidation model:
Property Name
Description
MONTHNUM
Provides a sorting order to leaf members of the time dimension within a year
TIMEID
Numeric ID to used for identifying the time member, for example, 20120100 for
2012.JAN .
More Information
1.2.8.10 User-Defined Dimension Properties

Use
A user-defined dimension is any dimension that is not one of the standard system dimensions.
Features
A user-defined dimension has the following required properties:
Property Name
Description
SCALING
Scaling options are Y or N. Used by EvDRE, EPMScaleData, and Library view. The
property is optional, but if a value is not defined, scaling is unavailable for the associated
member ID.
More Information
1.2.8.11 Audit Dimension Properties

Use
The audit dimension is user-defined and tracks the source of input data.
Features
An audit dimension has the following required properties:
Property Name
Description
SCALING
Scaling options are Y or N. Used by EvDRE, EPMScaleData, and Library view. This
property is optional, but if a value is not defined, scaling is unavailable for the associated
member ID.
The following properties are required only if the audit dimension is used in a consolidation model.
Property Name
Description
DATASRC_TYPE
Specifies whether a data source is used for Input ( I ), Manual Adjustments ( M ) or

Automatic Adjustments Eliminations ( A ).
IS_CONSOL
Specifies whether data is consolidated or not. Typically this is set to yes ( Y ), but set it
no ( N ) for data sources used in group-specific adjustments (for example, post
PUBLIC
Page 19 of 102
no ( N ) for data sources used in group-specific adjustments (for example, post

consolidation adjustments entered against a specific group).
IS_CONVERTED
Specifies whether data is translated or not. Typically this is set to yes ( Y ), but set it to
no ( N ) for data sources used in currency-specific adjustments (for example,
adjustments in EUR, USD, and so on).
DATASRC_STAGE
Defines to which Audit member consolidation adjustments from lower groups are
inherited in higher groups (Parent groups).
DIMLIST
Property used to create a grouping of data sources which can later be used as filters in
Automatic Adjustments and Eliminations business rules.
COPYOPENING
Flag used to filter data sources when running carry forward (CopyOpening).
OPENING_DATASRC
Specifies a different destination data source, to which the corresponding amounts are
carried forward. For example, this can be used where certain entries are posted to a data
source that specifically identifies these adjustments as audit adjustments in the current
year, but in future years it might be required to simply include in another standard data
source (that is, Input).
More Information
1.2.8.12 Subtable Dimension Properties

Use
Subtable dimensions break down account activity or flow. For example, some accounts, like Fixed Assets, have a subtable dimension containing Opening,
Additions, Deletions, Transfers, and Ending Balances. The subtable type dimension is important for writing business rules that require currency translation
amounts to be calculated by account. Since the subtable information can be used for multiple accounts, it requires its own dimension.
Features
A subtable dimension has the following required properties:
Property Name
Description
FLOW_TYPE
Defines the type of flow of the dimension, as follows:

OPENING - Opening
TRANSLOPE - Change difference on opening
ALLOCINC - Allocation
MERGER - Merger
INCOME - Net income from the period
CHANGE - Variation
TRANSFER - Transfer
TRANSFLOW - Translation change on flow
VARSCP - Variation in scope (generic)
VARSCPMETH - Variation in scope method
VARSCPPERC - Variation in scope percentage
VARSCPNEW - Variation in scope new company
VARSCPLEAV - Variation in scope sold company
CLOSING - Closing
NONE - No flow
Blank - All other flows
SCALING
Scaling options are Y or N. Used by EvDRE, EPMScaleData, and Library view. The
value is optional, but if a value is not defined, scaling is unavailable for the associated
member ID.
More Information
1.3 Model Management

Use
A model is a representation of the relationships, calculations, and data of an organization or business segment.
Models can be categorized as 'reporting' models and 'drivers and rates' models. Reporting models are used for user input and analysis. Drivers and rates models
store reference data such as currency rates and ownership data. For information about each, see Reporting Models and Drivers and Rates Models.
Features
You can use the following features when managing models:
Creating Models
PUBLIC
Page 20 of 102
When you create a model in the Planning and Consolidation Administration screen, you provide a name and description, select the type of model and its options
and settings, indicate whether you want to start from a blank model or an existing model, and select the dimensions to include in the model.
The setting Non Interco Member in Ownership is used to indicate a non-intercompany member within the ownership model.
The setting Parent/child property used for hierarchy of Groups is used with dynamic hierarchy statutory applications when defining fixed hierarchies. The value
must match the value in the ParentProperty property value of entities in the statutory application's supporting ownership application.
During the model creation process, items such as model publications, private publications, Documents view, reports, team tasks, and Data Manager packages
may be copied from a source model. You can use the Use as Source of Data for External Applications checkbox to make data within the model available for
evaluation through Process Control.
Once a model has been created, you can view features of Planning and Consolidation that are being used for the model, including whether work status, data
auditing, and journal template are on or off. You can also enable comments and use the model as a source of data for external applications.
Copying Models
You can copy an existing model as a quick way of creating a new model. The system copies the dimensions, data, and templates from the source model to the
new model. You can modify the model later. When you copy a model in the Planning and Consolidation Administration screen, you select a source model, then
provide a name and a description of the new model.
Setting up Work Status Settings for Models
Managing work status involves specifying who can make changes to your data and who can change the work state on a data set. You create work states to reflect
the status of data as it moves through your business processes. See Work Status Setup and Setup of Data Locking Settings.
Adding Business Rules to Models
You can add business rules to a model in the Business Rules domain of the Administration screen. You activate the rule types you need for the model, if not
already activated, and then add the new business rules of each type to the model. For more information, see Business Rules Management.
Setting up Legal Consolidation Models
In order for a legal consolidation model to function properly, it must contain the four required ENTITY, CATEGORY, TIME, and ACCOUNT dimensions (but can be
named as desired). The remaining dimensions have the following rules:
The CURRENCY/ GROUP dimension is required for the consolidation and/or currency business rules
The INTCO dimension used for matching intercompany activity
The DATASRC dimension is required for elimination and/or consolidation business rules
The SUBTABLE (flow) dimension is optional, and based on your requirements
Setting up Drill-through
You can set up drill-throughs to view the source data that make up the content of a selected cell in an Excel report (see Drill-Through Setup).
Optimizing Models
When you create new environments and models, only a small amount of data exists. Since the amount of data you maintain grows over time, we recommend you
periodically run the optimize function to improve performance. See the Planning and Consolidation Operations Guide for instructions.
YTD Storage Models
Since most general ledger and other source systems store balances on a periodic basis, default data storage for models is based on periodic time intervals. With
this method, all calculations are on periodic balances. The balances are then accumulated for year-to-date reporting. In some business cases, calculations should
occur on a year-to-date basis, like in a model with foreign currency translation. If a year-to-date basis is required, you can set your reporting models when you
create them to store data on a year-to-date basis, so they accept data entry in the YTD format. When data is entered into YTD, its periodic values, used for
reporting purposes, are derived by calculating the difference between the current period and the last period, as in the following example.
Example
This example depicts INC or EXP accounts. There is no change in behavior for AST or LEQ accounts.
January
February
March
Periodic
100
200
YTD
100
300
300
Both periodic and year-to-date storage methods support daily, weekly, monthly, quarterly and year-to-date reporting requirements.
You create a YTD storage model by specifying YTD - Year To Date for the data entry mode when defining the type of model you are creating.
Deleting Models
Administrators can delete models when necessary.
Caution
You can delete a model when it contains data. You cannot, however, delete a dimension member when there is data associated to that member in the model.
More Information
Dimension Types
1.3.1 Reporting Models

Use
Reporting models hold financial data.
PUBLIC
Page 21 of 102
Features
The following table describes the different types of reporting models and lists the required dimensions for each:
Type of Reporting Model
Description
Required Dimensions
Financial
Financial models perform management and legal

consolidation functions. They support data translations
Account (A)
Category (C)
from local currencies to one or more reporting currencies,

intercompany elimination calculations, and other
calculations.
Entity (E)
Time (T)
Currency (R)
When you create a financial model, you must choose an

associated rate model (see Drivers and Rates Models).
You can also choose to set up the following business
rules:
Currency conversion
Account transformation
Intercompany bookings
US eliminations
Carry-forward rules
Validations
Consolidation
Consolidation models perform more complicated legal

consolidation functions than Financial models.
Account (A)
Category (C)
Consolidation can incorporate complex organizational

structures involving full ownership, partial ownership,
minority ownership and consolidation methods.
Entity (E)
Time (T)
Audit (D)
Consolidation models must reference an ownership

model and a rate model (see Drivers and Rates Models).
You can also choose to set up the following business
Group (G)
Intercompany (I)
Subtables (S)
rules:
Currency (R)
Currency conversion
Account transformation
US eliminations
Carry-forward rules
Validations
Automatic adjustments
Standard
Standard reporting models have no special requirements

other than the four required dimensions. Generic models
Account (A)
Category (C)
have no default business intelligence. Therefore, to apply

logic, create it using logic scripts.
Entity (E)
Time (T)
1.3.2 Drivers and Rates Models

Use
Use this function to become familiar with the types of non-reporting models available in Planning and Consolidation.
Features
Drivers and rates models support reporting models by holding data such as currency exchange rates and ownership percentages. You can report on drivers and
rates model data. You cannot define business rules to these model types. The following table describes the different types of drivers and rates models and lists
the required dimensions for each:
Type of Drivers and Rates Model
Description
Required Dimensions
Rate
A rate model is a supporting model for financial and

consolidation reporting models. It is used to store
Account (A)
Category (C)
exchange rates that support currency conversion in

financial models.
The time dimension must be identical to the dimension
Entity (E)
Time (T)
Currency (R)
used by the models using the rate model to store their

foreign currency exchange rates and must have the same
category member IDs.
This model must include a currency dimension detailing
the exchange rates by each input currency. The currency
dimension in a rate model does not need to have the
REPORTING property.
Ownership
The ownership model is a supporting model for a
Account (A)
consolidation reporting model. It stores information such

as the consolidation methods, ownership percentages,
and group roll up information used for legal consolidation.
Category (C)
Entity (E)
Time (T)
Intercompany (I)
Group (G)
Generic
A generic model has no special requirements other than

the four required dimensions. Generic models have no
PUBLIC
Account (A)
Category (C)
Page 22 of 102
default business intelligence. Therefore, to apply logic,
Entity (E)
create it using script logic.
Time (T)
1.3.3 Large Key Figure Usage

By default Planning and Consolidation supports numbers with up to 13 digits before a decimal point and 7 digits after a decimal point. You can use larger
numbers by enabling functionality that allows large key figures, which are numbers with up to 24 digits before the decimal point and 7 digits after it. To use large
key figures you must first activate the functionality in the SAP Reference IMG, and then enable it in the model.
Related Information
Activate Large Key Figure Support in the SAP Reference IMG
Modify Existing Models for Large Key Figure Usage
Create New Models that Use Large Key Figures
1.3.3.1 Activate Large Key Figure Support in the SAP Reference

IMG
Perform this task to activate the use of large key figures within the system. You must also modify existing models in order to use this functionality and follow
specific steps when creating new models.
Prerequisites
To use this feature, you must have the following software installed:
Planning and Consolidation for the NetWeaver platform 10.0 SP10 or later
EPM solutions, add-in for Microsoft Office 10.0 SP14 or later
Procedure
1.
2.
3.
4.
Run transaction SPRO.

Choose SAP Reference IMG .
Choose
Planning and Consolidation
Configuration Parameters
Set Global Parameters
Enter a new flag with name ENABLE_LARGE_KEY_FIGURE and set its value to X.
5. Save your changes.
1.3.3.2 Modify Existing Models for Large Key Figure Usage

To use large key figures in the system, you must modify existing models.
Procedure
1.
2.
3.
4.
5.
In the Administration client, choose Models .

Select the model that you want to modify and choose Edit .
In the modification screen choose Change Type . The update wizard starts.
In the Key Figure Length option, select Large .
Finish the wizard and save your changes.
1.3.3.3 Create New Models that Use Large Key Figures

To use large key figures in the system, follow these steps when creating new models.
Procedure
1.
2.
3.
4.
In the Administration client, choose Models .

Start the model creation wizard.
In the Key Figure Length option, select Large .
Finish the wizard to create the new model.
1.3.4 Stabilizing Cube Names

Use this function to keep the technical name of a cube unchanged after model modification, optimization, or transport.
To keep the technical name of a cube unchanged after model modification, optimization, or transport, you can use the parameter ENABLE_FIXED_CUBENAME
with X as its value.
Modifying a model
When the parameter ENABLE_FIXED_CUBENAME is NOT set to X in the source and target system, the current system behavior remains unchanged.
When the parameter ENABLE_FIXED_CUBENAME is set to X, then:
PUBLIC
Page 23 of 102
If the model has no transaction data, the technical name remains unchanged after modifying the model structure.
If the model has transaction data, an error message appears to indicate that modifying the model in cube name stabilization mode is not possible. You must
to back up and clear the transaction data in the cube and modify it again.
Optimizing a model
When the parameter ENABLE_FIXED_CUBENAME is set to X, then:
A full optimization is automatically switched to light optimize mode and the technical name of the model does not change after the optimization.
If you run a light optimize, there is no change to the current system behavior.
Transporting a model
When the parameter ENABLE_FIXED_CUBENAME is set to X in both the source and target system, the resulting behavior depends on several factors as shown in
this table:
Table 1: Effects of ENABLE_FIXED_CUBENAME when transporting a model
Cube technical name
Cube technical name
Cube technical name
Cube technical name
Source system
Target system
A (with transaction data)
A (without transaction data)
B (with transaction data)
B (without transaction data)
Behavior and result
The import is rejected. An error

appears in the log to indicate the
The target model is overwritten by In the target system:

the source model.
1. Create a cube named A.
failure and to guide you on how to

proceed.
2. Copy the transaction data

from B to A.
3. Delete the cube named B.
In the target system:

1. Create a cube named A.
2. Delete the cube named B.
When the parameter ENABLE_FIXED_CUBENAME has different values in the source and in the target system, the model import is not performed and an error
message appears in the transport log.
1.4 Legal Consolidation

Use
This section focuses on the dimension properties and relevant settings required for the various tasks that are required to successfully perform legal consolidation
using SAP BusinessObjects Planning and Consolidation. The following tasks are described:
How to set up currency translations, intercompany eliminations, copy opening tasks, and other business rules using the business rules tables and script
logic in Planning and Consolidation Administration
How to set up the Data Manager package required to run the legal consolidation tasks in SAP BusinessObjects EPM solutions, add-in for Microsoft Office
Business rules provide the mathematical foundation for SAP BusinessObjects Planning and Consolidation models, allowing users to manage both management
and legal consolidation reporting. This section also discusses the configuration of business rules.
The finance department of a corporation uses legal consolidation to consolidate numbers from its subsidiaries and produce consolidated financial statements of this
group of legal entities at the end of a financial period.
Features
You can perform the following activities in Planning and Consolidation during the financial consolidation process:
Initialize opening balances at the start of a new reporting cycle
Enter amounts for each entity
Validate data
Match intercompany transactions (for example, AR/AP reconciliation)
Convert local currency data to the desired group reporting currencies
Generate all the consolidation entries for the desired groups of entities such as:
Ultimate ownership calculation
Elimination entries for intercompany revenue, investments, and profit in inventory
Adjusting entries
Reclassifications
Minority calculations and other calculations
Make the final validation
Generate the report
Activities
To enable users to generate consolidated financial statements, you should configure the legal model, and set up the legal and statutory consolidation business
rules, in order to perform the activities required in the generation of consolidated statements of a group of legal entities.
To set up your consolidation environment, you do the following:
Create the consolidation (legal) environment and set the necessary parameters (see Create an Environment)
Set up master data (dimensions) (see Master Data (Dimensions) Setup)
Create the model (see Create or Modify the Model) and set the model parameters (see Model Parameters if using the Microsoft platform of Planning and
Consolidation)
Enable business rules (see Business Rule Setting)
Update rate data and ownership data (see Execute Consolidation Task and Loading Data)
Set the work status
PUBLIC
Page 24 of 102
Set the journal template and validation criteria (see Journal Definition and Validation Setting)
1.4.1 Create an Environment

Use
Use this to set up an environment for legal consolidation.
Features
If you already have an existing environment (for example, for planning or reporting), you can use this environment to host your legal consolidation. Using the
environment for planning or reporting as a basis to build consolidations allows you to share the relevant dimensions (for example, account) with your consolidation
environment.
1.4.2 Dimension Setup in Dimension Library

Use
Set up dimensions for legal consolidation.
Features
For the consolidation model, the dimensions listed in the tables below are mandatory requirements. Therefore, it is recommended that you verify that all the
dimensions are available in the dimension library of your consolidation environment created from EnvironmentShell.
Note
Whereas the dimension names can be chosen as desired, it is mandatory that the dimension types match with the ones described below for the
corresponding models.
The MAIN legal consolidation model requires the following dimensions:
Dimension
Description
ACCOUNT
Members of this dimension are, for example, Revenue or Salaries.
CATEGORY
Contains the types of data you are going to track, such as Actual, Budget, and Forecast.
You can also set up categories to store versions, such as BudgetV1, and BudgetV2.
Audit
Used in the business rules of a reporting consolidation model to segregate input data.
Subtable (Flow)
Breaks down account activity or flow into subunits.
Entity
Contains the business units that are used to drive the business process.
Depending on your model design, the Entity type can be for example an operating unit, a
cost center, or a geographic entity.
Intco
Contains the intercompany codes for the entities.
Time
Contains the periods for which you store data.
Currency
The currency type dimension is required if the customer reports on local currency and
translated values.
Groups
The group represents the relationship of entities and consolidation scopes for a given
consolidation result.
The RATE model containing exchange rates requires the following dimensions:
Dimension
Description
ACCOUNT
Members of this dimension are used to detail the different types of rate (for example,
Average or End-of-period).
CATEGORY
You can also set up categories to store versions, such as BudgetV1, and BudgetV2.
Entity
This is used to store multiple tables of rates, if desired; otherwise, the R_Entity
dimension may just be limited to one dummy member, typically named GLOBAL.
Time
Contains the time periods for which you store data.
Currency
This dimension is used to store each applicable local currency.
Note
Time and Category dimensions must be shared by all the models involved in consolidation.
The OWNERSHIP model storing the ownership details requires the following dimensions:
Dimension
Description
PUBLIC
Page 25 of 102
ACCOUNT
Members of this dimension are for example METHOD (consolidation method),POWN

(ownership percentage), and PCON (control percentage).
CATEGORY
You can also set up categories to store versions, such as BudgetV1 and BudgetV2.
Entity
Contains the business units that are used to drive the business process. Depending on
your model design, the Entity type can be for example an operating unit, a cost center, or
a geographic entity.
Intco
Contains the intercompany codes for the entities.
Time
Contains the periods for which you store data.
Groups
The group represents the relationship of entities and consolidation scopes for a given
consolidation result.
The following table indicates the dimensions required in various models:

Name
Type
MAIN
Account (Consolidation)
OWNERSHIP
Account (Ownership)
Account (Rate)
Flow
Category
Entity
Entity (Rate)
Intercompany
Time
Group
InputCurrency
Audit
Currency
RATE
X
X
Activities
Create a new dimension
1. Select
Planning and Consolidation Administration
2. Click New .
3. Choose a unique ID, provide a description, and select the dimension type.
Dimensions
1.4.3 Create or Modify Dimension Properties

Use
When you create a new dimension, all the required properties are created automatically based on the dimension type. However, to ensure the correct operation of
consolidation and related processes (such as currency translation, simulation, and eliminations and adjustments), additional dimension properties are needed to
ensure the filtering, flagging, and calculation of the target data. You should ensure that these properties are maintained with the expected values for the
consolidation process according to the business requirements.
You manage consolidation-related properties for dimensions in Planning and Consolidation Administration by selecting
Dimensions .
Features
Account Dimensions
The Account dimension defines the chart of accounts for the model, and how these accounts are calculated and aggregated. Any dimension that is assigned the
type A is considered an Account dimension. Each model can have only one account-type dimension.
The following table details the account dimension properties:
Property Name
Length
Description of Property Values
ACCTYPE
This property can have the following values:

INC for income
EXP for expense
AST for asset
LEQ for liabilities and equity
DIMLIST
20
Used to group the accounts for use in business rules. For

example, using the DIMLIST property value can help
reduce the size of the FXTRANS table.
Note
Several DIMLIST properties can be used for one
PUBLIC
Page 26 of 102
dimension.
RATETYPE
10
Used by the currency translation business rules. This

property determines the business rules to be applied when
translating any given account from local currency to
reporting or group currency. A value is optional.
The following special values of RATETYPE are possible:
blank
All accounts are translated with a factor of 1.
NOTRANS
Accounts are not translated.
ELIMACC
20
Used in the elimination process and represents the

difference account to which the accounts to be eliminated
are posted.
Note
This property is used only with the US Eliminations
business rule.
Category Dimensions
All models require a category type dimension. The properties required in this dimension as described in the following table are for three business rules: currency
translation, eliminations and adjustments and copy opening balances.
For simulation purposes, or to analyze the variances from one set of data to another, you should mix-and-match different rates and values of different data
categories from different periods. For example, a user might want to compare ACTUAL with BUDGET values when both are translated at the ACTUAL rates, or
this year's ACTUALS with last year's ACTUALS, both being translated using last year's rates.
This can be done by either creating an additional simulation CATEGORY (such as Actual_at_Budget_rate or similar) or adding an extra dimension to the MAIN
cube, where all the simulated cases can be stored.
There is no need to copy the input values to all models for all the desired simulations. A few definitions stored in some specialized properties of the CATEGORY
(or the FX simulation) dimension inform the translation procedure where to read the input values and where to write the translated results.
To minimize the impact of the different simulations on the size of the database, it is also possible to tell the system to store only the difference between the default
results and the simulated scenarios.
When using the simulation categories in the MAIN cube, simulated translations are stored in additional members of the Category dimension. These categories
have non-blank values for one or more of the following properties:
Any dimension that is assigned the type C is considered to be a Category dimension.
Property Name
Length
FX_SOURCE_CATEGORY
20
The category for the source (LC) data. If blank, it is the

current category.
RATE_CATEGORY
20
The category from which the rates are read.
RATE_YEAR
The year from which the rates are read.

The value can be absolute (such as 2008, or 2009) or a
relative value (-1, -2, +1, +2). If blank it is the same as the
source.
RATE_PERIOD
10
The period from which the rates are read.

The value can be absolute (such as DEC, or FEB) or a
relative value (-1, -2, +1, +2). If blank it is the same as the
source.
FX_DIFFERENCE_ONLY
If Y, only the difference between the default values and the

simulated values is stored.
The business rules for copying opening balances can be controlled by assigning special properties to the category dimensions. If used, these properties affect
the execution and are defined in the following table:
Property Name
Length
CATEGORY_FOR_OPEN
20

Blank
The category for the opening balances is the same.
Not blank
The ID of the category from which to read the
opening balances.
OPENING_YEAR
Blank
Read the opening balances from the year before the
current year.
Not blank
Contains the year from which to read the opening
balances. It can be an absolute or a relative amount
OPENING_PERIOD
10
Blank
Read the opening balances from the last period of
the year.
Not blank
Contains the period from which to read the opening
balances. It can be an absolute or a relative amount
Audit Dimension
PUBLIC
Page 27 of 102
You should consider the following rules:

Mandatory for the elimination business rules. The DATASCR dimension is required for elimination and consolidation business rules. For example, automatic
elimination only works if you have a base level value of data source type A.
Optional for the currency business rules. It is not used in the business rules for currency translation.
Mandatory for the consolidation business rules. It is required as the results destination. For example, you can define, by source data source, a specific
destination data source where the resulting postings should be posted.
Any dimension that is assigned the type D is considered to be an Audit dimension.
The following table details the data source dimension properties:
Property Name
Length
IS_CONVERTED

Y
The data source is converted.
N
The data source is not converted.
G
Converts the data source from the reporting
currency to the group currency. That is, the
members are copied from the reporting currency of
the GROUP that is being translated into the
currency member corresponding to the specified
group.
IS_CONSOL
DATASRC_TYPE
Blank
Used for top adjustments of consolidated amounts
Y
Standard setting to consolidate data
I - input
M - manual journal entry
A - automatic adjustment
L - level
This is used in consolidation by level to move prior
level eliminations into a data source with property
DATASRC_LEVEL of Y in the GROUP
dimension.
COPYOPENING
Y (or blank)
The member is copied
N
The member is not copied
OPENING_DATASRC
20
Blank
The data source is the same as the source member
Non-blank
Contains the ID of the desired destination data
source for the copy
Entity Dimension
The Entity dimension defines the organizational structure of the business units for your model and how the units aggregate. Any dimension that is assigned the
type E is an Entity dimension. Each model can have only one entity-type dimension.
The following table details the entity dimension properties:
Property Name
Length
Description of appropriate property value
CURRENCY
20
Local currency used by the entity.

This currency must be defined in the InputCurrency
dimension.
FX_TYPE
20
Assigns a set of translation rules to an entity. Different

entities can use different sets of rules.
Optional.
OWNER
60
Used for work status.

Optional.
Intercompany Dimension
The Intercompany dimension ( I) defines the intercompany codes for entities in consolidation and ownership models.
Currency
The currency type dimension is required if the customer reports on local currency and translated values. You can use the currency type dimension for both
currency and groups, or you can split it into a Group dimension (type G) and a pure Currency dimension (type R) to allow reporting in multiple group currencies.
The required properties for a separate group dimension are the following:
Dimension
Property Name
Length
Description of Appropriate Property

Value
GROUP_CURRENCY
20
Can be any valid reporting currency. Used

for currency translation.
This property can only be used on
PUBLIC
Page 28 of 102
CURRENCY members with the property

CURRENCY_TYPE of G and, in this case,
it must contain a valid ID from the
CURRENCY dimension with the property
CURRENCY_TYPE of R.
G
PARENT_GROUP
20
Must be a valid ID from the Groups

dimension.
If you want to do the consolidation by level,
you must indicate here the higher level
from the group.
If you want to use this property to define the
hierarchy, enter the same code as the ID for
your top group. If this property is blank, the
ownership-based hierarchy from the
OWNERSHIP model is used.
ENTITY
20
Blank or a valid Entity ID.

This is used to define the link between the
Group and the Entity or to indicate the
Entity where the aggregation should be
stored.
If this property is filled with valid ID, and the
property STEntityORE_ENTITY is set to Y,
the results of the currency translation for
the current Group are also copied into this
Entity.
STORE_GROUP_CURR
Used for currency translation.

Y
By default the results of the
translation into a Group currency are
written in both the Group member
and in the Currency member of the
currency dimension.
N (or blank)
If only the Group member is to be
stored, set this property to N.
STORE_ENTITY
Y
If you want to store in the ID entered
in the Entity property.
Blank
If you do not want to store in the ID
entered in the Entity property.
STAGE_ONLY
This property controls the way the

converted values are saved when
performing a multilevel conversion of
groups.
This property can only take the values Y, E,
or N (blank).
G and R
CURRENCY_TYPE
L - local currency
R - reporting currency
T - transaction currency
G - group
Used for the currency translation.
FIRST_CONS_DATE
10
Blank
Management model.
YYYYMMM
Indicates the month and year of the
consolidation.
Flow Dimension
The flow type dimension is optional but its use is highly recommended. This dimension allows you to track changes within the account activities, such as opening
balance, additions, subtraction, and currency translation adjustments. If you do not require this level of detail, leave the business rule tables blank for the subtable field. Flow is similar to the movement type in SAP ERP.
If Flow is included in the model, it can be used in the following ways:
The currency translation procedure can detail the changes in the balance sheet generated by fluctuations in the exchange rates
The consolidation procedure can detail the eliminations applied to the movements of the balance sheet accounts
Any dimension that is assigned the type S is considered a Flow dimension.
If you choose to use a flow type dimension, the following properties are required:
Property Name
Length
FLOW_TYPE
12

OPENING - opening
TRANSLOPE - change diff on opening
ALLOCINC - allocation
MERGER - merger
INCOME - net income from the period
PUBLIC
Page 29 of 102
CHANGE - variation.
TRANSFER - transfer
TRANSFLOW - translation change on flow
VARSCP - variation in scope (generic)
VARSCPMETH - variation in scope method
VARSCPPERC - variation in scope percentage
VARSCPNEW - variation in scope; new company
VARSCPLEAV - variation in scope sold company
CLOSING - closing
NONE - no flow
Blank - all other flows
DIMLIST
20
Used to group the flows for several business rules
Flow dimensions should contain dimension members that require the following FLOW_TYPE property values:
OPENING
CLOSING
VARSCP
Activities
To manage dimension members and their property values
1. Select
2. Select the row containing the dimension member required:
to manage dimension members - click Edit Members
to manage the property values - click Edit Structure
Dimensions
1.4.4 Master Data (Dimensions) Setup

Use
Create the model for legal consolidation.
Features
The consolidation engine leverages the following models to retrieve the information necessary to perform its calculations:
The Legal or MAIN model
This consolidation type model is the model within which the respective consolidation entries for items, such as currency conversion or intercompany
eliminations, are written.
The RATE model
The currency conversion process uses a RATE model to look up the appropriate exchange rates for each relevant currency.
The OWNERSHIP model
The consolidation process uses an OWNERSHIP model, to store the definitions of each consolidation parameter. In particular, such definitions may include:
The list of companies being consolidated in each group
The consolidation method used in each case
The consolidation percentage for each case
The ownership percentage (how much of each is owned by the group)
The control percentage (how much of each is controlled by the group)
The MAIN, RATE, and OWNERSHIP models can be named as desired. Within the same environment, multiple MAIN models may exist, each one pointing to its
own RATE and OWNERSHIP models. Multiple MAIN models can also share the same RATE or OWNERSHIP models, if appropriate.
The RATE model, associated with a given model, is defined as an option upon the creation of a new MAIN model in Planning and Consolidation Administration.
The OWNERSHIP model, associated with a given model, is defined as an option upon creation of a new Consolidation model in Planning and Consolidation
Administration.
If this value does not exist, the consolidation procedure searches for a model named OWNERSHIP.
Each one of the above models must contain some required dimensions, while some other dimensions are optional. For more information, see Dimension Setup in
Dimension Library.
The required and optional dimensions are based on the standards used in the business rules. Other dimensions can coexist in a reporting model but do not
impact the business rule function.
All models must contain the following four required dimensions: ENTITY, CATEGORY, TIME, and ACCOUNT. They can be renamed as desired.
The CATEGORY and TIME dimensions can be the same across the MAIN, RATE, and OWNERSHIP models. Alternatively, they must contain the appropriate
matching members.
The ENTITY dimension of the MAIN model can be the same as that used in the OWNERSHIP model or it must contain the appropriate matching members if
different.
The GROUP dimension used must be the same in the OWNERSHIP model and the MAIN model. Here are some of the common member requirements between
these dimensions for the Legal consolidation environment setup described below:
In most cases, it is recommended that you use the same dimensions across models as it is easier to maintain.
Note
The RATE model is delivered with EnvironmentShell. Most dimension properties required for the consolidation setup are delivered with the dimensions.
However, it is recommended that you verify this before proceeding further.
PUBLIC
Page 30 of 102
1.4.5 Create or Modify the Model

Use
When working with a model, the model type tells the system which properties to associate with the model.
Features
In SAP BusinessObjects Planning and Consolidation, a model is either Reporting or Non-reporting. Non-reporting models support reporting models by holding
data, for example, price or rate information.
Following are the three types of reporting model in SAP BusinessObjects Planning and Consolidation:
Financial
A financial reporting model performs management consolidation functions, such as currency conversions, and intercompany eliminations.
This model must reference a rate-type model.
Consolidation
A consolidation reporting model performs legal consolidations. This is similar to a financial model, but with legal consolidation rules instead of management.
This model must reference an ownership-type model and a rate-type model.
Generic
A generic reporting model has no special requirements (other than to include a minimum of the four required dimensions).
The non-reporting types of models can be associated with only the financial and consolidation type models. Following are the two types of non-reporting model:
Rate
This model stores exchange rates that support currency conversions for reporting models. The model must include a currency-type dimension to store the
exchange rates by currency.
Ownership
An ownership model stores information such as the consolidation methods, ownership percentages, and group roll-up information used for legal consolidation.
Within the same environment, multiple reporting models may exist, each one pointing to its own RATE and OWNERSHIP models. Multiple reporting models can
also share the same RATE or OWNERSHIP models, if appropriate.
The RATE or OWNERSHIP model associated with a given reporting model is defined when a new consolidation type model is created.
Note
You can report on non-reporting model data, but you cannot assign work status codes to the data. In addition, you cannot define business rules to these model
types. All models require at least the four main dimension types: Entity, Account, Time, and Category.
In SAP BusinessObjects Planning and Consolidation, a consolidation scenario requires at least the following models:
Legal or MAIN
This is the main model containing all financial data. All consolidation postings such as eliminations, and minority interest calculations are posted in this
model.
OWNERSHIP
The OWNERSHIP model manages the organization structure and ownership percentages.
RATE
This contains all currency exchange rates for the different rate types such as average, and sport rate.
Currency translation can run on any type of reporting model. Currency conversion applies to both financial and legal consolidation models to which a
corresponding RATE model has been referenced. The reporting model must contain a currency (type R) dimension.
RATE Model
A rate model is a supporting model for financial and consolidation reporting models. It is used to store exchange rates that support currency conversion in
consolidation models. EnvironmentShell comes with a RATE model, so you can leverage this by just modifying the Category dimension from Category to
C_Category. The time dimension must be identical to the dimension used by the models using the RATE model to store their foreign currency exchange rates and
must have the same category member IDs.
This model must include a currency dimension detailing the exchange rates by each input currency. The currency dimension in a rate model does not need to
have the REPORTING property. The currency conversion process makes use of a RATE model, where the appropriate exchange rates are searched for each
relevant currency. This cube can be named as desired.
Note
The master data (dimension) can be shared by any model within an environment.
The RATE model requires the following dimensions:
Account (account dimension for the RATE model)
This details the different types of rate (Average, End-of-period, and so on). Account is specific to and used only by a RATE model.
Entity (entity dimension for the RATE model)
This stores multiple tables of rates, if required. Alternatively, the Entity dimension can be limited to one dummy member, typically named GLOBAL. For
example, if there is an entity C1000 for which a special exchange rate needs to be applied, it is defined here and the special rates are applied.
Entity is specific to and used only by a RATE model.
Currency
This dimension stores each applicable local currency.
Time and Category
These dimensions can be shared by all or the models involved in consolidation.
OWNERSHIP Model
Any consolidation type model must refer to a RATE and an OWNERSHIP model. EnvironmentShell is delivered only with PLANNING and RATE models.
Therefore, the OWNERSHIP model needs to be created before you can create the consolidation model. Refer to the model creation wizard to understand the steps
PUBLIC
Page 31 of 102
of the creation process.

The business rule process uses an ownership type model when calculating the ultimate ownership or during the minority interest calculation. This model must be
associated with a consolidation type model. The OWNERSHIP model contains the values of each consolidation parameter. In particular, such definitions may
include:
The list of companies being consolidated in each group
The consolidation method for each company
The consolidation percentage for each company
Their ownership percentage (how much each company is owned by the group)
The control percentage (how much each company is controlled by the group)
The OWNERSHIP model can be named as desired.
The OWNERSHIP model defines ownership details such as the consolidation scope, method, percentage of shares owned by the holding company or groups.
For the OWNERSHIP model, the only dimension that is specific to the OWNERSHIP cube is the Ownership Account that the consolidation engine uses to get the
information listed above. To pass the information, several required members need to be defined. The required members are as follows:
Method defines consolidation method
POWN defines the percentage of ownership
PCON defines the percentage of consolidation
PCTRL defines the percentage of control
Consolidation (MAIN) Model
Any consolidation type model must refer to a RATE and OWNERSHIP model.
Activities
Associate the desired RATE and OWNERSHIP models with the consolidation model and select all the consolidation business rules that need to be implemented.
You can select from the following list of business rules:
Currency conversion
Conversion of local currency data to the desired reporting currencies.
Calculations
To calculate and store amounts which are required for purposes of account-based calculations.
Matching intercompany transactions
US Eliminations
Specifically designed to address the posting of intercompany eliminations in simpler scenarios where a full legal consolidation model is not required
Carry Forward
Initialization of beginning balances when a new fiscal cycle starts
Validation
Validation of input data
Eliminations and Adjustments
Generation of all the consolidation entries for the desired groups of entities (for example: eliminations, adjustments, reclassifications and minority
calculations.)
Consolidation business rules allow the automated processing of data to render a consolidated set of financial statements. This is commonly thought of as
eliminations of investments in subsidiaries, adjustments of minority interest, reclassifications and any other postings depending on the nature of the consolidation
methodologies required.
Select only the desired dimensions required for legal consolidation and deselect any others.
Set dimensions to be included in the consolidation model and also set the secured dimension to control the security through SAP BusinessObjects Planning and
Consolidation member access profiles.
Normally the Entity and Category dimensions are set as secured dimensions for member access control.
The Group dimension stores group currency, reporting currency and consolidation groups. The MAIN cube must contain a CURRENCY dimension to store the
translated amounts. The consolidation entries, as generated by the consolidation process, are also stored by Group dimension.
Any additional dimension is optional in the MAIN cube, as far as the currency translation is concerned. For consolidation purposes, however, there are some other
requirements. These are described below:
The model may have an Intercompany dimension.
The model may have a FLOW dimension. This dimension is optional, but, if it exists, it can be used by the following procedures:
The currency translation procedure details the changes in the balance sheet generated by fluctuations in the exchange rates.
The consolidation procedure details the eliminations applied to the movements of the balance sheet accounts.
An Audit dimension may exist in the MAIN cube, but it is not required by the currency translation. If it exists, however, the currency translation can
recognize which members of the dimension should be translated, and which ones should just be copied as is to the destination currency. However, this
dimension is required for the consolidation procedure to work.
Additional (user defined) dimensions can be added to the MAIN cube (such as product, market, or division), as desired. The consolidation engine can recognize
their existence and take them into account in the process, and apply custom behavior to their members.
1.4.6 Set the Model Parameters (version for the Microsoft

platform only)
Use
Model parameters provide groupings of properties that affect how models are used. The legal model requires some settings, and some of the parameters
determine how to use organizational information from the ownership model.
Features
PUBLIC
Page 32 of 102
Features
When you create a consolidation type model, you should choose the settings of the model parameters in accordance with the intended purpose of the model. The
following table details business rule activation during the creation of a consolidation type model in SAP BusinessObjects Planning and Consolidation, version for
the Microsoft platform:
Setting
Description
APPROVALORG
If you want to use the work status feature, you must use this field to identify the
hierarchy level ( H1, H2, H3, ..., Hn) for which you want to track the work status of
deliverables. You can define only one hierarchy for each model within an environment.
For other organizations, No Status displays when viewing these members in the work
status screen. If this field is blank, work status tracking is disabled.
BPC_STATISTICS
When set to ON , various SAP BusinessObjects Planning and Consolidation modules

write detailed runtime statistics to the tables UJ0_STAT_HDR and UJ0_STAT_DTL. You
can use this information to monitor system performance. Valid values are ON and
OFF .
CALCULATION
Allows the use of the calculation business rule tables. The default value is 1.
FXTRANS
Allows the use of the currency translation business rule tables. The default value is 1.
INTCOBOOKINGS
Allows the use of the intercompany booking business rule tables. The default value is 1.
JRN_REOPEN_PROPERTY
A custom journal module assumes that the property UB is in the Account dimension to
filter the journals upon reopen. The default is Group. If Group, there is no need to modify
the Account dimension.
OPENINGBALANCE
Enables the business rule table for balance carry forward. The default value is 1.
ORG_ACCOUNTLIST
Member IDs of the ownership account dimension that store methods, %con (percentage
consolidation), %own (percentage ownership). These appear in the dynamic hierarchy
editor.
The default value is METHOD,POWN,PCON.
ORG_ACCOUNTOWN
Member ID of the ownership account that specifies the position of a consolidation entity
within the group.
The default value is PGROUP.
ORG_INTCO
The third party member in the Intercompany dimension to which all ownership
calculations are posted.
The default value is I_NONE, which should also be a member ID in the INTCO
dimension in the ownership model if using an ownership-based hierarchy.
ORG_OWNERSHIP
The consolidation logic requires the currency translation and consolidation procedures to
be listed here.
If no value is specified, the consolidation procedure defaults to the value OWNERSHIP.
ORG_OWNERSHIPCUBE
Name of the linked ownership model. The default value is OWNERSHIP.
ORG_PARENTPROPERTY
The property name in the Groups dimension that defines the ownership-based hierarchy
used in the Ownership Manager. The Group property contains the legal roll-up
members.
This property is used with ownership-based hierarchy statutory models when defining
fixed hierarchies. The value must match the value in the ParentProperty property value
of entities in the statutory model's supporting ownership model. The default value is
PARENT_GROUP.
USELIM
Allows the use of the business rule tables for US eliminations. The default value is 1.
VALIDATIONS
Allows the use of the validation business rule tables. The default value is 1.
YTDINPUT
This parameter controls whether data is input in year-to-date format. Valid options are 1
for YTD format and 0 for periodic format. This parameter is optional.
The following table lists the relevant model settings and the recommended values that should be set in SAP BusinessObjects Planning and Consolidation, version
for the Microsoft platform. (Refer to the Administration Model Help for instructions on how to set these values):
Key ID
Value
APPROVALORG
H1
FXTRANS
INTERCOMPANY
JRN_BALANCE
JRN_POST_OVERWRITE
OPENINGBALANCE
ORG_ACCOUNTLIST
METHOD, PCON, POWN
ORG_ACCOUNTOWN
PGROUP
ORG_INTCO
I_NONE
ORG_OWNERSHIPCUBE
OWNERSHIP
ORG_PARENTPROPERTY
PARENT_GROUP
OWNERSHIP_APP
OWNERSHIP
VALIDATIONS
PUBLIC
Page 33 of 102
WORKSTATUSVALIDATE
YES
YTDINPUT
YES
YTDINPUT Setting
One of the most important model parameters in Planning and Consolidation Administration that should be set is YTDINPUT. This defines the model type whether it
is periodic or YTD (year to date). This parameter plays an important role since it controls how the data is stored in the cube.
Most source systems store balances on a periodic basis (for example, daily, weekly, monthly, or fiscal periods). With this method, periodic data must be
accumulated for year-to-date reporting (except for balance sheet accounts, which gets the value from the last period).
However, in some business cases, calculations should occur on a year-to-date basis. If YTD is required, models can store the data on a YTD basis. When data is
entered into YTD, its periodic values used for reporting purposes are calculated as the difference between the current period and the last period (balance sheet
accounts would simply take the value from the last period).
By default, models are periodic. You can change the YTDINPUT parameter to a value of 1 to turn it into a YTD storage type.
Activities
Refer to the Administration Model Help for information about setting model parameters.
1.4.7 Business Rule Setting

Use
SAP BusinessObjects Planning and Consolidation delivers predefined functions designed to calculate and post amounts required to support common accounting
activities, such as:
Currency translation
Matching and elimination of inter-unit balances.
Features
For each predefined data package and script logic, there are one or more Business Rule tables, in which a business user can configure rules. The consolidation
engine uses these rules to perform all the appropriate calculations on a user-selectable region of data, and write the calculated results into the database
Business rules provide the flexibility for a business user to customize the delivered logical functions, to meet specific business needs, without having to
understand either scripting or programming.
To run these programs, use the Data Manager packages.
The following table lists the consolidation process tasks and the corresponding business rules:
Consolidation Task
Process Chain Name
Script Logic Files Name
Business Rule Name
Balance carry forward
/CPMB/OPENING_BA LANCES
COPY_OPENING.LGF
Carry-forward rules
/CPMB/FX_RESTATM ENT
FXTRANS.LGF
Currency translation rules
Intercompany reconciliation
/CPMB/ICDATA
ICDATA.LGF
No rules needed
Intercompany balance booking
/CPMB/ICBOOKING
ICBOOKING.LGF
Intercompany booking
Legal consolidation
/CPMB/LEGAL_CONS OLIDATION
CONSOLIDATION.LGF
Eliminations and adjustments and details
Account calculation
(cash flow function)
/CPMB/RUNCALCAC COUNT
CALCACCOUNT.LGF
Account-based calculation
US widely used
/CPMB/IC_ELIMINATI ON
ICELIM.LGF
US elimination
(elimination and adjustment)
Intercompany elimination
For each process, the predefined Data Manager packages with their associated logic scripts and rule tables are executed, performing the consolidation task
according to the business rule customization. Any specific business requirement needs to be configured in the corresponding business rule.
1.4.8 Execute Consolidation Task

Context
Data Manager packages are implemented as process chains and allow common data manipulation activities. The packages that come with SAP
BusinessObjects Planning and Consolidation are designed to be dynamic so you do not need to modify the packages for them to work with your models and
dimensions.
Data Manager packages allow you to manage data within SAP BusinessObjects Planning and Consolidation models and dimensions.
The Financial packages that can be used for the consolidation process, apart from the Standard and Administrative packages, are in the following table:
Process Chain Template
Description
Technical Name
Planning and Consolidation Default Formulas Logical
Executes default formulas stored in your default.xls file.
/CPMB/DEFAULT_FORMULAS
Planning and Consolidation FX Restatement
Allows you to perform currency translation. The package

runs the FXTrans logic.
/CPMB/FX_RESTATMENT
PUBLIC
Page 34 of 102
Planning and Consolidation IC Elimination
Allows you to perform intercompany eliminations. The

package runs the ICElim logic.
/CPMB/IC_ELIMINATION
Planning and Consolidation: ICBooking
Runs the ICBooking logic.
/CPMB/ICBOOKING
Planning and Consolidation ICData
Runs the ICData logic.
/CPMB/ICDATA
Planning and Consolidation Legal Consolidation
Runs the LegalConsolidation logic.
/CPMB/LEGAL_CONSOLIDATION
Planning and Consolidation Opening Balances
Runs the OpeningBalances logic.
/CPMB/OPENING_BALANCES
Planning and Consolidation Run CalcAccount
Runs the CalcAccount logic.
/CPMB/RUNCALCACCOUNT
Planning and Consolidation Clear the Journal Tables
Clears journal tables and creates an output file.
/CPMB/CLEAR_JOURNALS
Planning and Consolidation Export the Journal Tables
Exports journal tables to an output file
/CPMB/EXPORT_JOURNAL
Planning and Consolidation Restore Journal Tables
Allows you to load journal tables from a file
/CPMB/RESTORE_JOURNALS
Procedure
1. Add the Data Manager packages for a consolidation model:
For more information, see the SAP BusinessObjects EPM solutions, add-in for Microsoft Office help.
2. Create Script Logic files (LGF).
Script Logic allows users to define formulas that perform calculations on SAP BusinessObjects Planning and Consolidation members and data.
You can create the following different types of logic:
Dimension Member Formulas;
Script logic.
Each type has advantages and disadvantages. Logic is model-specific and all script logic statements are case-insensitive.
1. Select
Rules
Logic Scripts .
2. Select Scripts for CONSOLIDATION and click Open .
3. Click New .
4. Create an LGF file by using the script logic supported by SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver.
Note
The Logic File name must be identical to the string defined with the data package.
3. Maintain the business rule table.
SAP BusinessObjects Planning and Consolidation delivers predefined functions designed to calculate and post amounts required to support common
accounting activities such as:
Matching and elimination of inter-unit balances.
To allow a customer the flexibility to customize these functions to meet specific requirements table-based logic is used.
For each predefined function, there are one or more Business Rule tables, in which the business user can configure rules such as:
What balances should be read in order to calculate an amount to be posted.
What are the posting rules for the calculated amount (meaning, to what account and data source is the calculated amount posted).
Table-based logic (Business Rules) provides the flexibility for a customer to customize delivered functions (logic), to meet specific business needs, without
having to understand either scripting or programming.
The following Business Rule (table-based logic) functions are delivered with SAP BusinessObjects Planning and Consolidation:
Currency Translation
Convert local currency data into the desired reporting currencies
Account-based Calculations
Calculate and store amounts, which are required for purposes of account-based
calculations
Intercompany Bookings
Match intercompany transactions
US Eliminations
US eliminations
Specifically designed to address the posting of intercompany eliminations in simpler
scenarios where a full legal consolidation model is not required.
Carry-Forward
Initialize the opening balances when a new fiscal cycle starts
Eliminations and adjustments
Generate all the consolidation entries for the desired groups of entities (such as
eliminations, adjustments, reclassifications, and minority calculations)
The procedure to maintain the business rules is as follows:

1. Select
Rules
Business Rules .
2. Select the CONSOLIDATION Model and click Add/Remove Rule Types in the toolbar.
3. In the Add/Remove Rule Types dialog box, select the rule types you require and click OK .
4. Click the business rule type under the CONSOLIDATION model in the table grid.
Alternately, select the row of the business rule and click Open in the toolbar.
5. In the Business Rule Editor, click New to create a new rule, or select an existing rule and click Edit in the toolbar to modify the content of an
existing rule according to business requirements.
1.4.9 Loading Data

Procedure
1. Load the exchange rate to the RATE model.
The RATE model stores the exchange rates for doing currency translation. There are several ways to upload the data to the RATE model, such as using the
Data Manager package - import, or using dynamic templates to send data from the input schedule. For more information, see Currency Translation Rule.
PUBLIC
Page 35 of 102
2. Input ownership data and calculate ultimate ownership.

SAP BusinessObjects Planning and Consolidation 10.0, version for SAP NetWeaver provides an ownership-based hierarchy editor in Consolidation Central
so you can update the OWNERSHIP model directly.
3. Load the financial data.
After loading the financial data, use an SAP BusinessObjects Planning and Consolidation report to validate that the numbers loaded reconcile with the
numbers in the source system.
1.4.10 Journal Definition and Validation Setting

Use
Journals allow users to make adjustments to data in the database, typically as part of the month-end or quarter-end process. During the review and analysis step,
journals allow users to capture an audit trail of the changes and adjustments made to the database.
The purpose of validation is to prevent incorrect records being saved to the cube.
Features
Journal Template Definition
The primary requirement for journals is to track changes to data after the initial source data is input into the model. For example, the general ledger information is
loaded into the model through the Data Manager. The model users can adjust this data and also track and report on the changes by, for example, amount, date,
and user.
For information about setting up journals, see Journal Administration. For information on defining a journal template, see Journal Template Creation
Once the journal template is created, neither the dimension nor the data in the model can be deleted from the model.
Validation Setting
Validations are designed to prevent incorrect cube intersections from being saved. You cannot get data into a cube without going through the Write-Back module.
Therefore, validations are implemented in write-back, to ensure that invalid records cannot get into the cube from any source, including journals, Data Manager
packages, and manual data input. For example, a specified intercompany account with an empty Trading Partner dimension is blocked from being written into the
cube.
To customize validation, in the SAP ABAP system enter the transaction code UJ_VALIDATION to configure the validation framework and customize the validation
rules according to your business requirements. For more information, see Breakdown Validation.
Caution
If you have already created a journal template, creating a new template that changes the structure of the journal entries deletes the old template and all journal
entries associated with that template. This removes your audit trail, even though changes made to the model data through posted journal entries are
maintained. If you recreate the journal template, but do not change the structure of the template keeping all header and detail dimensions the same, you have
the option to keep the existing journal entries.
More Information
Journal Administration
Journal Template Creation
1.4.10.1 Example
Use
After loading general ledger data into a model using Data Manager, the processor should be able to review the data and use journal entries to make adjustments if
there is any correction or reclassification needed.
When journal entries are saved and posted, all adjustments to data can be tracked and reported on. For example, it is possible to run reports on the changes by
amount, date, user, and several other properties to review and analyze.
Validations, on the other hand. are designed to prevent incorrect records from being saved to the cube. The user controls what is deemed an incorrect record. An
example of an incorrect record is one where you have specified an intercompany account, but you have left the Trading Partner dimension empty.
1.5 Rules
Use
You can perform calculations on your data using the following methods:
Business rules, which are parameter-driven functions within Planning and Consolidation models for calculating and posting monetary amounts in support of
common accounting activities.
Logic, with which you define formulas that perform calculations on Planning and Consolidation dimension members and data.
1.5.1 Member Formulas

Use
PUBLIC
Page 36 of 102
Member formulas allow you to create and execute formulas and calculations on dimension members.
Prerequisites
The Enable Member Formulas option is selected for the dimension to which you are applying the member formula. See Dimension Properties.
Features
Use the following guidelines when implementing formulas:
The system calculates formulas at retrieval time. Formulas can slow retrieval performance if used incorrectly.
Implement member formulas only for members that need calculating after aggregations, such as ratios. Do not use formulas on members that need to
aggregate.
Use formulas only for ratios that need to be calculated at both the base and parent level. If the resulting value is aggregated to the parent, use logic scripts
to write the results to the database.
You cannot reference MDX functions, also known as user-defined functions, from a library file.
For information about restrictions pertaining to member formulas, see SAP Note SAP Note 1356081
Activities
You can view the member formulas added to a dimension by selecting
Rules
Member Formulas
, then choosing the name of a dimension.
You can add a formula to a dimension, as well as edit and delete a formula assigned to a dimension.
1.5.1.1 MDX Formula Syntax

Use
The basis for a dimension and advanced rule formulas is the multi-dimensional expression language called MDX.
Features
You can use the following features of MDX formula syntax:
Syntax basics
You can write the dimension ID using both uppercase and lowercase letters case, and the member ID should be the identical case of the member.
You must enclose all member IDs in [square brackets].
You must fully-qualify all member IDs, preceded by the names of their related dimension enclosed in square brackets, unless the dimension is ACCOUNT,
in which case you may omit the dimension name.
MDX syntax exceptions
The following are exceptions to MDX syntax:
Replace the keyword AS with an equal (=) sign.
Do not use single quotes around expressions.
Note that the following structure is the normal syntax for calculated members required by MDX queries:
{member} = {expression}[, solve_order = n]
The only exceptions are the equal sign (=) in place of the "AS" keyword and the lack of single quotes around the expression.
More Information
For examples of simple MDX formulas that can be used in the Formula column for an account, see Simple Rule Formula Examples.
For examples of movement calculations and allocating expenses based on entity type, see Advanced Rule Formula Examples.
1.5.1.1.1 Simple Rule Formula Examples

Use
The following are examples of simple MDX formulas that can be used in the Formula column for an account:
Features
Task
Syntax and Example
Adding two accounts
Syntax:
[DIMENSION].[ACCOUNT1] + [DIMENSION].[ACCOUNT2]
Example
PreTax Income:
[ACCOUNT].[OPERATING INCOME] + [ACCOUNT].[OTHEREXP].
Adding a range of accounts
Syntax:
PUBLIC
Page 37 of 102
[DIMENSION].[ACCOUNT1]:[DIMENSION].[ACCOUNT2]
Example
Total Personnel Exp:
SUM([ACCOUNT].[SALARIES]:[ACCOUNT].[COMMISSION])
Calculating a percentage
Syntax:
[DIMENSION].[ACCOUNT1] / [DIMENSION].[ACCOUNT2]
or (to prevent division by zero):
IIF([DIMENSION].[ACCOUNT1] = 0, NULL,
[DIMENSION].[ACCOUNT2]/[DIMENSION].[ACCOUNT1])
Example
Gross Margin Pct:
IIF([ACCOUNT].[REVENUE] = 0, NULL, [ACCOUNT].[GROSS
MARGIN]/[ACCOUNT].[REVENUE])
Multiplying by a factor
Syntax:
[DIMENSION].[ACCOUNT1]*[DIMENSION].[ACCOUNT2]
Example
Taxes:
[ACCOUNT].[PRETAX INCOME] * -0.35
Calculating a YTD value
Syntax:
[DIMENSION].[ACCOUNT1],[MEASURES].[YTD]
Example
Current Year Net Income:
([ACCOUNT].[NET INCOME], [MEASURES].[YTD])
1.5.1.1.2 Advanced Rule Formula Examples

Use
Advanced rule formulas include movement calculations and expense allocation based on entity type.
Features
You can use the following features of advanced rule formulas:
Movement calculations
Movement calculations define the copying or movement of data from one time period to another. In the formula examples below, [ AccRec] is the accounts
receivable account, and [ AccPay] is the accounts payable account.
Example
Account
Description
Formula
Mvmt Acc Rec
Movement in Accounts Receivable
IIF([TIME].CURRENTMEMBER.PROPERTIES("CALC
")="N", [ACCOUNT].[ACCREC] ([ACCOUNT].[ACCREC], [TIME].PREVMEMBER),
SUM(DESCENDANTS([TIME].CURRENTMEMBER, 20,
LEAVES)))
With the formula, you are checking whether the current
TIME member is parent or not by checking the property
CALC = NO. If it is not a parent, then we take the current
TIME member's Account Receivables (ACCREC) and
subtract the previous month's Account Receivables. If the
current TIME member is parent, then you simply sum
up all of the children.
Mvmt Inventory
Movement in Inventory
IIF([TIME].CURRENTMEMBER.CHILDREN.COUNT=0
, [ACCOUNT].[INVENTORY] ([ACCOUNT].[INVENTORY],
[TIME].PREVMEMBER),
LEAVES)))
The formula checks inventory.
Mvmt Acc Pay
Movement in Accounts Payable
IIF([TIME].CURRENTMEMBER.CHILDREN.COUNT=0
, [ACCOUNT].[ACCPAY] ([ACCOUNT].[ACCPAY], [TIME].PREVMEMBER),
LEAVES)))
Mvmt Work Cap
Movement in Working Capital
SUM([ACCOUNT].[MVMT ACC
REC]:[ACCOUNT].[MVMT ACC PAY])
PUBLIC
Page 38 of 102
Allocating expenses based on entity type

The following examples assume there is an Entity property named Function . If an entity has the function SM , the Total Department Expense is allocated to the
S&M Exp account. If an entity has the function RD , the Total Department Expense is allocated to the R&D Exp account. If an entity has the function CORP , the
Total Department Expense is allocated to the G&A Exp account.
Example
Account
Description
Formula
S&M Exp
Sales & Marketing Expense
IIF([ENTITY].CURRENTMEMBER.PROPERTIES("CA
LC")="N",
IIF([ENTITY].CURRENTMEMBER.PROPERTIES(
FUNCTION ) = SM , [ACCOUNT].[TOTAL DEPT
EXP], NULL),
SUM(DESCENDANTS([ENTITY].CURRENTMEMBER,
[ENTITY].[LEV1], LEAVES)))
You first check if the current ENTITY member is parent or
not. Then, you read the property FUNCTION of the
current ENTITY member to see whether it is "SM" or not.
If it is "SM", then, you are taking the Total Department
Expense as a Sales & Marketing expense. Otherwise, it
will be assigned with zero. If current ENTITY is parent, a
sum of all children appears.
R&D Exp
R&D Expense
IIF([ENTITY].CURRENTMEMBER.PROPERTIES("CA
LC")="N",
FUNCTION ) = RD , [ACCOUNT].[TOTAL DEPT
EXP], NULL),
In this formula, you are taking the "RD" values of
FUNCTION property.
G&A Exp
G&A Expense
IF([ENTITY].CURRENTMEMBER.PROPERTIES("CAL
C")="N",
FUNCTION ) = CORP , [ACCOUNT].[TOTAL DEPT
EXP], NULL),
1.5.1.1.3 Nested Formulas

In a nested formula, a given part of that formula is calculated by another formula.
The functionality described in this topic applies only to systems based on SAP HANA, which enhances capabilities and improves performance of Business
Planning and Consolidation. If you are not using an SAP HANA-based system, disregard the information in this topic.
Prerequisites
You must have the SAP HANA Component for Planning and Consolidation HANABPCSP05 installed on your system.
Use
You can create a nested formula in which the different parts of that formula are calculated by other formulas.
Example
A=B+C
B=D-6
C=F*E
In the example above, the formula A is calculated by B and C. In turn B and C are also calculated by formulas.
Nested formulas are only supported by the HANA MDX engine. The HANA MDX engine significantly improves the performance when executing complex
calculations on large amounts of data.
1.5.2 Script Logic

Use
Script logic is a feature that allows you to create files called logic scripts containing instructions for performing calculations on Planning and Consolidation data.
PUBLIC
Page 39 of 102
Features
You can perform logic calculations on base level members only. In addition, logic is specific to each model.
Planning and Consolidation provides a library of MDX formulas, and the EnvironmentShell sample environment contains a number of logic functions.
Note
Logic keywords are case-insensitive. However, all environment, model, dimension, and member names in K2 are case-sensitive .
You have the following two files for each piece of script logic you create:
An .LGF file, which is an ASCII file you create and edit when setting up logic calculations. You access the .LGF file through the logic editor.
An .LGX file, which is the compiled logic file created by the system when you validate and save your logic. This is an executable version of the .LGF file
that is not stored in Planning and Consolidation.
Default logic is a special logic statement that is executed on every writeback to a model. All logic in Default.LGF is run after data sends. Data is first
committed to the model and then, Default.LGF is run on model data. Having all of your logic in the Default.LGF logic file might become unmanageable.
Therefore you can create other logic files, such as FXTrans.LGF for foreign currency translation and ICElim.LGF for intercompany eliminations. Your default
logic can contain an INCLUDE statement to execute specific logic in real-time, such as currency translation if desired, rather than having to run a separate batch
process.
You access logic files from the Script Logic subdirectory within the hierarchy of a model.
Logic Library
Planning and Consolidation has a library of standard logic functions available for your use. The file has the extension .LGF, which can be called at validation by
using the INCLUDE function in your logic file. The logic module scans the library file for the appropriate formulas to use based on the information in the .LGF file.
The following are examples of logic delivered with Planning and Consolidation:
Allocation.lgf: runs an allocation
Calcaccount.lgf: used to prepare Cash Flow; runs an Account Calculation business rule
Consolidation.lgf: used to run a Legal Consolidation business rule
Copy_Opening.lgf: used to run a Balance Carry Forward business rule
FX_Trans.lgf: used to run currency conversion
ICBooking.lgf: used for running Intercompany reconciliation and difference posting
ICData.lgf: used to run Intercompany reconciliation
ICElim.lgf: used to run Intercompany reconciliation
MDXlib.lgf: library of MDX financial functions
System_Constants.lgf: stores constant values for use within script logic. See the System constants file section that follows for more information.
System_Library.lgf: includes basic examples of a set of keywords
Validation.lgf: used for running a Validation rule
System Constants File
The system constants file is the logic file that maps your dimension names for a model to the standard Planning and Consolidation logic. By updating the
dimension constants file with your dimensions, you avoid having to change or rewrite any of the standard functions that are included with Planning and
Consolidation.
The system constants file is located in the \\root\Webfolders\ <Environment> \systemlibrary\logiclibrary folder. You can edit this file using
download and upload functions from transaction UJFS in the ABAP interface.
Running Script Logic
Script logic can be automatically invoked each time the system sends data to the database. Instructions in the default logic file are executed immediately after
data is sent and you can see the results immediately. Script logic can be run from Data Manager for batch processing of formulas. Using Data Manager to
execute Logic module formulas is useful for calculations that do not need to be executed immediately. For example, you may decide to wait until all data has been
entered in the local currency before generating the translated amounts in reporting currencies.
Activities
From the Planning and Consolidation Administration screen, you can view all logic scripts for a model by choosing
model, then choosing Open . All logic scripts that have been set up for that model display.
Rules
Logic Scripts
, selecting a
You can create a new logic script for the selected model by choosing New , then assigning a name to the logic script. You can type directly into the logic editor.
You can also insert Planning and Consolidation keywords, MDX keywords, dimension names, and member names from the dropdown lists, replacing variables in
the keywords as appropriate. To add a keyword from the dropdown lists to a line in a script, you can double-click on a keyword, you can select a keyword and
then select Insert Keyword , and you can drag and drop a keyword from the dropdown list into a line in the logic editor.
You can comment out and uncomment blocks of script logic, as well as individual lines, in the logic editor.
When you create new logic script and edit an existing script, you can validate its syntax. Any problems with the logic display in the lower portion of the logic editor
with line numbers to make locating and resolving the problems easier.
You can copy an existing logic script by selecting a file, then providing a name for the new script, and modifying it as you need.
You can use the following color coding in the logic editor to assist in writing and troubleshooting logic scripts:
Keywords display in blue
Constant values display in green
Comments display in grey
Incorrect syntax, such as parenthesis errors, misspelled keywords and dimension names, and unrecognized words, displays in red
You can easily resolve errors in script logic using the error lines in the lower portion of the logic editor window. Errors in a script appear by line number.
More Information
For more detailed documentation of script logic and examples, see the section Planning and Consolidation, version for the SAP NetWeaver Platform in the
Enterprise Performance Management (EPM) How-to Guides section of the SAP SDN at:
PUBLIC
Page 40 of 102
http://wiki.sdn.sap.com/wiki/display/BPX/Enterprise+Performance+Management+%28EPM%29+How-to+Guides.
1.5.2.1 Library of MDX Functions

Use
Planning and Consolidation provides several multidimensional expressions ( MDX) functions you can use in your dimension rule formulas. You can also use some
of these MDX functions in advanced rule formulas.
A majority of the MDX functions define industry-standard financial ratios. You can use ratios to evaluate the performance of your business and identify potential
problems. Ratios expose factors such as the earning power, solvency, efficiency, and debt load of your business.
Features
The following table describes some of the more common MDX functions:
MDX Function
Description
Parameters
Ancestor
Returns the ancestor of a member at a specified level
<Member>, <Level>
ClosingPeriod
Returns the last sibling among the descendants of a

member at a level
[<Level>[, <Member>] ]
Cousin
Returns the member with the same relative position

under a member as the member specified
<Member1>, <Member2>
Current Member
Returns the current member along a dimension during an (none)

iteration
Default Member
Returns the default member of a dimension
(none)
FirstChild
Returns the first child of a member
(none)
FirstSibling
Returns the first child of the parent of a member
(none)
IsEmpty
Determines if an expression evaluates to the empty cell

value
<Expression>
Item
Returns a member from a tuple
<Numeric Expression>
Lag
Returns a member prior to the specified member along the <Numeric Expression>
member's dimension
LastChild
Returns the last child of a member
(none)
LastSibling
Returns the last child of the parent of a member
(none)
Lead
Returns a member further along the specified member's

dimension
Members
Returns the member whose name is specified by a string

expression
(none)
NextMember
Returns the next member in the level that contains a

specified member
(none)
OpeningPeriod
Returns the first sibling among the descendants of a

member at a level
[<Level>[, <Member>] ]
ParallelPeriod
Returns a member from a prior period in the same relative [<Level>[, <Numeric Expression>[, <Member>] ] ]
position as a specified member
Parent
Returns the parent of a member
(none)
PrevMember
Returns the previous member in the level that contains a

specified member
(none)
Aggregate
Returns a calculated value using the appropriate aggregate <Set>[, <Numeric Expression>]
function, based on the context of the function
Avg
Returns the average value of a numeric expression

evaluated over a set
<Set>[, <Numeric Expression>]
CoalesceEmpty
Coalesces an empty cell value to a number
<Numeric Expression>[, <Numeric Expression>...]
Correlation
Returns the correlation of two series evaluated over a set
<Set>, <Numeric Expression>[, <Numeric Expression>]
Count
Returns the number of tuples in a set, empty cells
<Set>[, EXCLUDEEMPTY | INCLUDEEMPTY]
included unless the optional EXCLUDEEMPTY flag is used

IIf
Returns one of two values determined by a logical test
<Logical Expression>, <Numeric Expression>,

LinRegIntercept
Calculates the linear regression of a set and returns the

value of b in the regression line y = ax + b
LinRegPoint

value of y in the regression line y = ax + b
<Numeric Expression>, <Set>, <Numeric Expression>[,

<Numeric Expression>]
LinRegR2
Calculates the linear regression of a set and returns R2

(the coefficient of determination)
LinRegSlope

value of a in the regression line y = ax + b
PUBLIC
Page 41 of 102
value of a in the regression line y = ax + b

LinRegVariance
variance associated with the regression line y = ax + b

Max
Returns the maximum value of a numeric expression

Median
Returns the median value of a numeric expression

Min
Returns the minimum value of a numeric expression

Sum
Returns the sum of a numeric expression evaluated over
a set
For additional NW BI MDX keywords, run function module BAPI_MDPROVIDER_GET_FUNCTIONS via transaction SE37.
1.5.2.1.1 Custom Logic and BADI

Use
You use this instruction to call any custom ABAP programming you have written.
Activities
Run the following instruction to call custom ABAP programs:
*CALL_CUSTOM_LOGIC <filter_value_of_the_BADI>
where filter_value_of_the_BADI is the name of the filter you provided during the BADI implementation of UJ_CUSTOM_LOGIC BADI.
Custom logic example
*CALL_CUSTOM_LOGIC COMPLEX_ALLOCATION
BADI examples
*START_BADI / *END_BADI call any custom ABAP programming written using UJ_CUSTOM_LOGIC BADI (Transaction SE19) and allow you to export
parameters to ABAP codes in the BADI.
Syntax
*START_BADI <filter_value_of_your_BADI_implementation>
<key1> = <value1>
<key2> = <value2>
*END_BADI
where filter_value_of_your_BADI_implementation is the name of the filter you provided during the BADI implementation of UJ_CUSTOM_LOGIC
BADI.
Syntax example
The following example shows how to call an implemented BADI, with CALC_ACCT as the filter value, for adding two accounts to a destination account:
*START_BADI ROUND
DECIMAL = 2
*END_BADI
The DECIMAL parameter is visible in the IT_PARAM internal table inside the EXECUTE method. In the EXECUTE method, you can write custom code to change
the incoming transactional data of CT_DATA.
Optional Parameters
You can use the following optional parameters within a *START_BADI / *END_BADI instruction:
Query - Performs the default query. Valid values are On, the default, and Off. Set Query to Off if you want to perform your own query.
Write - Automatically writes back the data. Valid values are On, the default, and Off.
Example
Implementing code (in EXECUTE method of the implemented class) for declining depreciation
Note
Before you can use a BADI in script logic, implement UJ_CUSTOM_LOGIC BADI from transaction SE19. See the ABAP online help at
http://help.sap.com/saphelp_nw70/helpdata/en/32/a83942424dac04e10000000a1550b0/content.htm
. for information on how to implement a BADI.
METHOD if_uj_custom_logic~execute.
DATA: ls_param TYPE ujk_s_script_logic_hashentry,
l_log TYPE string,
l_ast_acct(16) TYPE c,
l_year(3) TYPE n,
l_percentage(3) TYPE p,
PUBLIC
Page 42 of 102
lo_model TYPE REF TO if_uj_model,

lo_dim TYPE REF TO if_uja_dim_data,
ls_dim TYPE uja_s_dim,
time_dim(16) TYPE c,
lr_rec TYPE REF TO data,
lr_result_rec TYPE REF TO data,
l_intermediate_value TYPE uj_sdata,
lt_final TYPE REF TO data.
FIELD-SYMBOLS: <ls_rec> TYPE ANY,
<ls_result_rec> TYPE ANY,
<ls_time> TYPE ANY,
<ls_signed.data> TYPE ANY,
<lt_final> TYPE STANDARD TABLE
* Make sure all the parameters are passed.
CLEAR ls_param.
READ TABLE it_param WITH KEY hashkey = 'YEAR' INTO ls_param.
IF sy-subrc NE 0.
l_log = 'You have not specified the parameter ''YEAR'' which is required.'.
cl_ujk_logger=>log( i_object = l_log ).
RAISE EXCEPTION TYPE cx_uj_custom_logic.
EXIT.
ENDIF.
l_year = ls_param-hashvalue.
CLEAR ls_param.
READ TABLE it_param WITH KEY hashkey = 'PERCENTAGE' INTO ls_param.
IF sy-subrc NE 0.
l_log = 'You have not specified the parameter ''PERCENTAGE'' which is required.'.
cl_ujk_logger=>log( i_object = l_log ).
RAISE EXCEPTION TYPE cx_uj_custom_logic.
EXIT.
ENDIF.
l_percentage = ls_param-hashvalue.
* Get name of the account dim
cl_uj_model=>get_model( EXPORTING i_appset_id = i_appset_id
RECEIVING ro_model = lo_model ).
CALL METHOD lo_model->get_dim_data_by_type
EXPORTING
i_dim_type = uj00_cs_dim_type-time
i_appl_id
= i_appl_id
RECEIVING
ro_dim_data = lo_dim.
TRY.
CALL METHOD lo_dim->get_info
IMPORTING
es_dim_info = ls_dim.
ENDTRY.
time_dim = ls_dim-dimension. TRANSLATE time_dim TO UPPER CASE.
CREATE DATA lt_final LIKE ct_data.
ASSIGN lt_final->* TO <lt_final>. CREATE DATA lr_result_rec LIKE LINE OF ct_data. ASSIGN lr_result_rec->* TO
<ls_result_rec>. CREATE DATA lr_rec LIKE LINE OF ct_data. ASSIGN lr_rec->* TO <ls_rec>.
* Loop through incoming data and create a result set
LOOP AT ct_data ASSIGNING <ls_rec>.
<ls_result_rec> = <ls_rec>.
ASSIGN COMPONENT time_dim OF STRUCTURE <ls_result_rec> TO <ls_time>.
<ls_time>+0(4) = is <ls_time>+0(4) + l_year.
ASSIGN COMPONENT 'SIGNEDDATA' OF STRUCTURE <ls_result_rec> TO <ls_signeddata>.
DO l_year TIMES.
PUBLIC
Page 43 of 102
l_intermediate_value = l_intermediate_value + ( <ls_signeddata> - l_intermediate_value ) * l_percentage / 100.

ENDDO.
<ls_signeddata> = <ls_signeddata> - l_intermediate_value.
APPEND <ls_result_rec> TO <lt_final>.
ENDLOOP.
* Send the result data back.
Note
Planning and Consolidation always overwrites existing values.
ct_data = <lt_final>.
ENDMETHOD.
Script logic file content to call the BADI:
*START_BADI DECD
QUERY = ON
WRITE = ON
YEAR = 1
PERCENTAGE = 10 *END_BADI
Note
ET_MESSAGE in the BADI logs the messages to the Data Manager.
If you want to stop the execution, raise the cx_uj_custom_logic exception within a BADI implementation.
More Information
For instructions about creating an SAP Business Add-In, see the ABAP model help in the SAP NetWeaver Library.
1.5.2.2 Logic Keyword Reference

Use
This reference contains descriptions of all the logic keywords you can use.
More Information
*ADD / *ENDADD
*BEGIN / *END
*DESTINATION_APP
*FOR / *NEXT
*FUNCTION / *ENDFUNCTION
*INCLUDE
*REC
LOOKUP
*RUNALLOCATION
*SELECT
*SELECTCASE / *ENDSELECT
*SUB( ) / *ENDSUB
*WHEN / *ENDWHEN
*XDIM_MEMBERSET
*XDIM_ADDMEMBERSET
*XDIM_MAXMEMBERS
*XDIM_FILTER
*COMMIT
Special Keywords
TMVL Parameter
1.5.2.2.1 *ADD / *ENDADD

This structure allows you to automatically cumulate a set of members to a calculated member as specified in a comma delimited range. The range can be
dynamically derived using a *SELECT( ) instruction. See *SELECT.
The syntax is:
PUBLIC
Page 44 of 102
*ADD {variable} = {set}

{formula}
*ENDADD
Example
*ADD %ACC%=[CE0004010],[CE0004020],[CE0004030] [#CE0661000] = %ACC%/[CE0652000]
*ENDADD
*COMMIT
[#CE00661000] = [CE0661000]/[CE0652000]
The ADD statement expands into:
[P_ACCT].[#CE0661000]
=[P_ACCT].[CE0004010]/[P_ACCT].[CE0652000]+[P_ACCT].[CE0004020]/[P_ACCT].[CE0652000]+[P_ACCT].[CE0004030]/[P_ACC
T].[CE0652000]
Note
The expression to the right of the equals sign ( = ) currently does not support more complex expressions.
Only one formula can be written inside the ADD/ ENDADD structure.
1.5.2.2.2 *BEGIN / *END

The BEGIN/ END structure can be used to split long formulas across multiple lines to improve readability. The validation process trims and joins all lines between
the BEGIN and END statements.
Example
*BEGIN
[P_ACCT].[#CE0661000] =
[P_ACC].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[CE0004030] )
[P_ACCT].[CE0652000]
*END
1.5.2.2.3 *DESTINATION_APP
The DESTINATION_APP keyword allows you to write the results of calculations to a different model.
Syntax
*DESTINATION_APP = {app name}
Often, the destination model shares only some of the dimensions of the original model. In this case, the missing dimensions can be dropped from the original
records with the instruction:
*SKIP_DIM= {dimension name}[,{dimension name},]
When the original model has dimensions that are not found in the destination model, the SKIP_DIM keyword is mandatory. Validation cannot pass without the
SKIP_DIM keyword.
Multiple dimension names can be supplied to the instruction separated either by commas or by multiple SKIP_DIM instructions entered on separate lines.
If the destination model has dimensions that do not exist in the original model, these can be added to the passed records, using the instruction:
*ADD_DIM {dimension name}={value}[,{dimension name}={value} [, {dimension name} = {dimension name(source): Property
name}, #]
Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple ADD_DIM instructions entered on separate
lines. Dimension properties (dimension from the source model) are also supported.
Example:
To explain DESTINATION_APP with SKIP_DIM, ADD_DIM, and RENAME_DIM, another model DETAIL_PLAN is created by copying the PLANNING model from
the delivered EnvironmentShell. It is necessary to do the following steps:
Create new dimensions PRODUCT and MARKET and add these to the DETAIL_PLAN model
Replace P_ACCT with P_ACCTDETAIL
Remove the P_ACTIVITY dimension from the DETAIL_PLAN cube using the following syntax:
*XDIM_MEMBERSET TIME = 2006.AUG
*XDIM_MEMBERSET CATEGORY=ACTUAL
*DESTINATION_APP=DETAIL_PLAN
*SKIP_DIM = P_ACTIVITY
*ADD_DIM P_DATASRC=INPUT, MARKET = PRODUCT:MARKET
*RENAME_DIM P_ACCT=P_ACCTDETAIL
PUBLIC
Page 45 of 102
*WHEN CATEGORY
*IS "ACTUAL"
*REC(EXPRESSION=%VALUE%)
*ENDWHEN
Explanation: DETAIL_PLAN is the target model, which has all dimensions of PLANNING except for P_ACCT. This dimension is replaced with P_ACCTDETAIL.
Also, DETAIL_PLAN has two additional dimensions, namely P_DATASRC and MARKET. The above script logic moves the data into DETAIL_PLAN with:
P_DATASRC defined by the keyword INPUT
MARKET by using the value of the property 'MARKET' of the dimension PRODUCT, which must exist in the source model
The corresponding values of P_ACCT are copied to P_ACCTDETAIL
The keyword RENAME_DIM can be used, to change name of one or more dimensions. The syntax is:
*RENAME_DIM {dimension name}={value}[,{dimension name}={value},]
This instruction can be used when data is to be written into a model where a dimension is named with a different ID.
Multiple dimension names and values can be supplied to the instruction separated either by commas or by multiple RENAME_DIM instructions entered on
separate lines.
Any combination of the three keywords, above, is supported.
Examples
Example 1
Environment: EnvironmentShell_V
Model: PLANNING
In this example, EnvironmentShell_V is a copy of EnvironmentShell and COPY_PLANNING is a copy of the PLANNING model. You can execute the
script, shown in this example, in a PLANNING model to copy ACTUAL data to the COPY_PLAN model.
If the *DESTINATION_APP command appears once in the middle of the script, all remaining data writing of the script logic file occurs in the referenced
destination model. Any data writes before the *DESTINATION_APP are written in the model where the script is currently being run.
*DESTINATION_APP=COPY_PLANNING
*WHEN CATEGORY
*IS "ACTUAL"
*ENDWHEN
Example 2
To explain DESTINATION_APP with SKIP_DIM, ADD_DIM, and RENAME_DIM, another model DETAIL_PLAN is created by copying the PLANNING model from
the delivered EnvironmentShell. It is necessary to:
Create new dimensions PRODUCT and MARKET and add these to the DETAIL_PLAN model
Replace P_ACCT with P_ACCTDETAIL
Remove the P_ACTIVITY dimension from the DETAIL_PLAN cube
*DESTINATION_APP=DETAIL_PLAN
*SKIP_DIM = P_ACTIVITY
*ADD_DIM P_DATASRC=INPUT, PRODUCT = NO_PRODUCT, MARKET = NO_MARKET
*RENAME_DIM P_ACCT=P_ACCTDETAIL
*WHEN CATEGORY
*IS "ACTUAL"
*ENDWHEN
Explanation
DETAIL_PLAN is the target model, which has all dimensions of PLANNING except for P_ACCT. This dimension is replaced with P_ACCTDETAIL. Also,
DETAIL_PLAN has two additional dimensions, namely PRODUCT, and MARKET.
The above script logic moves the data into DETAIL_PLAN with:
Blank data in the PRODUCT and MARKET dimensions
P_DATASRC defined by the keyword INPUT
corresponding values of P_ACCT copied to P_ACCTDETAIL
1.5.2.2.4 *FOR / *NEXT

*FOR / *NEXT is used to repeat certain scripts written between a FOR and an immediate NEXT for a set of members. Sets of members can be provided either
directly in the FOR statement or through variables.
PUBLIC
Page 46 of 102
The Logic Module supports any number of FOR NEXT loops in the body of the logic files. The syntax is the following:
*FOR {variable1} = {set1} [ AND {variable2={set2}]
{text}
{text}
*NEXT
Example
In a logic file, you may need to repeat some calculation for a set of entities. This works automatically when you write:
*XDIM_MEMBERSET TIME = 2006.JAN
*XDIM_MEMBERSET CATEGORY = Q1FCST_LOAD
*FOR %Q1% = 2006.JAN, 2006.FEB, 2006.MAR
*RUNALLOCATION
*FACTOR=1/3
*DIM TIME WHAT = 2009.JAN; WHERE = %Q1%;
*DIM CATEGORY WHAT=Q1FCST_LOAD; WHERE=FQ1;
*ENDALLOCATION
*NEXT
Assuming the forecast data for Q1 is loaded in 2006.JAN, the above script allocates this data into each period in Q1 equally.
Note
Only one variable is allowed per *FOR statement.
1.5.2.2.5 *FUNCTION / *ENDFUNCTION

A user-defined function is the name of a placeholder that a user can insert in formulas in place of a corresponding MDX statement or part of one. This can greatly
improve the readability of a logic statement.
The definitions of the logic functions can be inserted anywhere in a logic file or in an included file. Their syntax is the following:
For single line functions
*FUNCTION {functionname}({Param1}[,{Param2}]) = {Function Text}
For multi-line functions
*FUNCTION {functionname}({Param1}[,{Param2}])
{Function text}
{Function text}
*ENDFUNCTION
An unlimited number of functions can be defined within a script logic file.
An unlimited number of parameters can be passed to a function to dynamically modify the corresponding MDX string.
Functions currently cannot be nested, meaning a function cannot contain another function.
The position of the functions in the logic file is irrelevant, unless the same function is redefined, in which case the new definition of the function applies only from
the point of the redefinition.
The values of the passed parameters are replaced in the function text without any validation, even if they are embedded in longer words, like in the following
example:
Use caution when defining the names of the parameters to avoid the risk of conflicts with MDX reserved words and with the text surrounding them in logic. The
best practice is to always surround the name of the parameters with a delimiter, as in the following example:
Example
*FUNCTION Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION[#CE0661000] = Price([CE0004000],[CE0652000])
The example calculates the Price. You do not have to check the denominator for Zero to avoid divide-by-zero error. The Script Logic engine automatically replaces
the divide by zero error with zero.
You can also use *FUNCTION to substitute members or dimensions to make scripts more readable.
*FUNCTION PERSONAL_COST = CE0004000
*FUNCTION LAB_HOUR = CE0652000
*FUNCTION PER_PRICE = CE0661000
*FUNCTION ACCOUNT = P_ACCT
Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION
PUBLIC
Page 47 of 102
[ACCOUNT].[#PER_PRICE] = Price([ACCOUNT].[PERSONAL_COST],[ACCOUNT].[LAB_HOUR])
The following characters, plus the blank character, are invalid in logic functions names:
+ - / * ^ % > < = ( ) [ ] {}, .;' :& \ | # ~ "
1.5.2.2.6 *INCLUDE
Multiple files can be combined into one logic file by the use of the instruction INCLUDE. During the LGX generation of the script logic execution step, the
statements in the INCLUDE file are combined with the main file.
Example
*INCLUDE FUNCTION_DEFINITIONS.LGF
[ACCOUNT].[#PER_PRICE] =
Price([ACCOUNT].[PERSONAL_COST],[ACCOUNT].[LAB_HOUR])
A FUNCTION_DEFINITIONS.LGF file can include all definitions:
*FUNCTION PERSONAL_COST = CE0004000
*FUNCTION LAB_HOUR = CE0652000
*FUNCTION PER_PRICE = CE0661000
*FUNCTION ACCOUNT = P_ACCT
Price(%COST%,%HOUR%)
%COST%/%HOUR%
*ENDFUNCTION
1.5.2.2.7 *REC
The *REC( ) instruction tells the program what to do once the specified criteria has been met. Each REC instruction generates one new record to post to the
database. Each source record can generate as many records as desired, even pointing to the same destination cell.
The parameters of the REC( ) function specify what to modify of the original record. Any dimension member can be modified using the following syntax:
{DimensionName}={member}
Example
*XDIM_MEMBERSET P_ACCT = CE0004010
*WHEN CATEGORY
*IS ACTUAL *REC(FACTOR = 1.1, CATEGORY="FORECAST")
*ENDWHEN
The {member} must be enclosed in double quotes and can contain the name of any dimension enclosed between percent signs (for example:
ENTITY="IC_%ENTITY%"). In this case, the dimension name is replaced with the value of the current member for that dimension, and not with just the
dimension name.
You can use property values in WHEN statement.
Example
*XDIM_MEMBERSET CATEGORY = PLAN
*WHEN TIME.YEAR
*IS "2007"
*REC(FACTOR = 1.1, CATEGORY="FORECAST")
*ENDWHEN
The above script copies the 2007 plan data to Forecast. You can also read property values and assign them to dimensions.
Example
*XDIM_MEMBERSET P_ACCT = CE0004010,CE0652000
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=([P_ACCT].[CE0004010],[P_ACTIVITY].[NONE])/([P_ACCT].[CE0652000],[P_ACTIVITY].[LABPRD]),
RPTCURRENCY=[ENTITY].CURRENCY, P_ACCT=CE0661000)
*ENDWHEN
Restrictions For Using the REC Instruction
You cannot use other MDX keywords (such as PARENT and DESCENDANTS) in FACTOR or EXPRESSION instructions. The only permitted operations are
addition (+), subtraction (-), multiplication (*), and division (/), combinations of these operators, and parenthesis for tuple and priorities of the operations.
You cannot use the GET() function to refer to another source value. The MDX tuple format acts as a GET function.
You cannot use NOADD or FLD functions within REC.
Dynamic properties such as HLEVEL, PARENTHn are not supported in the REC statement.
PUBLIC
Page 48 of 102
REC always needs to be accompanied by WHEN / IS / ENDWHEN. Stand-alone REC statements do not have any effect.
You cannot use SIGNEDDATA or any measure name in a WHEN statement to write a condition on a measure value.
WHEN / IS / REC / ENDWHEN cannot be used in SELECTCASE / ENDSELECT.
Using Multiple REC Statements
You can write multiple REC statements within one WHEN/ IS/ ENDWHEN statement.
Syntax
*WHEN {dim}
* IS {condition_value}
*REC({FACTOR or EXPRESSION instruction},dim=)
*ENDWHEN
Example
*XDIM_MEMBERSET TIME = 2006.AUG,2006.SEP
*XDIM_MEMBERSET P_ACCT=CE0004010
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/1.5098, RPTCURRENCY="EUR")
*REC(EXPRESSION=%VALUE%/1.0666, RPTCURRENCY="CAD")
*REC(EXPRESSION=%VALUE%/1.9183, RPTCURRENCY="GBP")
*ENDWHEN
The script shown above creates EUR, CAD, and GBP posts in the cube.
Referring To Another Source Value Within A FACTOR/EXPRESSION Instruction
You can assign a source value from the scoped data for a FACTOR or EXPRESSION instruction to calculate a new value inside a *REC( ) statement. To refer to
another source value, you must use fully qualified MDX formatting, including an Account dimension.
Note
You have the ability to use implicit Account members in direct MDX statements within script logic.
Syntax
*WHEN {dim}
* IS {condition_value}
*ENDWHEN
Example
Environment: EnvironmentShell_V (Copy of EnvironmentShell)
Application: Planning
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/[P_ACCT].[CE0004020], P_ACCT="CE0661000")
*ENDWHEN
You can use tuples as well.
Example
Environment: EnvironmentShell_V (Copy of EnvironmentShell)
Application: Planning
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/([P_ACCT].[CE0652000],[P_ACTIVITY].[LABPRD]), P_ACCT="CE0661000")
*ENDWHEN
PUBLIC
Page 49 of 102
1.5.2.2.8 LOOKUP
Referring to Another Source Value Using the LOOKUP Function
To calculate a new value inside a *REC( ) statement, you can use the LOOKUP function to assign a source value that is outside the scoped data for a FACTOR
or an EXPRESSION instruction.
Syntax
*LOOKUP {Model}
*DIM [{LookupID}:]{DimensionName}="Value" | {CallingDimensionName}[.{Property}]
*DIM MEASURES="MeasureName"
*ENDLOOKUP
Example
In the following example, you are reading RATE information and using it in the calculation. You can also use FOR/NEXT to look up multiple values.
Environment: EnvironmentShell_V (Copy of the EnvironmentShell sample environment)
Model: Planning
*LOOKUP RATE
*DIM TIME="2006.AUG"
*DIM CATEGORY="ACTUAL"
*DIM R_ACCT="AVG"
*DIM R_ENTITY="GLOBAL"
*DIM RATEEUR:INPUTCURRENCY="EUR"
*DIM MEASURES="PERIODIC"
*ENDLOOKUP
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/LOOKUP(RATEEUR), RPTCURRENCY="EUR")
*ENDWHEN
Example
In the following example, you are first reading all reporting currencies in the *SELECT statement and assigning the values to variable %CUR%. Using
FOR/NEXT, you read their rates from RATE model. Then, you use them in the calculation.
Values in the models before the execution of the script:
PLANNING model data:
TIME
P_ACCT
ENTITY
P_ACTIVITY
CATEGORY
Currency
P_DATASRC
SignData
2006.AUG
CE0004010
C9000
NONE
ACTUAL
LC
UPLOAD
157,915.81
Rate model data:

Category
InputCurrency
R_ACCT
R_ENTITY
TIME
SignData
ACTUAL
EUR
AVG
GLOBAL
2006.AUG
1.5022
ACTUAL
USD
AVG
GLOBAL
2006.SEP
1.0000
*XDIM_MEMBERSET TIME=2006.AUG
*SELECT(%CUR%, "[ID]", RPTCURRENCY, "[REPORTING]=Y")
*LOOKUP RATE
*DIM R_ACCT="AVG"
*DIM TIME="2006.AUG"
*FOR %LOOP_CUR%=%CUR%
*DIM C_%LOOP_CUR%:INPUTCURRENCY="%LOOP_CUR%"
*NEXT
PUBLIC
Page 50 of 102
*ENDLOOKUP
*WHEN P_ACCT
*IS "CE0004010"
*FOR %LOOP_CUR%=%CUR%
*REC(EXPRESSION=%VALUE%/LOOKUP(C_%LOOP_CUR%), RPTCURRENCY=%LOOP_CUR%)
*NEXT
*ENDWHEN
Values in the model after the execution of the script:
2006.AUG
CE0004010
C9000
NONE
ACTUAL
EUR
UPLOAD
105,123.03
2006.SEP
CE0004010
C9000
NONE
ACTUAL
USD
UPLOAD
157,915.81
You can also pass property values to scope members to look up data.
Example
In this example, the corresponding Entity's currency is read from master data and this is used to look up the rate value.
*XDIM_MEMBERSET ENTITY=C9000
*LOOKUP RATE *DIM TIME="2006.AUG"
*DIM R_ACCT="AVG"
*DIM RATE:INPUTCURRENCY=ENTITY.CURRENCY
*ENDLOOKUP
*WHEN P_ACCT
*IS "CE0004010"
*REC(EXPRESSION=%VALUE%/LOOKUP(RATE), RPTCURRENCY=ENTITY.CURRENCY)
*ENDWHEN
Restriction
Reading multiple measures within a single LOOKUP by assigning different lookup IDs is not supported.
1.5.2.2.9 *RUNALLOCATION
Allocation helps distribute data from a source region to a target region using the specified driver.
Syntax
*RUNALLOCATION
*FACTOR=<driver>
*DIM P_ACCT WHAT=<soure>; WHERE=<target>; USING=<distribution key>; [TOTAL=<distribution key>]
*DIM <other dimensions>
*ENDALLOCATION
WHAT (Source)
The source value represents the range of data values to be allocated by the allocation function. This value is qualified by one or several tuples in the model.
Possible WHAT options are:
Options
Descriptions
Example
Member
A specified dimension base member.
*DIM Region WHAT = US
[property]="property value"
A filter to select dimension members based on a specified

property and a given value for that property.
*DIM Product_Group = [Fruit] = "apples"
BAS
All leaf level members of a specific dimension parent

member
*DIM Product_Group = BAS(TotalProduct)
same as WHERE
Use the same members defined in the WHERE parameter
*DIM Account WHERE = Rent
for the specified dimension
*DIM Account WHAT = Rent
The <> operand references all members not equal to a
*DIM Region USING <> Corp
<> member
defined member.
In the <>member mode, the member should be base
member in the dimension.
If the <> is used, all other base members in that
dimension should be included in the region.
PUBLIC
Page 51 of 102
Restriction of WHAT
You cannot use blank or [ALL] in WHAT condition.
You cannot use non-base members with <>.
USING and TOTAL (Distribution key)
The basis of the allocation is the definition of a portion or complete source value to be allocated. The method of defining the basis is the use of a factor. A factor can
be the value or values that can be multiplied or divided to derive a value (added or subtracted potential future support).
A factor can also derive values based on a defined region of data referred as using, or the basis region.
Possible USING and TOTAL options are:
Options
Descriptions
Example
Member
*DIM Region USING = US
BAS

member
same as WHERE
Use the same members defined in the WHERE parameter
for the specified dimension. The same dimension must be *DIM Account USING = PercentAcct
for both WHERE and USING.
Note
WHERE only supports a single member reference.
<> member
The <> operand references all members not equal to a
*DIM Region USING <> Corp
defined member.
In the <>member mode, the member should be base
member in the dimension.
If the <> is used, all other base members in that
dimension should be included in the region.

Restriction of USING
You cannot use >0. For example, USING = Amount >0 is not supported.
USING and TOTAL must have the same definition.
You cannot use non-base members with <>.
You cannot use parent member directly in USING. BAS(parent) is still allowed as described above.
FACTOR (Driver)
FACTOR can be used to define any arithmetic expression, written in the {expression} parameter, and can contain operands, parentheses, constants, and one or
both of the keywords USING and TOTAL, representing respectively the amount coming from the USING region, the amount of the driver, and the amount coming
from the TOTAL region, the sum of the drivers.
If FACTOR is omitted, the FACTOR defaults to 1.
If the arithmetic expression is omitted, the default is multiplication.
Possible FACTOR options are:
Options
Descriptions
Example
.8
Only a fixed amount is to be applied to the source value for Tuple value of the WHAT is 10 for product A
allocation.
10*.8 = 8
USING
The value of the USING region defined is used as the basis Tuple value of the WHAT is 10 for product A, tuple value of
of the allocation. This provides the ability to change values the USING is .8
without having to edit the definition of the allocation.
10*.8 = 8
-1 * USING/100
Or
1 * USING/100
Calculation takes the defined region as USING, and
Tuple value of the USING region is 70 for product A.
reverses the value (negative), then divides the value by

100.
-70/100 = -.7
(-70%) (1-70)/100 = -.69 (-69%)
Note
This is used with driver accounts not reporting values.
USING/TOTAL
Calculation takes the region defined as USING, and
Tuple value of USING region is 70 for product A. The total
divides the total value for the region defined as TOTAL.
of the TOTAL region (tuples) is 700, assuming that the

using region is for all regions not just US.
70/700 = .1 (10%)
Basic Mathematical expression with USING & TOTAL

(For example, 1 + USING, USING -1 , and 1 - USING)
Calculation takes the region defined as USING, and does
Tuple value of the USING region is 70 for product A.
the necessary mathematical operations with the total value 1+70 = 71

for the region defined as TOTAL.
70 -1 = 69
1-70 = -69
Restriction of FACTOR
You cannot use any script logic keywords in FACTOR expression.
WHERE (Target)
The target identifies the tuples to which the values should be allocated. It represents dimension member combinations to which the values should be distributed.
The target identifies the dimension for which the value of the members is modified as compared to the source, and only explicitly mentioned and characterized
dimension should be modified.
PUBLIC
Page 52 of 102
The keyword WHERE is used in combination with the keyword *DIM to identify the target dimension members (the values to be modified against the source).
Possible WHERE options are:
Options
Descriptions
Example
Member
*DIM Region WHERE = US
BAS
member
same as WHAT
Use the same members defined in the WHAT parameter for *DIM Account WHAT = Rent
blank or [All]
the specified dimension
The ability to assume all base members for given

dimensions either via a blank parameter or [ALL] key
word
*DIM Entity =

*DIM IntCo = [ALL]
Common Restriction
*APP (ability to write in different model if needed), COUNT and LIST keywords inside RUNALLOCATION or any other options not mentioned above are not
supported.
Examples
Example 1
The account RENT is entered in entity GLOBALOPS, inter-company NON_INTERCO. This amount must be allocated using a percentage of allocation that is entered
by the user in account PERCENT in the appropriate entities and for the desired members of the CATEGORY, TIME, DATASRC, and RPTCURRENCY dimensions.
This allocation demonstrates the following features:
It uses the {dimensiontype}DIM keyword to identify the dimensions by type
It uses the <<< and >>> keywords to reference the definitions used to the left or to the right
Before Allocation
Source Account ( RENT) data:
RENT CHINA
China
RENT JAPAN
Japan
RENT INDIA
India
RENT ASAREST
Rest of Asia
RENT ASA
Asia
50,000,000.00
PERCENT CHINA
China
10.00
PERCENT JAPAN
Japan
32.00
PERCENT INDIA
India
8.00
PERCENT ASAREST
Rest of Asia
50.00
Driver (Percent Account) data:
*XDIM_MEMBERSET TIME=2006.SEP
*XDIM_MEMBERSET P_ACCT=RENT,PERCENT
*XDIM_MEMBERSET ENTITY=ASA,INDIA,CHINA,JAPAN,ASAREST
*RUNALLOCATION
*FACTOR=USING/100
*DIM P_ACCT WHAT=RENT; WHERE=<<<; USING=PERCENT
*DIM ENTITY WHAT=ASA; WHERE=INDIA,CHINA,JAPAN,ASAREST; USING=<<<
*ENDALLOCATION
After Allocation
RENT CHINA
China
5,000,000.00
RENT JAPAN
Japan
16,000,000.00
RENT INDIA
India
4,000,000.00
RENT ASAREST
Rest of Asia
25,000,000.00
RENT ASA
Asia
50,000,000.00
Example 2
The account RENT is entered in entity GLOBALOPS, inter-company NON_INTERCO. This amount must be allocated on the basis of the square meters of rented
space used by all European entities.
Allocation uses historical rent as the driver
It uses the BAS( ) keyword to build a list of members
Before Allocation
Below is the history data shown for the 2008.JAN period. Asia is the parent node.
PUBLIC
Page 53 of 102
Entity
CATEGORY
Asia all
ACTUAL
2008.JAN
Asia
ACTUAL
China
ACTUAL
1,500.00
Japan
ACTUAL
7,000.00
India
ACTUAL
500.00
Rest of Asia
ACTUAL
5,000.00
Planning Asia
ACTUAL
Source Account ( RENT) data:

To allocate 50,000 to base countries
This input can be received in the Planning Asia entity
Driver data:
The historical data is the Driver
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
TIME=2008.JAN,2009.JAN
P_ACCT=RENT
CATEGORY=ACTUAL,PLAN
ENTITY=ASA,BAS(RASA)
//Create total rent data to be allocated.

*WHEN ENTITY
*IS "ASA"
*REC (EXPRESSION=50000,TIME=2009.JAN,CATEGORY=PLAN)
*ENDWHEN
*COMMIT
//Allocate to base countries.

*RUNALLOCATION
*FACTOR=USING/TOTAL
*DIM P_ACCT WHAT=RENT; WHERE=<<<; USING=<<<; TOTAL=<<<
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<< TOTAL=<<<
*DIM TIME WHAT=>>>; WHERE=2009.JAN; USING=2008.JAN; TOTAL=<<<
*DIM CATEGORY WHAT=>>>; WHERE=PLAN; USING=ACTUAL; TOTAL=<<<
*ENDALLOCATION
//Clear the total rent account.

*WHEN ENTITY
*IS "ASA"
*REC (EXPRESSION=0,TIME=2009.JAN,CATEGORY=PLAN)
*ENDWHEN
After Allocation
Entity
CATEGORY
2009.JAN
Asia all
PLAN
50,000.00
Asia
PLAN
50,000.00
China
PLAN
7,500.00
Japan
PLAN
35,000.00
India
PLAN
2,500.00
Rest of Asia
PLAN
5,000.00
Planning Asia
PLAN
2009.JAN is posted with rents for individual countries based upon their historical share.
Example 3
The sum of all ADVERTISING expenses incurred by all European operations must be reallocated to each European operation based on their external SALES.
It uses the DOT({type}) keyword to identify the dimensions by type
It demonstrates the ability to perform aggregations in the WHAT region ( SALESEUROPE and ALL_INTCO are parent members)
It shows a many-to-one redirection of a dimension (it reads the sum of the Inter-company members and writes it in the NON_INTERCO member of the INTCO
dimension)
It shows a one-to-one redirection of a dimension (it reads the INPUT member and writes the results in the ALLOCATED member of the DATASRC dimension)
Before Allocation
Source data - History data for External Sales:
PUBLIC
Page 54 of 102
Actual - Periodic
2008.JAN
Planning Asia
China
500,000
Japan
600,000
India
200,000
Rest of Asia
800,000
Asia
2,100,000
Asia all
2,100,000
Data to be allocated ( ADVERTISING):

Plan - Periodic
2009.JAN
Planning Asia
500,000
China
Japan
India
Rest of Asia
Asia
Asia all
500,000
Factor: USING/TOTAL
APP or (Dim) or VALUE
WHAT
WHERE
USING
TOTAL
DOT(A)
ADVERTISING
<<<
EXTSALES
<<<
DOT(E)
SALESEUROPE
BAS(SALESEUROPE)
<<<
<<<
DOT(I)
ALL_INTERCO
NON_INTERCO
>>>
BAS(ALL_INTERCO)
DATASRC
INPUT
ALLOCATED
INPUT
<<<
*RUNALLOCATION
*FACTOR =USING/TOTAL
*DIM P_ACCT WHAT=ADVERTISING; WHERE=<<<; USING=EXTSALES; TOTAL=<<<
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<<; TOTAL=<<<
*DIM INTERCO WHAT=WORLD_INTERCO; WHERE=I_NONE; USING=>>>; TOTAL=BAS(World_InterCo)
*DIM P_DATASRC WHAT=MANUAL; WHERE=ALLOCATED; USING=MANUAL; TOTAL=<<<
*DIM TIME WHAT=2009.JAN; WHERE=2009.JAN; USING=2008.JAN; TOTAL=<<<
*ENDALLOCATION
After Allocation
Plan - Periodic
2009.JAN
Planning Asia
China
119,048
Japan
142,857
India
47,619
Rest of Asia
190,476
Asia
500,000
Asia all
500,000
Example 4
This example implements the same scenario as example 3, but using a system variable for year. (%YEAR%). This returns current calendar year. Assume that
the script is for year 2009.
Before Allocation
Source data - History data for External Sales:
Actual - Periodic
2008.JAN
Planning Asia
China
500,000
Japan
600,000
India
200,000
Rest of Asia
800,000
Asia
2,100,000
Asia all
2,100,000
PUBLIC
Page 55 of 102
Data to be allocated ( ADVERTISING):

Plan - Periodic
2009.JAN
Planning Asia
500,000
China
Japan
India
Rest of Asia
Asia
Asia all
500,000
Factor: USING/TOTAL
WHAT
WHERE
USING
TOTAL
DOT(A)
ADVERTISING
<<<
EXTSALES
<<<
DOT(E)
SALESEUROPE
BAS(SALESEUROPE)
<<<
<<<
DOT(I)
ALL_INTERCO
NON_INTERCO
>>>
BAS(ALL_INTERCO)
DATASRC
INPUT
ALLOCATED
INPUT
<<<
*RUNALLOCATION
*FACTOR =USING/TOTAL
*DIM P_ACCT WHAT=ADVERTISING; WHERE=<<<; USING=EXTSALES; TOTAL=<<<
*DIM ENTITY WHAT=ASA; WHERE=BAS(RASA); USING=<<<; TOTAL=<<<
*DIM INTERCO WHAT=WORLD_INTERCO; WHERE=I_NONE; USING=>>>; TOTAL=BAS(World_InterCo)
*DIM P_DATASRC WHAT=MANUAL; WHERE=ALLOCATED; USING=MANUAL; TOTAL=<<<
*DIM TIME WHAT=%YEAR%.JAN; WHERE=%YEAR%.JAN; USING=%YEAR%(-1).JAN; TOTAL=<<<
*ENDALLOCATION
After Allocation
Plan - Periodic
2009.JAN
Planning Asia
China
119,048
Japan
142,857
India
47,619
Rest of Asia
190,476
Asia
500,000
Asia all
500,000
Example 5
All accounts in the profit and loss of category ACTUAL, for the three entities ITALY, FRANCE and UK, are copied into the corresponding accounts of the entity
GLOBALOPS for category BUDGET. This allocation is basically an example of a simple copy action, which does not use FACTOR at all. In this example the engine
performs a one-to-one copy ( ACTUAL into BUDGET) and a many-to-one copy ( ITALY, FRANCE and UK are added up and copied into GLOBALOPS).
Before Allocation
Actual - Periodic
2007.DEC
UK (Great Britain)
30,000
Italy
10,000
France
10,000
Budget - Periodic
2008.FEB
Global Operations
Factor:
WHAT
WHERE
ACCOUNT
[GROUP] = "profit & loss"
<<<
CATEGORY
ACTUAL
BUDGET
ENTITY
SALESITALY; SALESFRANCE; SALESUK
GLOBALOPS
DOT(R)
LC
<<<
A property not supported in ALLOCATION replaces a property with variable using a select statement. Ensure that the *SELECT statement selects only base
members.
*XDIM_MEMBERSET ACCOUNT=ADVERTISING,EXTSALES
PUBLIC
Page 56 of 102
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*XDIM_MEMBERSET
*SELECT(%ACCT%,
ENTITY=UK,ITALY,FRANCE,GLOBAL
P_DATASRC = INPUT
TIME = 2007.DEC,2008.JAN
CATEGORY = ACTUAL,BUDGET
INTCO= I_NONE
RPTCURRENCY = LC
"[ID]",ACCOUNT,"[CALC]='N'","[GROUP]='PL'")
*RUNALLOCATION
*FACTOR=
*DIM ACCOUNT WHAT=[GROUP]="PL" AND [CALC]="N"; WHERE=<<<
*DIM CATEGORY WHAT=ACTUAL; WHERE=BUDGET
*DIM ENTITY WHAT=UK,ITALY,FRANCE; WHERE=GLOBAL
*DIM DOT(R) WHAT=LC; WHERE=<<<
*DIM TIME WHAT=2007.DEC; WHERE=2008.FEB
*ENDALLOCATION
After Allocation
Budget - Periodic
2008.FEB
Global Operations
50,000
1.5.2.2.10 *SELECT
The special instruction *SELECT allows the user to retrieve a list of elements from a dimension and save it in a user-defined variable for use somewhere else in
the logic.
*SELECT ({variable}, {[What]}, {From dimension}, {Where})
Example
With the following instruction, the user can retrieve the ID of all members in the CURRENCY dimension where the property CURRENCY TYPE has the value R.
*SELECT(%CURRSET%, "[ID]", RPTCURRENCY, "[REPORTING]='Y'")*XDIM_MEMBERSET RPTCURRENCY = %CURRSET%
The *SELECT statement fills the variable %CURRSET% with the list of reporting currencies defined in the current model. The content of the resulting variable is
then used in the XDIM_MEMBERSET statment.
The SELECT instruction is not specific to a given logic section, but it can be written once anywhere in the logic and used across multiple commit sections.
The SELECT statement is fairly limited, as it only supports the equal sign (=) , not equal to (<>) and cannot be used to combine multiple filter criteria with AND or
OR keywords.
1.5.2.2.11 *SELECTCASE / *ENDSELECT

To write formulas containing several nested IIF( ) statements, use the following syntax:
*SELECTCASE {expression}
*CASE {value1}[,{value2},]
{formulas}
[*CASE {value1}[,{value2},]
{formulas}
[*CASEELSE]
{formulas}
*ENDSELECT
where
{expression} is the condition to be evaluated
{value1},.. is the range of comma-delimited results that satisfy the condition for the current case
With such a structure, the readability of a logic statement can be significantly improved.
Example
*BEGIN
#A = IIF([ACCOUNT].[E]=1 OR [ACCOUNT].[E]=2,X+Y,
IIF([ACCOUNT].[E]=3 OR [ACCOUNT].[E]=4,X-Y,X*Y))
*END
#C = IIF([ACCOUNT].[E]=1 OR [ACCOUNT].[E]=2,W+Z,null)
#B = IIF([ACCOUNT].[E]=3 OR [ACCOUNT].[E]=4,W*Z,null)
The following formulas could be written as follows:
*SELECTCASE [ACCOUNT].[E]
PUBLIC
Page 57 of 102
*CASE 1,2
#A=X+Y
#C=W+Z
*CASE 3,4
#A=X-Y
#B=W*Z
*CASEELSE
#A=X*Y
*ENDSELECT
Note
SELECTCASE structures currently CANNOT be nested.
1.5.2.2.12 *SUB( ) / *ENDSUB

A SUB structure allows the user to define reusable logic sections anywhere in the body of the logic to make the logic easier to read and maintain.
A *SUB( ) structure is declared like a multi-line *FUNCTION( ) structure with the following syntax:
*SUB {SubName}({Param1,[,{Param2}])
{body text}
{body text}
{body text}
[]
*ENDSUB
When a SUB is then used somewhere else in the logic, its body lines are inserted in the logic with all the values passed to its parameters appropriately replaced.
A SUB behaves similarly to included files, to which any number of parameters can be passed. When the logic is validated, the subs are inserted in the body of
the logic as if they were included with an *INCLUDE instruction. However, to use a SUB structure, no special keyword is required. A SUB is called by inserting a
line with the name of the SUB, followed by the values assigned to its parameter enclosed in brackets. The other important difference from included files is that a
SUB does not need to be written in a file of its own, but can be written in any part of the logic, more similarly to a FUNCTION.
Example
Here the sub is defined:
*SUB MYSUB(Param1,Param2,Param3,Param4)
[%ACCOUNT_DIM%].[#Param1]=[%ACCOUNT_DIM%].[Param2]+[%ACCOUNT_DIM%].[Param3]
[%ACCOUNT_DIM%].[#Param4]=[%ACCOUNT_DIM%].[#Param1]*[%ACCOUNT_DIM%].[Factor_Param4]
*ENDSUB
Here the sub is used:
MySub(A1,B1,C1,D1)
MySub(A2,B2,C2,D2)
MySub(A3,B3,C3,D3)
Similarly to a FUNCTION, a SUB is not position sensitive, and can be defined anywhere in a logic, as well as, if so desired, stored in separate library files that
must then be merged with the logic using an INCLUDE instruction.
A SUB can be used in any commit section of the logic without the need to be redefined in each section. However, if a SUB is redefined in a logic file, its new
definition applies to all lines following the redefinition.
A SUB without parameters is supported, but they must always be followed by brackets.
1.5.2.2.13 *WHEN / *ENDWHEN

See also *REC.
A WHEN / ENDWHEN structure works in the same way as the SELECTCASE / ENDSELECT structure, with *REC( ) statements that generate new records. The
syntax is the following:
*WHEN {criteria}
*IS [=]{value1}[,{value2},] | <>{value}
*REC(FACTOR={Real number}|EXPRESSION={Expression}[,{dim1}={member},{dim2}=])
[ *REC(FACTOR={Real number}|EXPRESSION={Expression}[,{dim1}={member},{dim2}=])]
[*ELSE]
*ENDWHEN
where
{criteria} is what to test. Typically, this is a property of the current member of a dimension. The syntax is DimensionName.Property |
DimensionName, such as *WHEN ACCOUNT.RATETYPE. If Property is not specified, the ID property is assumed. For example, *WHEN ACCOUNT equals
to *WHEN ACCOUNT.ID.
PUBLIC
Page 58 of 102
{ValidCondition} is one or more values that meet the criteria. You can enclose them in double quotes to treat them as strings. Omit the quotes if they
represent numeric values. For example:
*IS "AVG","END"
*IS 10,20,30
If no operator is specified, the *IS clause assumes the presence of an equal sign (*IS = "AVG", "END").
The {value} must be literals only, not variables. Therefore, the following sample is not supported:
*IS dimension.property
Note
There should be no space between the two characters of the unequal sign operator (<>). You can insert one or more blanks between the operators and the
value.
If an unequal sign (<>) is used, you can pass only one value. Therefore, the syntax *IS <> 2,3,4 is invalid.
Other relational operators like AND, OR and NOT are not currently supported.
Nesting of WHEN / ENDWHEN
WHEN / ENDWHEN structures can be nested by as many levels as desired and in any sequence, as shown in the following sample:
*WHEN xxx
*IS "A"
*REC()
*REC()
*IS "B"
*REC()
*WHEN yyy
*IS "C","D","E"
*REC()
*ELSE
*REC()
*ENDWHEN
*ENDWHEN
1.5.2.2.14 *XDIM_MEMBERSET
*XDIM_MEMBERSET defines the scope of the data in which subsequent business logic will be applied.
Syntax
*XDIM_MEMBERSET {Dimension name} = {Members Set}
* XDIM_MEMBERSET {Dimension}<>{MemberSet}
Example
*XDIM_MEMBERSET TIME = 2006.DEC
*XDIM_MEMBERSET P_ACCT = bas(CE0004000)
[TIME].[#2009.DEC] = [TIME].[2006.DEC] * 1.1
*COMMIT
This example first reads all children of CE0004000 in the 2006.DEC period, increases them by 10%, and then copies them to the 2009.DEC period.
Other valid use cases:
*XDIM_MEMBERSET P_ACCT = CE0004010, CE0004020, CE0004030
*XDIM_MEMBERSET P_ACCT = CE0004000, where all children values are summarized to one parent record.
*XDIM_MEMBERSET P_ACCT = BAS(CE0004010, CE0004210) The scope is defined by the base members of both CE0004010 and CE0004210. The
string inside the parentheses () can also be replaced by a variable defined in the Data Manager prompt.
*XDIM_MEMBERSET P_ACCT = DEP(CE0004010) All direct children of CE0004010.
*XDIM_MEMBERSET P_ACCT = ALL(CE0004010) All children of CE0004010.
*XDIM_MEMBERSET P_ACCT <> CE0004010
You cannot combine bas() with any other member set.
*XDIM_MEMBERSET P_ACCT = bas(CE0004000), CE0004210 This is not a valid use case.
Use *XDIM_ADDMEMBERSET to add more members to the scope of the member set defined by bas().
Forcing a dimension to read all members without member formulas
Using the <ALL> keyword, you can force a dimension to read all base members without member formulas.
Example
*XDIM_MEMBERSET P_ACCT = <ALL>
*XDIM_MEMBERSET TIME = 2006.DEC
PUBLIC
Page 59 of 102
[P_ACCT].[#CE0661000] = [P_ACCT].[CE0004000] / [P_ACCT].[CE0652000]
1.5.2.2.15 *XDIM_ADDMEMBERSET
With the keyword XDIM_ADDMEMBERSET, the logic can merge a specific set of members with the members passed in the region for which the logic should be
executed. This instruction is similar to the instruction *XDIM_MEMBERSET. The difference is that, while XDIM_MEMBERSET redefines the region passed by the
user, XDIM_ADDMEMBERSET adds the defined set to the passed region.
*XDIM_ADDMEMBERSET {dimension} = {members set}
Example
*XDIM_MEMBERSET P_ACCT = bas(CE0004000)
*XDIM_ADDMEMBERSET P_ACCT = CE0004210
[TIME].[#2009.DEC] = [TIME].[2006.DEC] * 1.1
*COMMIT
In the above example, CE0004210 is scoped along with all children of CE0004000.
1.5.2.2.16 *XDIM_MAXMEMBERS
When the number of records being processed is too large, performance can deteriorate significantly. Also, processing too much data in the memory will slow down
the system for other uses and eventually run out of memory. For example, an TSV_TNEW_PAGE_ALLOC_FAILED ABAP dump can occur even with high Roll
memory settings. In this case, you can break the action into multiple packets and execute them sequentially using the following syntax:
*XDIM_MAXMEMBERS {dimension} = {max number of members}
Example
*XDIM_MEMBERSET TIME = 2009.JAN
*XDIM_MEMBERSET CATEGORY = FCST_LOAD
*XDIM_MAXMEMBERS P_ACCT = 5
*RUNALLOCATION
*FACTOR=1/12
*DIM TIME WHAT = 2009.JAN; WHERE = BAS(2009.TOTAL);
*DIM CATEGORY WHAT = FCST_LOAD; WHERE = FORECAST;
*ENDALLOCATION
Assuming the whole year's forecast initially loaded 2009.JAN and FCST_LOAD, the above script allocates the data equally to each period in 2009. The
script logic engine reads the data in packages split by P_ACCT members, with each package containing a maximum of five P_ACCT members, until it
reaches the end in P_ACCT dimension members.
1.5.2.2.17 *XDIM_PACKAGEBY
Defines the dimension for which to partition packages during script logic execution. Packages start in parallel mode for better performance.
You can specify the server group using a parameter in IMG. Run transaction SPRO, then choose
PARALLEL_SERVER_GROUP
Business Planning and Consolidation
Global setting
*XDIM_PACKAGEBY {Dimension name} [ = {Package number} ]

Package number is an optional parameter having a default value of 2.
Example
*XDIM_PACKAGEBY ENTITY
In the example above, two packages are created and partitioned by the dimension ENTITY.
Example
*XDIM_PACKAGEBY ACCOUNT = 4
Four packages are created are partitioned by the dimension ACCOUNT.
Note
You can use the *XDIM_PACKAGEBY keyword only once in each script.
Parallel mode is triggered ONLY when the member number for the dimension that is defined with *XDIM_PACKAGEBY is greater than 1.
The following keywords do not support PACKAGEBY: *RUN_PROGRAM, *RUNALLOCATION, *CALL_CUSTOM_LOGIC, and *START_BADI.
1.5.2.2.18 *XDIM_FILTER
XDIM_FILTER brings all members when the specified condition is met. This keyword returns only base members.
PUBLIC
Page 60 of 102
Example
*XDIM_MEMBERSET Category = PLAN
*XDIM_MEMBERSET Entity = C3000
*XDIM_MEMBERSET P_DataSrc = MANUAL
*XDIM_MEMBERSET RptCurrency = LC
*XDIM_MEMBERSET P_Activity = EMPL1
*XDIM_MEMBERSET P_ACCT = CE0004220
*XDIM_FILTER Time = [Time].properties("MONTHNUM") = "2"
*WHEN P_ACCT
*IS CE0004220
*REC (EXPRESSION = 888)
*ENDWHEN
*COMMIT
The code in this example writes only FEB records for CE0004220.
1.5.2.2.19 *COMMIT
A logic file can contain formulas that depend on the result of calculations performed by the model, and these calculations in turn depend on the results of other
formulas in the same logic.
Example
[P_ACCT].[#CE0004030] = ( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] ) * 0.15
[P_ACCT].[#CE0661000] =
( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[#CE0004030] ) / [P_ACCT].[CE0652000]
In this example, CE0661000 depends on the first calculation, and this calculation in turn depends on the calculation of CE0004030.
The logic, if written in the above format, does not work correctly, because CE0004030 cannot be retrieved from the model until its result has been posted to the
model. To get the right results, CE0004030 must be calculated AND stored in the model. THEN, the calculated result can be retrieved from the model and be
used to calculate CE0661000.
To force a write back of the result of the calculation of CE0004030 into the model before the calculation of CE0661000, you can insert the instruction *COMMIT
between the two calculations. The logic then works when written as follows:
Example
[P_ACCT].[#CE0004030] = ( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] ) * 0.15
*COMMIT
[P_ACCT].[#CE0661000] =
( [P_ACCT].[CE0004010] + [P_ACCT].[CE0004020] + [P_ACCT].[CE0004030] ) / [P_ACCT].[CE0652000]
In this case CE0004030 in the second formula does not have the pound sign (#), because it is a stored amount read from the model.
Note
Any number of commit instructions can be entered in a logic file. However, the number of commit instructions should be kept to the minimum, because they
have a negative impact on the overall performance of the logic execution due to increased communication between the database and script logic engine. The
ideal case is to have one commit at the end.
1.5.2.2.20 Special Keywords

The following are special keywords:
SET
An implied keyword is available for each dimension, which holds the set of members passed to the logic engine for a given dimension. This keyword can be used
as a replacement string anywhere in the logic.
%{DimName}_SET%
{DimName} is the name of a valid dimension in the model. For example the keyword %INTCO_SET% contains the set of members passed to the logic for the
dimension INTCO.
This keyword can be used anywhere in the logic and not just within some specific statement like XDIM_MEMBERSET.
This keyword is not modified by the XDIM_MEMBERSET instruction, as it always returns the original set passed to the logic.
This keyword does not return a default set if no set is passed. Its default is an empty set.
DIM
Another type of implied keywords is available for each non-user-defined dimension. This keyword holds the actual name of a dimension of a given type, and can
be used as a replacement string to use anywhere in the logic.
%{DimType}_DIM%
{DimType} is the type of dimension.
PUBLIC
Page 61 of 102
Example
If, in a model, the category dimension is called SCENARIO , the keyword %CATEGORY_DIM% returns the word SCENARIO.
Valid types are:
ACCOUNT
CATEGORY
TIME
ENTITY
INTCO
CURRENCY
DATASRC
Using Data Manager Prompts
In most of the script executions, you need to get user selection and use that value inside the logic script. For this purpose, you can use Data Manager prompts
inside the logic.
Syntax
$DM_PROMPT$...
Example
*XDIM_MEMBERSET P_ACCT= CE0004020, CE0004010
*XDIM_MEMBERSET CATEGORY = ACTUAL
*XDIM_MEMBERSET TIME=2006.SEP
*XDIM_MEMBERSET ENTITY= C9000
*XDIM_MEMBERSET P_ACTIVITY=NONE
*XDIM_MEMBERSET P_DATASRC=UPLOAD
*XDIM_MEMBERSET RPTCURRENCY = LC
// Increase Wage and Salary, and Personnel Expense by entered percentage
[P_ACCT].[#CE0004020] = [P_ACCT].[CE0004020] * ( 1 + $WS_PERCT$ / 100) [P_ACCT].[#CE0004010] =
[P_ACCT].[CE0004010] * ( 1 + $EXP_PERCT$ / 100)
The percentage to be increased for the above two accounts is provided by the user.
Note
Additional configuration is required in the Data Manager to pass these parameters to script logic. In transaction RSPC in the ABAP layer, the corresponding
process chain's BPC:Run Logic step, Process Variant, needs to be maintained with additional parameters like TAB, SUSER, and REPLACEPARAM.
Then, the dynamic script of Data Manager needs to be adjusted to accept the prompts.
PROMPT(SELECTINPUT,,,,"%ENTITY_DIM%,%CATEGORY_DIM%,%CURRENCY_DIM%,%TIME_DIM%")
PROMPT(TEXT,%WS_PERCT%,"Input W/S Percent in decimals",)
PROMPT(TEXT,%EXP_PERCT%,"Input Exp. Percent in decimals",)
INFO(%EQU%,=)
INFO(%TAB%,;)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,TAB,%TAB%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,EQU,%EQU%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SUSER,%USER%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SAPPSET,%APPSET%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SAPP,%APP%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,SELECTION,%SELECTION%)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,LOGICFILENAME,TESTING0123.LGF)
TASK(ZBPC_PROT_EXP_RUN_LOGIC,REPLACEPARAM,WS_PERCT%EQU%%WS_PERCT%%TAB%EXP_PERCT%EQU%%EXP_PERCT%)
Note
Read the restriction around Validation when DM prompts are used in your script in OSS note 1334695.
Script Logic System Variables
%USER% - Returns the current Planning and Consolidation user
%APPSET% - Returns the current Planning and Consolidation environment
%APPLICATION% - Returns the current Planning and Consolidation model
%YEAR% - Returns the current calendar year
You can use %YEAR% to derive the member values. For example, %YEAR%.TOTAL, and %YEAR%.Q1. You can also use to offset years like %YEAR%(2).TOTAL.

PUBLIC
Page 62 of 102

Use
This optional parameter returns a time value after taking into consideration an offset value from a given time period.
Prerequisites
This function works only with base member values.
Activities
The format for this parameter is TMVL(offset, base_period). Utilize this parameter following these guidelines:
Offset can be either negative or positive. Only integers are allowed.
The base period can be a hardcoded value such as 2009.MAY, a Time script variable such as %TIME_SET%, or a Data Manager Prompt variable such
as $CURPER$.
Note
Nested TMVL parameters such as TMVL(-1, TMVL(-3, 2009.JAN)) ) are not supported.
You can use TMVL in:
FACTOR/EXPRESSION within REC
FOR/NEXT loops
IS conditions inside WHEN/ENDWHEN.
variables, like %TIME_SET%
The first period of the TIME_SET is used as the base period for a negative offset and the last period of the TIME_SET is used as the base period for a
positive offset.
scope statements
Multiple separate (not nested) TMVLs can be used in one scope statement.
When 0 is used as offset, no offset will be done for the provided time member.
Example
In this example, Actual data records are copied over to the same period in the following year with a 10 percent increase. The existing data is shown in the
following table:
Category
Entity
P_ACCT
P_Activity
P_DataSrc
RptCurrency
Time
SignData
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2006.APR
100,891.26
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2006.APR
70,836.02
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2006.APR
15,131.67
The script used is the following:

*XDIM_MEMBERSET P_ACCT= CE0004010, CE0004020, CE0004210
*XDIM_MEMBERSET CATEGORY = ACTUAL
*XDIM_MEMBERSET ENTITY= C9000
*XDIM_MEMBERSET P_ACTIVITY=NONE
*XDIM_MEMBERSET P_DATASRC=UPLOAD
*XDIM_MEMBERSET RPTCURRENCY = LC
*XDIM_MEMBERSET TIME = 2006.APR
*WHEN CATEGORY
*IS ACTUAL
*REC(FACTOR=1.1, TIME=TMVL(12,2006.APR))
*ENDWHEN
The data that results from running the logic script is shown in the following table:
Category
Entity
P_ACCT
P_Activity
P_DataSrc
RptCurrency
Time
SignData
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2007.APR
110,980.40
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2007.APR
77,919.62
ACTUAL
C9000
CE0004010
NONE
UPLOAD
LC
2007.APR
16,644.84
1.5.3 Validations as Script Logic

Use
PUBLIC
Page 63 of 102
Use
You use this to check the integrity and correctness of entered values before signing off such data as approved.
Activities
The validation process is handled by a stored procedure called VALIDATION. This procedure is launched using the following logic statement:
*RUN_PROGRAM VALIDATION( <parameters list> )
Example
*RUN_PROGRAM VALIDATION
CATEGORY = %C_CATEGORY_SET%
CURRENCY = %GROUPS_SET%
OTHER = [ENTITY=%ENTITY_SET%]
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
1.5.4 US Eliminations as Script Logic

Use
You use this to control where the results of eliminations are stored in an Entity dimension.
Activities
The intercompany eliminations process is handled by a program called US_ELIM. This program is launched using the following logic statement:
*RUN_PROGRAM US_ELIM( <parameters list> )
Example
*RUN_PROGRAM US_ELIM
GROUP = %GROUPS_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
More Information
US Eliminations Rule
1.5.5 Carry-Forward as Script Logic

Use
You use this program to initialize a new reporting period with the closing balances of the last period from the previous year into the opening balances of the current
period.
Activities
The copy-opening process is handled by a class called CL_UJP_COPYOPENING. This program is launched using the following logic statement:
*RUN_PROGRAM COPYOPENING( <parameters list> )
Example
*RUN_PROGRAM COPYOPENING
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
More Information
PUBLIC
Page 64 of 102
Carry-Forward Rule
1.5.6 Intercompany Booking as Script Logic

Use
You use this to run Intercompany booking as well as difference posting.
Activities
Intercompany reconciliations processes are handled by a program called ICBOOKING.
Running the following in an ICDATA.LGF logic file runs Intercompany reconciliation:
*RUN_PROGRAM ICBOOKING ( <parameters list> )
Example
*RUN_PROGRAM ICBOOKING
CATEGORY = %CATEGORY_SET%
DATASRC = INPUT// value of datasrc dimension member that represents the input datasrc
TID_RA = %TIME_SET%
ENTITY = %ENTITY_SET%
ACCOUNT = %ACCOUNT_SET%
FLOW = %FLOW_SET%
TYPE = 'I'.
*ENDRUN_PROGRAM
Running the following in an ICBOOKING.LGF logic file runs Intercompany reconciliation and difference posting:
*RUN_PROGRAM ICBOOKING ( <parameters list> )
Example
*RUN_PROGRAM ICBOOKING
GROUP = %CATEGORY_SET%
TID_RA = %TIME_SET%
*ENDRUN_PROGRAM
More Information
Intercompany Booking Rule
Eliminations and Adjustments Rule for Legal Consolidation
1.5.7 Currency Conversion as Script Logic

Use
You use this to run a new logic file currency conversion. Currency conversion typically runs by default when default logic runs.
Activities
Currency conversion is handled by a program called CURR_CONVERSION. This program is launched using the following logic statement:
*RUN_PROGRAM CURR_CONVERSION( <parameters list> )
You must also set up the following list of attributes for relevant dimensions in addition to the required attributes:
Dimension
Attribute
ACCOUNT
RATETYPE
DATASRC
DATASRC_TYPE (I, M, A, or L)
IS_CONVERTED (Y, G, or N)
ENTITY
CURRENCY (local currency)
FLOW
FLOW_TYPE (used to find the closing flow)
CURRENCY
CURRENCY_TYPE (currency type - Reporting, Local, or group)
PUBLIC
Page 65 of 102
TIMEID
YEAR
PERIOD
TIMEID
MONTHNUM
INPUTCURRENCY (with Rate cube)
MD (indicator of multiple or divide)
Note
Datasrc dimension is not mandatory for planning, and currency translation could be run without this dimension. If you choose to include a Datasrc dimension in
a planning cube, the attributes must be set up as they are checked in currency conversion program.
Flow dimension is not mandatory for planning, and currency translation could be run without this dimension. If you choose to include a Flow dimension in a
planning cube, the attribute needs to exist in the flow-type dimension to enable currency conversion.
Example
*RUN_PROGRAM CURR_CONVERSION
CATEGORY = %C_Category_SET%
GROUP = %GROUPS_SET%
TID_RA = %TIME_SET%
RATEENTITY = Global
*ENDRUN_PROGRAM
Note
Global should be the valid member ID that is set in the RATEENTITY dimension.
More Information
Currency Translation Rule
1.5.8 Account-based Calculations as Script Logic

Use
You use this to run an account-based calculation rule.
Activities
You run this program using the following logic statement:
*RUN_PROGRAM CALC_ACCOUNT( <parameters list> )
Example
*RUN_PROGRAM CALC_ACCOUNT
CURRENCY = %CURRENCY_SET%
TID_RA = %TIME_SET%
CALC=A
OTHER = [ENTITY=%ENTITY_SET%]// or OTHER=[ENTITY=C1000] or [ENTITY=%ENTITY_SET%;INTCO=%INTCO_SET%...]
*ENDRUN_PROGRAM
Note
If there is no other scope against which you need to run the program, delete the OTHER line in the script.
More Information
Account-based Calculations Business Rule
1.5.9 Business Rules Management

Use
Business rules are parameter-driven functions within SAP BusinessObjects Planning and Consolidation models for calculating and posting monetary amounts in
PUBLIC
Page 66 of 102
support of common accounting activities, such as intercompany booking, currency translation, and eliminations and adjustments.
To manage business rules in SAP BusinessObjects Planning and Consolidation, select
Rules .
Rules
Business
Features
Adding Business Rules to Models
When you create or modify a model, you can add business rules to it. You can add the following types of business rules:
Account-based calculation (see Account-based Calculation Rule)
Currency translation (see Currency Translation Rule)
Intercompany booking to match intercompany transactions (see Intercompany Booking Rule)
Carry-forward processing to initialize beginning balances when a new fiscal cycle starts (see Carry-Forward Rule)
US eliminations (see US Eliminations Rule)
Eliminations and adjustments when generating consolidation entries for a group of entities, such as eliminations, adjustments, reclassifications, and minority
calculations (see Eliminations and Adjustments Rule for Legal Consolidation)
After adding a business rule type to a model, you must customize it to meet your needs by specifying parameter values. For example, in Eliminations and
Adjustments, you can indicate which balances to read before calculating an amount, or under which account and audit member to post the calculated amount. In
addition to customizing default business rules, delivered with the IFRS starter kit for instance, you can define new rules for various types of business processes
and add them to a model. For more information, see Model Management if using the NetWeaver platform of Planning and Consolidation, or Model Management if
using the Microsoft platform.
Editing Business Rules
You can edit the list of available rules for a selected type of business rule within a model. You can then edit a specific rule in the list. You can use standard
Microsoft Excel functionality to perform the following actions:
Select multiple detail record rows
Copy, paste, and delete detail records by row
Copy and paste within a cell by right-clicking and selecting a context menu option or using CTRL + C and CTRL + V
Copy rows
You can look up members within the cells of a rule by clicking the Lookup icon that appears when you place the cursor within that cell.
Validating Business Rules
You can verify the detail records of a business rule after modifying it by clicking Validate in the <Rule Name> page. A message appears displaying a
successful status or any errors encountered.
Activities
You can run a business rule as follows:
Perform a data send.
When you send data using the EPM add-in for Office or SAP BusinessObjects Planning and Consolidation, the system runs the default logic indicated in
default.lgf. For example, the default logic can execute the currency translation business rules. While you can add any logic or business rule execution to the
default script, it is not recommended, as performance may decrease when sending data.
Run a Data Manager package that contains a reference to a logic file (*.LGF).
Logic can be applied to a specified region of data that is stored in the database using any type of logic. You can create new logic files or modify existing
ones. For example, an Import package runs against the default logic unless the Import package is modified to include other logic files. Each logic file
contains one or more ABAP programs that run a specific set of logic commands. Business rules execution can be triggered in any logic file.
Post a journal entry.
Upon posting a journal, the system runs logic that is specific to journal processes. To overwrite the default journal logic, you can create a new script logic file
called Journal.lgf. Business rules execution can be triggered in the journal logic file.
In SAP BusinessObjects Planning and Consolidation, Currency Translation and Consolidation processes can also be executed from the Consolidation
Monitor.
More Information
Consolidation Monitor
1.5.9.1 Account-based Calculation Rule

Use
Account-based calculations read and aggregate the values posted to specific combinations of accounts, flow types, and audit members in order to post the
aggregated amount under an alternate destination account, flow and audit member combination.
Features
The following dimensions can be specified in order to define source and target members in the calculation:
Category (C-type dimension)
Account (A-type dimension)
Flow (S-type dimension)
Datasource (D-type dimension)
The account-based calculations business rule can invert the sign when posting calculated amounts when appropriate, which alternates debit and credit amounts.
This rule can also use reference data in other periods and years to determine amounts to post.
PUBLIC
Page 67 of 102
This rule also supports year-to-date calculations in period-based models.

You can utilize account-based calculations in both financial and legal consolidation models.
Example
You can use this business rule to calculate and post values that you need for cash flow reporting.
More Information
Account-based Calculations as Script Logic
1.5.9.2 Currency Translation Rule

Use
You use this to convert local currency values into one or more reporting or group currencies in accordance with major Generally Accepted Accounting Principles.
Currency translation rules are executed as a separate task using a Data Manager package. They can also be executed from the Consolidation Monitor in the
Consolidation Central area of SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver. For more information, see Consolidation Monitor.
Prerequisites
Currency translation applies to both financial and legal consolidation models to which a corresponding rate model has been referenced.
When performing currency translation, different exchange rates such as average and period end rates, as well as formulas, are applied. A currency translation
rule contains the necessary rates and logic for a unique account rate type. The account rate type must exist in the Account dimension in order to be triggered.
However, you can create and name the currency translation rule first, and then assign the RATE_TYPE in the account dimension to the accounts to which it
relates. When currency translation runs, it translates each account in accordance with the rules defined for the account rate type which has been assigned to that
particular account.
If you need to store data in the local currency of the entity and also convert it to one or more reporting or group currencies, a currency type dimension must exist. In
addition, the system must access a rate model that stores the exchange rates used for the automatic translation. The following list provides a summary of the
environment requirements to support currency translation:
The environment must include a rate model where exchange rates are stored. You must assign this rate model to any model that utilizes it.
The model itself must include a currency type dimension and possibly a Group dimension.
The Currency (R type) dimension must include the properties:
REPORTING, whose values are Y or blank
CURRENCY_TYPE, whose values are R for Reporting Currencies, T for transaction currency, or L for local currency. The value G for group currency is
used only if the currency dimension is also used to manage groups. This value is only relevant for models migrated from a previous version of SAP
BusinessObjects Planning and Consolidation.
For Consolidation type models, the Group (G) dimension must include the following properties:
GROUP_CURRENCY, whose values are valid currencies in the previously mentioned Currency dimension
CURRENCY_TYPE, whose values are G for group currency or N for Non-Group related data, meaning local data
The Entity (E type) dimension must include the property CURRENCY, whose values are valid Input_Currencies. Input currencies are listed in the
currency dimension of the Rate model.
The Account (A type) dimension must include the property RATETYPE, whose values are valid accounts in the rate model.
The Time (T type) dimension must include the properties YEAR, PERIOD, TIMEID, and MONTHNUM.
The Audit dimension is not mandatory for currency translation, but if you include it, the dimension must include the following properties:
DATASRC_TYPE, whose values include the following:
I - Input
M - Manual Adjustment
A - Eliminations and Adjustments
L - Audit level (use only for consolidation)
IS_CONVERTED, whose values include the following:
N - these members are ignored in the conversion
Y (or blank) - these members are converted from LC into the desired currency unless the members are flagged as requiring manual
adjustment; these members have their currency conversions entered manually
G - these members are copied from the reporting currency of the GROUP that is being translated into the currency member corresponding to the
given group
The Flow (S type) dimension is not mandatory for currency translation, but if you include it, the dimension must include the property FLOW_TYPE.
The InputCurrency dimension within the applicable rate model must include the property MD, whose values are M for multiply rates or D for divide rates.
The appropriate FXTRANS logic must be available.
The default translation reads all values in local currency where currency = LC, applies the correct exchange rate according to the applicable rate model, and
writes the results in the appropriate reporting currency (USD, EURO, and so on).
Rate selection
For the selection of the correct rate, the following rules apply:
The source currency is derived from the property CURRENCY of the entity being translated.
The rate to be applied during translation, such as Endflow, Histrate, and so on, is derived from the property RATETYPE of the account being
translated.
The valid rates are those corresponding to an account of the rate model for which the value of the GROUP property is FX rate.
The system does not convert any accounts with a rate type that is not a part of the currency translation business rules and converts all accounts with a
blank rate type with a factor 1.
PUBLIC
Page 68 of 102
Note
The default currency translation supplied with the product for multi-currency models performs a cross-rate translation; it multiplies the amount in local currency
by the ratio between the rate of the destination currency and the rate of the source currency. This allows the model to use only one table of rates for translating
any source currency into any destination currency.
Note
Other types of translations can be defined by using the currency translation business rules tables and the relevant properties in the Currency and
InputCurrency dimensions to support:
the ability to use different tables of rates by reporting (destination) currency
the ability to distinguish between Multiply currencies and Divide currencies
Preconditions for Running Currency Translation
Currency translation can run in the following two modes:
Reporting currency mode
Reporting currency mode converts transaction data recorded in a local currency to the specified reporting currency. For this mode, make sure the script is
similar to the following:
CURRENCY = %RPTCURRENCY_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
......
*ENDRUN_PROGRAM
Pay attention to the keyword CURRENCY. If running currency translation for the reporting currency, the keyword on the left side should be CURRENCY . If
running currency translation for a group, use the keyword GROUP .
Group mode
Group mode converts subsidiaries' data to a group's currency. This is mainly used before consolidation.
Whatever mode the currency translation runs in, the following conditions must be satisfied:
The model must contain only one Currency (type R) dimension.
The model must contain only one Group (G type) dimension if the model is a Consolidation model.
For consolidation models migrated from previous versions of SAP BusinessObjects Planning and Consolidation, this dimension is not mandatory, in order to
ensure compatibility with the current version.
The reporting model must reference the RATE model.
Some dimensions, such as Account, Entity, and Currency, must contain appropriate properties as noted in the following table:
Model
Dimension
Property
Description
Main
Account
RATETYPE
The value of the RATETYPE property

must be a valid key member in the rule
table for currency translation, such as
AVG, END, and ENDFLOW.
Main
Entity
CURRENCY
The CURRENCY property denotes the local

currency for the current Entity. For
example, for Entity US, the currency is
USD; for FRANCE, the currency is EUR.
The value of this property must be a valid
member of the InputCurrency
dimension.
Main
Currency
CURRENCY_TYPE
The CURRENCY_TYPE property specifies

the currency type, and it should take the
following values:
L (local currency)
R (reporting currency)
G (group, for compatibility on
migrated models only)
Main
Group
CURRENCY_TYPE
The CURRENCY_TYPE property specifies

if the member is a group/sub-group or is
used to enter local data:
G (Group)
N (Non-Group, used for data input)
Main
Time
YEAR
The YEAR property contains the year

information of the ID. For example, if the
ID is 2008.AUG, YEAR is 2008.
Main
Time
PERIOD
The PERIOD property denotes the period

to which the current time belongs. For
example, if the ID is 2008.AUG,
PERIOD is AUG.
Main
Time
PERIOD
The TIMEID property is a numerical

value for the current time. For example,
for 2008.AUG, the TIMEID is 20080800.
Main
Time
MONTHNUM
The MONTHNUM property takes the

numerical value of month. For example,
for 2008.AUG, the MONTHNUM is 8.
PUBLIC
Page 69 of 102
When optional dimensions such as Audit and Flow (S type dimension) do not exist, currency translation still runs successfully. However, if they do exist, they
impact the translation process. In this case, the following properties in these dimensions are mandatory:
Dimension
Property
Description
Audit
DATASRC_TYPE
The DATASRC_TYPE property signifies the audit member

type. The following four values are available:
I (input)
M (manual adjustment)
L ( audit level, for consolidation only)
A (eliminations and adjustments)
Audit
IS_CONVERTED
When the IS_CONVERTED property is set to N or blank,

members are ignored in the conversion. When set to Y,
members are converted from the local currency to the
desired currency.
Flow
FLOW_TYPE
The FLOW_TYPE property can take many values, but the

most important is the value CLOSING. The rule of currency
translation with FORCE_CLOSING = Y makes use of it.
To run currency translation in reporting currency mode, the mandatory condition mentioned previously should be satisfied. If optional dimensions such as Audit
and Flow (S type dimension) exist, the condition of the optional dimension is also necessary.
To run currency translation in group mode, beside the same requirement as reporting currency mode, the following additional conditions are mandatory:
The Ownership model must be set up and referenced.
Group information must be maintained in a separate Group dimension (except for models migrated from previous versions, where Groups can be
maintained in a Currency dimension).
Note
For migrated consolidation models only.
When using the Currency dimension, Currency and Group information resides in the same dimension. The following properties are needed in
Currency dimension:
The ENTITY property can be blank or a valid Entity ID. It is used to define the link between the group and the entity and to indicate the entity where
the aggregation should be stored. (Refer to the STORE_ENTITY property below.)
The GROUP_CURRENCY property can be used only on CURRENCY members with the property CURRENCY_TYPE= G. It must contain a valid ID from
the Currency dimension with the property CURRENCY_TYPE = R.
The STAGE_ONLY property controls the way the converted values must be saved in case of a multilevel conversion of groups. This property can
have the three values Y, E, or N (blank).
The STORE_ENTITY property can have the values Y or blank. It indicates whether the system copies the results of the currency translation for the
current Group into the entity specified in ENTITY property.
The STORE_GROUP_CURR property can have the values Y or blank. It indicates whether the system stores the currency translation result in the
Group currency. Otherwise, the system stores the result only in Group, not in currency.
The PARENT_GROUP property defines the group hierarchy. The value of this property should be a valid Group ID in the dimension.
When currency and group reside in one dimension, make sure the script file is similar to the following before running currency translation for the group:
GROUP= %GROUPS_SET%
TID_RA = %TIME_SET%
RATEENTITY = GLOBAL
......
*ENDRUN_PROGRAM
Pay attention to the keyword GROUP. If running currency translation in group mode, the keyword GROUP should be used instead of CURRENCY.
As of SAP BusinessObjects Planning and Consolidation 10.0, when building a consolidation, both a group dimension and a currency dimension are
required. Therefore, consolidation group members and currency members are held separately.
A new dedicated dimension, for example, Group, should be type G.
More Information
Currency Translation as Script Logic
1.5.9.3 Intercompany Booking Rule

Use
The Intercompany booking function supports the overall Intercompany reconciliation process.
Prerequisites
The following are required to perform Intercompany eliminations within a model:
The model must include an Intercompany dimension of type I.
The Intercompany dimension must include the property ENTITY, whose values are entity names.
PUBLIC
Page 70 of 102
The account dimension must include the property ELIMACC, whose values are account names.
The entity dimension must include the property ELIM, whose values are Y or blank.
The appropriate business rule table must be set up.
A Data Manager package executing the intercompany logic must be available.
This configuration not only allows intercompany details to be entered for any account, but it also supports an automatic elimination-by-level for all desired accounts.
Note
Although not mandatory, Intercompany reconciliation is normally performed in a separate Intercompany matching model apart from the Consolidation model.
Features
Intercompany booking records the declarations and reported balances by other entities against a particular entity. This allows business users within each
reporting entity to run a report that matches all of its declarations and reported balances against the balances of the rest of the entities, without having to assign to
each owner read-access for other entities. Bookings that make the Intercompany declarations match can be automatically generated, and details can be posted to
the consolidation model.
You use the Intercompany Booking business rule table to define the posting rules the system uses in generating the entries to match the Intercompany balances
and declarations.
The values entered in the following properties determine default elimination logic:
Dimension
Property
Length in Characters
Content
Account
ELIMACC
20
A valid account in this dimension
Entity
ELIM
Y or blank
Intercompany
ENTITY
20
The entity ID corresponding to this

intercompany member
Currency
REPORTING
Y or blank
The default elimination logic does the following:

Scans all base level, non-elimination entities, which are entities with the property ELIM <> Y.
In case the model has a currency dimension, restricts its action to all reporting currencies, which are currencies that have the property REPORTING=Y.
Data in local currency cannot be eliminated because it is in different currencies.
Eliminates all values of the accounts to be eliminated, which are accounts that have the property ELIMACC<>blank, into the desired plug account, which is
the account specified by the ELIMACC property.
The elimination is performed in the elimination entity below the first common parent.
The common parent is determined as follows:
The system identifies the two entities for which a common parent must be found. The first entity is the current entity member. The second entity is the
entity corresponding to the current Intercompany member. This entity is obtained by reading the content of the property ENTITY of the current
Intercompany member.
The system searches in a selected entity hierarchy for the first member that has both entities as descendants. This is the common parent.
Then the system searches in the immediate descendants of the common parent for a valid elimination entity (an entity that has the property ELIM=Y).
This is the entity in which the system stores the results of the elimination.
The default elimination logic searches in the first hierarchy of the entity dimension. This can be modified to have the elimination performed in all hierarchies
existing in the entity dimension. If no common parent is found, no elimination occurs. If no elimination entity is found below the first common parent, the next
common parent is searched.
More Information
Intercompany Booking as Script Logic
1.5.9.4 Carry-Forward Rule

Use
Carry-forward populates the opening balances for the current year with the closing balances of the last period of the prior year.
Features
Carry-forward rules enable you to generate the Opening Balance of any category based on the following properties:
Flow_Type in the Flow dimension: the value of this property should be OPENING on the relevant Opening flow and CLOSING on the relevant Closing flow.
Category_for_ope, Opening_year, Opening_period in Category dimension
Carry-Forward rules can be used to initialize a new reporting period with the closing balances of the last period from the previous year into the opening
balances of the current period. It can also copy closing balances from a designated year ( Opening_year property) and period ( Opening_period
property) to the current period. The designated year and period can be an absolute or relative number. You can also specify a Category in which to store the
closing data using the Category_for_ope property. For example, you may need to create opening data in a Budget category using data from a Forecast
category.
DataSrc_Type, Opening_Datasrc, Copyopening in the Audit dimension
Currently this procedure is limited to copying the opening balances as found in the Audit dimension members flagged as I and M in the DATASRC_TYPE
property. The procedure copies only the input balances and their related manual adjustments. The balances generated automatically by the consolidation
procedure ( Audit members flagged as A) are taken into account during the consolidation process by the consolidation procedure itself.
The Copyopening property enables you to identify the members on which the carry-forward rule should be executed.
PUBLIC
Page 71 of 102
The Opening_Datasrc property enables you to post data on a specific datasource when running the Carry-Forward rules.
Within a carry-forward rule, the field Account specifies the Destination account. The property Same_period enables you to copy the same period
balances to the current period. The YTD property enables you to sum up the balances of YTD to the current period.
In a legal consolidation model, such flows are often identified as members of a dedicated dimension. In simpler models, however, it is also possible to store them
as additional accounts in the Account dimension.
More Information
Carry-Forward as Script Logic
1.5.9.5 US Eliminations Rule

Use
US eliminations functionality addresses the posting of Intercompany US eliminations in scenarios where a full legal consolidation model is not required, such as
within a standard financial model.
Prerequisites
The following are required to perform Intercompany eliminations within a model:
The model must include a dimension of type I, Intercompany.
The Intercompany dimension must include the property ENTITY, whose values are entity names.
The account dimension must include the property ELIMACC, whose values are account names.
The entity dimension must include the property ELIM, whose values are Y or blank.
The appropriate business rule table must be set up.
A Data Manager package executing the Intercompany logic must be available. This configuration not only allows Intercompany details to be entered for any
account, but it also supports an automatic elimination-by-level for all desired accounts.
Features
When reporting the financial results of a group of entities, you may want to see the results for the group net all Intercompany activity within the group. Therefore, the
system identifies Intercompany activities and balances and posts entries so these activities and balances are fully eliminated when looking at the overall results
for the group. US eliminations functionality addresses the posting of Intercompany eliminations in scenarios where a full legal consolidation model is not required,
such as within a standard financial model. When utilizing a legal consolidation model, Intercompany eliminations are normally handled as part of an eliminations
and adjustments function.
Intercompany elimination entries should be reflected only in groups in which both the entity and the partner entity are part of the group. To address this, US
eliminations uses a concept known as posting at first common parent.
US eliminations are normally used in financial models as opposed to legal consolidation models.
The US eliminations business rules define the audit members to eliminate. For each of these audit members you then define the corresponding destination audit
member under which the system should post the elimination postings.
The values entered in the following properties determine default elimination logic:
Dimension
Property
Length in Characters
Content
Account
ELIMACC
20
A valid account against which the actual

Intercompany account to be eliminated
should be offset
Entity
ELIM
Y or blank
Intercompany
ENTITY
20
The entity ID corresponding to this

Intercompany member
Currency
REPORTING
Y or blank
The default elimination logic does the following:

Scans all base level non-elimination entities (entities having the property ELIM <> Y).
In case the model has a currency dimension, restricts its action to all reporting currencies only (currencies having the property REPORTING=Y). Data in
local currency cannot be eliminated because it is in different currencies.
Eliminates all values of the accounts to be eliminated (accounts having property ELIMACC<>blank) into the desired plug account (the account specified by
the ELIMACC property itself).
The elimination is posted to the elimination entity immediately below the first common parent. The common parent is derived as follows:
For a particular record the system identifies the two entities for which a common parent must be found. The first entity is the current entity member and
the second entity is the entity corresponding to the current Intercompany member. This entity is obtained reading the content of the property ENTITY
of the current Intercompany member.
The system searches in a selected entity hierarchy for the first member that has both entities as descendants. This is the common parent.
Then the system searches in the immediate descendants of the common parent for a valid elimination entity (an entity having the property ELIM=Y).
This is the entity where the results of the elimination are stored.
The default elimination logic does its searches in the first organizational structure (hierarchy) of the entity dimension. This can be modified to have the
elimination performed in all hierarchies existing in the entity dimension. If no common parent is found, no elimination occurs. If no elimination entity is found
below the first common parent, the next common parent is searched.
More Information
PUBLIC
Page 72 of 102
More Information
US Eliminations as Script Logic
1.5.9.6 Eliminations and Adjustments Rule for Legal

Consolidation
Use
You use this type of business rule when performing a legal consolidation process to generate adjustments and postings that integrate results from subsidiary
reporting entities into consolidated financial statements in accordance with Generally Accepted Accounting Principles.
Eliminations and adjustments are executed as a separate task using a Data Manager package. They can also be executed from the Consolidation Monitor in the
Consolidation Central area of SAP Business Planning and Consolidation, version for SAP NetWeaver. See Consolidation Monitor.
Prerequisites
Before executing eliminations and adjustments, do the following:
Enter any ownership changes into the ownership cube, such as the acquisition of a new company, the sale or transfer of shares, and divestitures.
Update consolidation methods and accounting methods as necessary.
Update percent ownership and percent control within the group.
Note
Ownership calculations can be run to calculate the overall ownership within each group. Consolidation parameters assigned to each entity within each group
then need to be validated within the ownership cube.
You must have the following items in your environment before performing the eliminations and adjustments:
Ownership Model
Stores the overall ownership and percentage control of each entity by group on a category and time dependent basis as well as the corresponding method of
consolidation to apply
Group dimension
Provides the ability to store consolidated results by the group to which they relate
Currency dimension
Provides the ability to store consolidated results in the currencies specified for each group
Note
It is only possible to use a common dimension for both currency and group in migrated models. In SAP BusinessObjects Planning and Consolidation
10.0, you must use two separate dimensions; one for group and one for currency.
Method-based multipliers
Define the formulas to use in calculating the amounts to post
Eliminations and Adjustments rules
Define the balances upon which eliminations and adjustments are made and the items such as accounts and flow to which calculated amounts are posted
Features
The most important of the necessary adjustments for legal consolidation relate to the elimination of intercompany activity between the various reporting units, and
reclassifications and supporting the model of the applicable rules for the accounting of long-term investments. Eliminations and adjustments rules support the
calculation and generation of these postings.
Eliminations and adjustments rules are applicable only to a legal consolidation model to which you attach a corresponding ownership model.
When eliminations and adjustments rules are executed for a given group, the system performs the following:
Reads from the ownership model which entities make up the group, the applicable consolidation method, and the ownership and consolidation percentages.
Determines for each elimination and adjustment defined in the business rules the base amount upon which the elimination and adjustment is to be
calculated based on the source data.
Identifies for each elimination and adjustment the corresponding method-based multiplier from the business rules.
Based on the identified method-based multiplier and the method of consolidation assigned to a given entity, determines the formulas to apply in calculating
the amounts to post. Ownership and consolidation percentages can be applied in the calculations.
Posts the calculated amounts based upon the posting rules defined in the Eliminations and Adjustments business rules tables.
The following information describes the fields of the General tab in the Business Rules interface of Eliminations and Adjustments:
Source Audit ID: Restricts the type of transaction data to which the rule applies. This can be a member of the audit dimension, or a DIMLIST in the audit
dimension. This field can also be blank to represent all audit members with an audit type of I or M. (You can use Adjustment Level to apply further
restriction.)
Destination Audit ID: Indicates the kind of data the rule generates. This should be one base member with an audit type of A.
Group Type Filter: Restricts the rule to specific group or scope members.
Entity Property Filter: Similar to Group Type Filter, this restricts the rule to specific entity members.
Adjustment Type: Defines the rule type. Possible values are the following entries:
Blank: generic rule type
N: for new entities in the group/scope; similar to a generic rule
P: for proportional entities
E: for equity entities
D: for entities that leave the group/scope in the middle of the year
L: for entities that leave the group/scope in the beginning of the year
Adjustment Level: Indicates the execution sequence of all elimination rules. The system executes an elimination rule with an adjustment level of 0 first, then
PUBLIC
Page 73 of 102
level 1, then 2, and so on. The result of an elimination rule with a lower adjustment level can be the input of an elimination rule with a higher adjustment
level. The source audit ID for an elimination rule with an adjustment level larger than 0 has further restrictions.
Other Dimension Filter: A string in this field indicates filters or special restrictions on other dimensions. For example, if you have a user-defined dimension
called Product and you want to run an elimination for only one of its members called Pro1, you would enter Product = Pro1.
Force Destination Member: When filled, indicates the value to which the system should force the elimination result. For example, if you enter Product =
ALL, then for the generated elimination result, the system populates the dimension Product to ALL, no matter what the original value was.
Ownership Filter: Filters the ownership value. For example, to apply a rule to only those entities whose ownership percentage in a group or scope is larger
than 70%, you enter POWN > 0.7.
More Information
Method-based Multipliers and Consolidation Rules
1.5.9.6.1 Method-based Multipliers and Consolidation Methods

Use
You can set up global business rules at the environment level. Once the headers, methods, and rules are defined, they can be used in all related business rule
tables within an environment.
Features
You populate the following two global definitions:
Consolidation methods
Global Definitions
You can add a new Global Definition in Planning and Consolidation Administration by:
Selecting the type of Global Definition (Method of Method-based Multiplier)
Entering the required fields
Saving or validating the Method of Method-based Multiplier
Once defined, the rule can be used in any model in the environment.
Note
Validating the rule is not supported in the Microsoft version.
Consolidation methods
The Consolidation Method list describes the accounting methods available for consolidating each entity.
Field Name
Description
Method code
The unique method code. The value must be an integer between 1 and 98
99 - a reserved value and means any method, consequently it cannot be assigned
to any entity
Method name
The name of this method.
Example
Leaving, Equity, Proportional, Global, Holding.
Method type
The Entity method type.

Available types: New, Holding, Global, Proportionate, Equity, Leaving (During the Year),
Disposed at last year-end
Method-based Multipliers control how the amounts or the destination accounts should be calculated.
You define a name (ID), a description, and a type as noted in the following table. The consolidation method defined in the Type field limits the use of the rule to the
specified type of consolidation method.
The calculation of consolidated data is controlled by the multiplier being used, the consolidation method assigned to the current entity, and its Intercompany
partner, if applicable.
The following fields can be defined:
Field Name
Description
ID
The identifier of the rule.
Example
RULE01
Description
A description of the rule.
Example
Equity, 100% Minority part, Dividends, Stock Holder Equities, Intercompany
PUBLIC
Page 74 of 102
elimination
Type
The consolidation method using the method-based multiplier can be restricted to:
Proportional
Equity
Leaving
Disposed
New
or blank
Entity Method
A valid entity method, as defined in the Consolidation Methods list, or a list of entity
methods separated by commas to which the multiplier applies.
IntCo Method
A valid entity method, as defined in the Consolidation Methods list, a list of entity
methods separated by commas, or 99 for all methods. For the Intercompany dimension,
this is the entity value to which the multiplier applies.
ALL Formula
An expression that represents the percentage (or formula) to apply to the Destination All
account property from the Eliminations and Adjustments business rule.
The value can be an arithmetic expression combining any defined percentage in the
account dimension of the ownership model. All percentages where the property
IS_INPUT is equal to Y can be used. Note the following guidelines:
The members must be enclosed in square brackets.
Example
[POWN], [PCTRL], [POWN]
Add the prefix P to the percentage to use the Prior value.
Example
[PPOWN], [PPVOTE]
Add the prefix I_ to the percentage to add the Intercompany value.
Example
[I_POWN]
The syntax of the prior value can be combined with the syntax of the INTCO value.
Example
[I_PPOWN]
Note
The calculation of POWN by both direct share method and group share method is
supported.
We also support the calculation of PCTRL (calculation of ultimate control %) in the
business rule tables.
There are two options for obtaining results: system calculations and manual
updates. There is also an option to change from system to manual while calculating.
This gives you the means to manage security by protecting system calculations that
cannot be overwritten by manual updates.
To support this, we also provide the O_ACCT dimension in EnvironmentShell by
adding a set of members that store only system calculations. The members are
POWN_SYS, PCTRL_SYS, and METHOD_SYS.
Group formula
An expression that represents the percentage (or formula) to apply to the Destination
Group account from the Eliminations and Adjustments business rule. The value can be
an arithmetic expression combining any defined percentage as defined by the Account
dimension of the Ownership model. All percentages where the property IS_INPUT is
equal to Y can be used. The percentage must be enclosed in square brackets. See the All
formula field above for further details.
Minority formula
An expression that represents the percentage (or formula) to apply to the Destination
Minority account from the Eliminations and Adjustments business rule. An arithmetic
expression combining any defined percentage as defined by the Account dimension of
the Ownership model. All percentages where the property IS_INPUT is equal to Y can
be used. The percentage must be enclosed in square brackets. See the All formula field
above for further details.
Remark
Text for this rule.
1.5.10 Controls
Use
Controls enable you to test the validity of the data gathered in a reporting process. Controls can be applied to any type of data. (See Create a Control.) For
example, a control can be used to check whether assets equal liabilities for data entered in data entry schedules or for adjustments entered in journals.
Controls are run on the data available in the model (in local currency, on base entities). If a dimension is deleted from the model, all control results relevant to that
dimension are also deleted.
Controls are grouped into control sets. (See Create a Control Set.)
The main steps to follow when setting up your controls are as follows:
PUBLIC
Page 75 of 102
Figure 1:
Note
An entity for which no control level is defined is automatically assigned Level 4, meaning all controls are run when a control set is executed. (For more
information on entity control levels, see Control Set Status.)
You manage controls in
You execute controls in
Consolidation Central
Controls Monitor
Rules
Controls
. (See Controls Monitor).
Note
You can also execute tasks in a Business Process flow, provided that the relevant tasks are set up in the business process flow definition.
Prerequisites
To view the Controls page in Planning and Consolidation Administration, you must have the View Controls Manager right.
Features
A control has two output values:
The calculated amount for the control
The control status
Calculated amount
Controls are calculated at the Entity level in local currency.
Control Status
When a control set is executed, the status is a roll-up of the status of all the controls available in this set. (See Create a Control Set.) If any problems are detected
when the controls are run, warnings or errors are generated. A warning does not prevent the data from being validated in the workflow. A blocking error prevents
the data from being validated, meaning the work status cannot be modified for the corresponding category, time and entity members. (For more information, see
Control Set Status.)
Enable controls
Controls are enabled or disabled at the model level in Planning and Consolidation Administration.
Two properties, Control Level and CTRL_CURRENCY_NOT_LC (Bypass LC in ctrls), must exist on the Entity dimension to allow enabling the controls.
Note
To enable controls, Work Status dimensions must be set with at least three main dimensions: Category, Time, and Entity. (See Create a Control.)
Edit Assignments
A control set must be assigned to a Category/Time dimension pair to be executed. (For more information, see Assign Control Sets.)
Activities
To enable controls
PUBLIC
Page 76 of 102
1. In the Controls page, select the model whose control sets you want to enable.
2. Click Enable controls .
3. In the Enable Controls dialog box, select Enable and click OK .
To display the Controls page in Planning and Consolidation Administration
Select
Rules
Controls .
To display a control definition
1. In the Controls page, select the model containing the control(s) you want to view.
2. In the Controls for <Model name> page, click an individual control to display its properties.
To edit assignments for a control set see Assign Control Sets.
More Information
Create a Control Set
Assign Control Sets
Create a Control
Controls Monitor
Control Set Status
1.5.10.1 Create a Control

Prerequisites
An administrator has given you the Edit Controls Manager right.
A value has been specified for the MONTHNUM property in the Time dimension.
Procedure
You create controls in the Controls page of Planning and Consolidation Administration.
To create controls in SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, do the following:
1. Select
Rules
Controls .
2. Select the model for which you want to create a control.
3. Click Open to display the list of existing controls for that model, then click New .
Note
When dimensions are added or removed from the product, control definitions containing a deleted dimension are updated accordingly and are marked as being
invalid for change tracking reasons. Impacted control definitions must be verified. If a dimension is removed from a model, all control results are deleted.
Note
If a driving dimension is added to the Work Status definition, control results are deleted as well as existing locks. This new dimension is also removed from the
control expression, since driving dimensions cannot be used in control expressions. If a dimension is removed from the Work Status, all control data is cleared
and control expressions must be verified accordingly.
The control properties that you can define include:
ID
Description
Type
Equation type
Control Level
Breakdown Dimensions
Tolerance Threshold
Expression
Documents
ID
A control must be identified with a unique code. This field is mandatory.
Control Description
A control description should clearly and concisely describe which verification is being performed and for which reason, and what is the accounting, financial or
economic logic. For example, "Assets = Liabilities".
Control Type
You assign one of the following two control types:
Warning: warns the user of noncritical data quality issues. Does not prevent the user from going to the next work status level.
Blocking: prevents the user from going to the next work status level until the blocking status is cleared.
Equation Type
You choose the operand for the expression: =, >, <, >=, <=, <>. The operand determines how the two amounts in the expression will be compared.
Control Level
This is linked to the Control Level property in the entity dimension. A control level is defined for each control, organizing the controls by rank, so that the relevant
data can be verified.
Four control levels are available:
PUBLIC
Page 77 of 102
Basic: Level 1
Standard: Level 2
Advanced: Level 3
Comprehensive: Level 4
Controls are executed according to the control level associated to the selected entity. (See Execute a Control Set.) If an entity has no control level defined, it is
automatically assigned Level 4, meaning all controls are run when a control set is executed. (For more information on entity control levels, see Control Set Status.)
Breakdown Dimensions
Choose the dimension(s) for which controls should be executed on all members. You can choose up to two breakdown dimensions. Breakdown dimensions allow
you to define controls to be run on any type of data (for example: input, manual adjustments, automatic adjustments).
Example
CTRL1 is defined as TOTAL_ASSET = TOTAL_LIABILITIES, break-down dimension: DATASOURCE with TOTAL_INPUT member specified in the control
expression. TOTAL_INPUT is the aggregation of INPUT, INPUT_ADJ1 and INPUT_ADJ2.
When the control is executed, it compares TOTAL_ASSET versus TOTAL_LIABILITIES for both members INPUT, INPUT_ADJ1 and INPUT_ADJ2. As a
result, if two members generate an error, the following information is generated:
One row appears displaying the aggregated information for the control, without data in any of the columns except for the status, which is Failed.
Two rows below for that given control to display the detailed calculations, with data for both lines.
Note
Any dimension can be used as a breakdown dimension, except for: dimensions used as driving dimensions in the Work Status setting, currency dimensions
and group dimensions.
Tolerance Threshold
The tolerance threshold is an amount, expressed in either absolute value or as a percentage, which is compared to the difference between the two amounts. If the
control result is less than or equal to the member amount defined in the tolerance threshold, then the difference is considered as insignificant and the control status
is OK .
Example
Expression of control for amounts x
and y
Comparison difference/tolerance
Control result
Example
x= y
< Tolerance
Valid
Tolerance entered: 1
Amount x: 1,000,000
Amount y: 1,000,000.5
Difference: 0.5
The difference is less than the tolerance.
The two amounts are therefore considered
equal.
The control, run to check if the two
amounts are equal, is therefore valid.
> Tolerance
Error or warning
x< y
< Tolerance
Error or warning
Amount x: 1,000,000
Amount y: 1,000,000.5
Difference: 0.5
equal.
The control, run to check if x is less than
y, is therefore in error.
> Tolerance and x < y
Valid
> Tolerance and x > y
Error or warning
x> y
< Tolerance
Valid
Error or warning
xy
< Tolerance
Valid
Error or warning
xy
< Tolerance
Valid
Error or warning
Error or warning
Valid
Amount x: 1,000,000
Amount y: 1,000,000.5
Difference: 0.5
equal.
The control, run to check if x is less than
or equal to y, is therefore valid.
Valid
PUBLIC
Page 78 of 102
Expression
The expression is the formula used for identifying the two amounts to be compared. In the Expression tab, the upper panel contains the formula for identifying the
first amount to be compared. All the dimensions must be specified.
When breakdown dimensions are specified, an icon appears in the column header identifying that dimension as a breakdown dimension.
The lower panel contains the formula for identifying the second amount to be compared, which can be from another Category, Time, or Group.
In the Category field you can enter any member from the Category dimension. In the Year Offset field, you can enter an integer preceded by "+" or "-". In the
Period field you can enter an integer which is associated to the MONTHNUM property of the Time dimension. For relative periods, "+" or "-" signs can be used; for
example, for the previous month you enter "-1".
If the lower panel is left blank, the first member of the expression (defined in the upper panel) is compared to zero.
Documents
Microsoft Excel input schedules or reports, as well as Web Input Forms or Web Reports can be attached to aid in resolving issues.
More Information
Execute a Control Set
Control Set Status
1.5.10.2 Create a Control Set

Use
A control set is a grouping of controls. Control sets are associated to a particular model. You can define more than one control set for a model. The controls in a
control set are organized in the order in which they are executed. A control set must be assigned to a Category and Time dimension pair in order to be executed.
See Assign Control Sets.
To create control sets in SAP BusinessObjects Planning and Consolidation, version for SAP NetWeaver, select
Rules
Controls .
Prerequisites
An administrator has given you the Edit Controls Manager right.
Features
Control Set Properties
The control set properties that you can define include:
ID
A control set must be identified with a unique code. This field is mandatory.
Description
A control set should clearly describe the type of verifications to be performed.
Create, Display, Modify, Copy, or Delete a Control Set
You can create a new control set containing a selection of controls by copying an existing control set. This allows you to quickly initialize a control set containing
multiple controls, without having to add the controls one by one. You can then make changes to the copied control set using the Add/Remove function.
Activities
To create a control set
1. In the Controls page, select the model where you want to add the control set and click Edit Sets in the toolbar.
Alternately, click the number in the Sets column corresponding to the model where you want to add the control set.
2. In the Control Sets: <Model name > page, click New in the toolbar.
3. Specify a name and a description for the control set.
4. To add controls to the control set, click Add/Remove in the toolbar.
5. In the Add/Remove Controls dialog box, use the arrows to move controls from the Available Controls list into the Selected Controls list, then click
OK .
6. Save the control set.
Note
A control can be assigned to more than one control set.
To display or modify a control set
1. In the Controls page, click the number in the Sets column corresponding to the model for which you want to display all the control sets.
Alternately, select the row containing the model and click Edit Sets in the toolbar.
2. In the Control Sets: <Model name> page, select the control set that you want to display or modify.
3. To add or remove controls from the control set, click Add/Remove .
4. In the Add/Remove Controls dialog box, use the arrows to move controls between the Available Controls list and the Selected Controls list, then
click OK .
5. Save the control set.
PUBLIC
Page 79 of 102
Note
A control can be assigned to more than one control set.
To copy a control set
1. In the Controls page, select the model containing the control set you want to copy and click Edit Sets in the toolbar.
2. In the Control Sets: <Model name > page, select the control set and click Copy in the toolbar.
3. In the Copy Control Set dialog box, enter a name and description and click OK .
The copied control set contains the same controls as the original control set. You can then make changes to the control set following the steps
described above.
To delete a control set
1. In the Controls page, select the model containing the control set(s) you want to delete and click Edit Sets in the toolbar.
2. In the Control Sets: <Model name> page, select the control set(s) you want to delete and click Delete in the toolbar.
Note
Deleting a control set does not delete the associated controls.
More Information
Assign Control Sets
Execute a Control Set
1.5.10.3 Assign Control Sets

Use
To execute a control set, you must specify when you want your control set to be run and on what type of data, by assigning at least one Category/Time dimension
pair to your control set. Creating a category/time pair consists of choosing at least one category and one period per control set.
To assign category/time pairs to control sets, in Planning and Consolidation Administration select
Rules
Controls . In the Controls page select the row for
the model containing the control sets for which you want to define assignments and click Edit Assignments. Alternately, click the number in the Assignments
column corresponding to the required model.
Features
Display category/time pair assignments for control sets
There are two ways to display the category/time pair assignments for control sets:
Show Categories by Time
You select the option Categories by Time to display the active control sets assigned to each category and period intersection.
In the Assignments grid, the categories are listed in rows and the periods are listed in columns. Assigned control sets appear in the grid in cells at the
intersection of a category and a period.
To modify an assignment, click Edit and double-click in a cell to display the list of available control sets. You can then assign a control set to the selected
category/time pair.
Show Control Sets by Time
You select the option Control Sets by Time to display the category/time pairs organized by each available control set.
In the Assignments grid, the active control sets are listed in rows and the periods are listed in columns. Expand a control set by clicking its arrow to
display the selected categories; in doing so you display the category/time pairs for the expanded control set in the form of a checkbox in each grid cell. If the
checkbox is selected, the control set is run for that category and period.
Note
The Control Sets by Time view is for consultation only. You cannot modify the category/time pairs in this view.
To display additional control sets, click Control Sets and select additional control sets in the Member Selector dialog box.
Display additional periods or categories
You can display additional periods or categories in the Assignments grid. Click Category or Time in the toolbar and make your selections in the Member
Selector dialog box. The additional dimension members are displayed in the grid.
Sorting and moving columns
You can sort the contents of a column by clicking in the column header. A triangle appears, indicating the direction of the sort. Clicking the column header a
second time changes the direction of the sort.
You can change the order of columns in the grid by dragging and dropping them.
1.6 Business Process Flow Management

Use
This function enables you to create and manage business process flow (BPF) templates (or "process" templates) and manage the processes created from these
templates. You can manage business process flows if you have the Manage BPFs task profile.
A process template is the specification of a single enterprise-wide business process, containing tasks that can span across the various modules of Planning
and Consolidation. It defines the business processes that are presented to users as a prepackaged set of application tasks. For an additional level of control over
the workflow, you can integrate work status rules.
PUBLIC
Page 80 of 102
Once you have completed a process template, you can create a process, based on the template, in the Administration screen. A process represents an
iteration of the enterprise-wide business process. It allows the user to see only the tasks relevant for that user, given his or her role and data access privileges.
Example
A process template describes a monthly activity, such as line managers entering monthly actual budget data. You create an instance of the process for each
manager, who enters actual data for a particular department. In this example, the process context has the same time and category, but a different entity.
Therefore, the process context, which is the varying entity, serves as the key for identifying and tracking the instances of the process. It allows the process to
run simultaneously across various operational units.
Features
The following functions are available to authorized users:
Function
More Information
Create new process templates
You can create a new process template on which to base processes, copy existing
process templates, and modify existing templates. For more information, see Creating
New Process Templates.
Archive process templates
You can archive process templates. When you archive a process template, all processes
based on the template must be completed because these are also archived. Archived
process templates appear on the All Templates and Versions list with a current version
of Inactive .
Validate process templates
When you create a new process template, the system automatically validates the
template for completeness before saving the template. The result of this validation is
shown in the Status column. A template can be Valid or Invalid . If it is invalid, you
can revalidate it by selecting the template , and clicking Validate .
Unlock process templates
If a template is locked, as shown in the Current Version column, you can unlock it.
Select the template, and click Unlock .
Deploy a template
If a template is not locked and has a status of Valid , you can deploy it so that it can be
used for creating processes. Select the template, and click Deploy .
View all templates and versions
If you choose All Templates and Versions , the All Templates and Versions window
opens. This lists all the templates, including those that have a current version of
Inactive . An inactive template is one that has been archived.
If you select a template and choose All Templates and Versions , the list will contain all
versions of the selected template.
Manage processes
After a process template has been created, business users can use it to create processes.
After processes have been created, administrators can reset, archive, or delete them. .
1.6.1 Creating New Process Templates

Use
With the correct authorization, you can use this process to create a new process template. You can define up to 100 process templates for each environment.
Process
1.
2.
3.
4.
From the Administration screen, select Process Templates from the left navigation pane.
Select New . The Process Template Designer opens.
On the Process Settings tab, provide details such as name, description, and the controlling model of the business process flow. See Process Settings.
On the Activities tab add activities to represent the flow of the business process. See Activities.
You can create a new activity as well as duplicate an existing activity and then modify it. You can also change the order of activities.
5. You can add actions to define the specific tasks users perform within the activities. See Defining Actions.
An action can be any user authorized task, for example, opening a schedule, publishing a report, or approving entered data.
6. When you save a new process template, the system automatically validates the template to ensure it is properly defined and completed before saving the
template. The result of this validation is shown in the Status column. A template can be Valid or Invalid . If it is invalid, you may need to make changes
to the model before clicking Validate to validate the template.
Template validation is a prerequisite for creating a process.
Note
Validation occurs every time that you click Save . So, if you make an interim save to avoid losing your work, you will probably receive some validation
errors or warnings. You can view these by choosing See Details next to the warning message.
Result
Based on the process template you created, you can generate processes in the Administration screen. See Creating Processes. You can also perform actions on
the process instances. See Process Management.
1.6.1.1 Process Settings

PUBLIC
Page 81 of 102
Use
Before creating a process template, you provide basic information that identifies the process.
The modify process uses the same features as the setup process described in this topic.
Features
The following table describes the information you need to complete the setup process in the Process Settings tab:
Item
Description
Name
The name of the process template.
Description
A description for the process template.
Model
The model that contains the dimensions that are required to define the context, and the
Time dimension you want to use for the processes.
If, for example, you select the Planning model, whose Time dimension is in monthly
increments, the process works in monthly time increments, as well.
The model governs both the time dimension for process instances and the available
dimensions for activity context.
Dimensions
Choose dimensions as follows:

Driving dimension
The dimension that is common to all process contexts that users might use for
completing the tasks in the process. This dimension must have a defined
Reviewer property.
Identity dimension
One or more dimensions common to all processes for this template.
The system automatically selects the Time dimension, since it is required for all
processes.
Users
Choose the users and teams to which the process template applies.
Select the appropriate option to view by team or user. Move the users or teams from the
Users and Roles tabs to the Selected Users and Roles column.
Setting this access allows these users and roles to view the processes, created from this
template, in the process monitor. They cannot perform any actions in these processes.
You define the performer and reviewer roles when you create a process from this
template.
Activities
To create a process template from scratch, choose Business Process Flow Templates in the Administration screen, and choose New . This opens the Process
Template Designer .
You can also use Copy and Edit to create a process template based on an existing template.
To define activities within the business process flow, choose the Activities tab. For more information, see Activities.
1.6.1.2 Activities
Use
You can create activities that form part of a process. For guidelines on defining activities, see Criteria for Defining Activities.
Features
The following table summarizes the information that you need to supply for each activity:
Item
Description
Initial Information
Name
Provide a title for the activity.
Instruction
Provide a description of what is to be done in the activity. This is the instruction that is
displayed to a user performing a process based on this process template.
Dimensions and Users

Driving Dimension
Select the driving dimension.

This is the dimension that is common to all process contexts that users might use for
completing the tasks in the process. This dimension must have a defined Reviewer
property.
For more information, see Defining Activity Context Criteria.
Members
Clicking the members icon opens the Criteria Editor . You can define relationships
among members and add additional criteria as required.
For more information, see Defining Activity Context Criteria.
Performer
Select the property that defines the performer for each member.
To define an action that a performer must perform when reviewing the activity.
A Performer is the person, to whom the activity is provided to at run time, that is the
PUBLIC
Page 82 of 102
person, who has to perform the work items in the activity and mark it as complete. This
can be one or more users, or a team. Performers are determined by a property of the
dimension used as driving dimension of the activity. You can select the "Owner"
property or any other property for this. Owner has a specific meaning in Planning and
Consolidation; it is the dimension property that determines who can change the work
status of each member to anything other than unlocked. So you could choose to have an
activity that is performed by the same owner as work status.
For more information, see Defining Actions.
Require Reviewer
If required, select this checkbox and select a property that defines the reviewer for each
member.
To define an action that a reviewer must perform when reviewing the activity.
You select the reviewer in the same way as selecting a performer, but you can select a
different property to determine the reviewer users.
For more information, see Defining Actions.
Opening Criteria
Opening Criteria
Select the appropriate radio button to open by All activity contexts or Matched activity
contexts.
For more information, see Criteria for Opening Activities.
Allow Reopen
To allow authorized users to reopen an activity, select the Yes radio button.
For more information, see Criteria for Reopening Activities.
Activities
To create a new activity, click New ; to edit an existing activity, select the activity. To copy an existing activity, select the activity, and chose Copy from the
context menu. You are offered the opportunity to duplicate the activity definition and contents, or just the activity definition.
You can preview instances of this activity by clicking Preview Activity Instances .
Once you have defined an activity, you can create a working area where users can add, view, and manipulate data. Choose Create a performer workspace. This
opens a workspace, that is driven by the process and whose driving dimensions are those defined for the activity. In this workspace, you can add any Planning
and Consolidation function for data entry, creating reports, and so on. For more information, see Defining Actions.
You can define a workspace for each activity. You can also choose whether the reviewer uses the same workspace or has a separate workspace for reviewing
this activity.
You can generate activities by selecting properties of the driver dimension.
Logical relationship of selections:
1.
2.
3.
4.
All selections on hierarchy: OR

Same property's selections: OR
Between different property selections: AND
Between hierarchy selections and property selections: AND
Order of activities:
1. If there is a hierarchy selection, follow the preorder traversal of the hierarchy.
2. If there is only a property selection, follow alphabetical order. The operators supported in property selections are equal, not equal, between, and like.
For example, the driver dimension of one step is D, which has hierarchy H1 and H2, and properties P1 and P2. The selections are the following:
1.
2.
3.
4.
5.
Base members of member M1 in H1

Children of member M2 in H2
P1 = 'V1'
P1 between 'V2' and 'V3'
P2 = 'V4'
The members generated as activities will satisfy the logical relationship (1 OR 2) AND ((3 OR 4) AND 5).
1.6.1.2.1 Criteria for Defining Activities

Use
You define activities in the Process Template Designer interface in the Administration screen. For more information, see Activities.
Each process must contain at least one activity.
The following are guidelines for defining activities:
Activities have defined criteria to control the activity context, opening of activities, review criteria, and reopening of activities if required.
You must associate at least one action with an activity.
All activities can have more than one action associated with them. The primary action is the launch action; the additional actions appear in the action pane
when the primary action is launched.
Activities may require approval by a reviewer before the system considers the activity complete.
You must perform activities in sequential order.
Each activity is assigned a driving dimension, which determines the generation (iteration) of the activity by process context. The driving dimension assigned
to the activity is also associated with the owner and reviewer property for each activity context. The owners and reviewers can be modified when you create
a process.
The process owner can finalize the process only when all activities are completed.
Up to one thousand activities per process template or process can be defined.
Up to one million activity contexts per process can be defined. The activity contexts can be calculated as a product of the number of activities and number
of process contexts.

PUBLIC
Page 83 of 102

Use
To complete the creation of an activity in a process template, you must define the activity context criteria for that activity.
Procedure
You define activity context criteria in the Dimensions and Users Area of the Actions tab by performing the following steps:
1. Select the driving dimension. The driving dimensions are displayed according to the model that you selected in the Process Settings tab. Each activity has
only one driving dimension, and this determines which members can be selected for that activity.
2. Set member criteria for the activity context using the Criteria Editor . There is a limit of six member definitions per step:
Select specific valid member IDs from the list. This list is generated depending on the driving dimension you have selected. You can make multiple
dimension member selections.
If you select a parent ID (a node that has subnodes) in the dialog box that appears, you can generate dimension members based on the
dependent ( Children ), or base ( Base Members ) nodes of the parent ID. If you do not select Children , Base Members , or All Members ,
it defaults to Single Member , which just includes the selected node.
Note
Dependent members are all entries one level below the parent node.
Base members are all entries at the lowest level below the parent node.
3. Select the property of this dimension, which contains valid user IDs for the owner. For more information, see Owner Property.
1.6.1.2.3 Criteria for Opening Activities

Use
You select the opening criteria when you are defining activities in the Process Template Designer interface. For more information, see Activities.
Features
When choosing an opening criterion for an activity, consider the following guidelines:
There is no opening criterion for the first activity of a process. The first activity is always open, regardless of how the opening criterion for the activity is
defined in the process template.
When you complete all activities in a context, the next activity automatically opens regardless of the opening criteria.
When you are defining an activity, you can choose the opening criteria to be All or Matched . The following sections describe how these criteria affect activities.
All Activity Contexts
Choosing All Activity Contexts as the opening criterion for an activity introduces the following constraints:
All activity contexts must be completed before the next activity opens.
Use with matching driving dimensions, or different driving dimensions.
Use this option when you have matching driving dimensions, but different activity contexts between activities.
Example
You must complete all tasks for all activity contexts in activity 1 before activity 2 opens:
Activity
Driving Dimension
Activity Context
Status
Entity
Italy
Complete
Entity
France
Open
Entity
Italy
Pending
Entity
France
Pending
Matched Activity Contexts

Choosing Matched Activity Contexts as the opening criterion for an activity introduces the following constraints:
When you complete an activity context, the next activity opens for that same activity context.
Use with matching driving dimensions only.
Do not use when you have matching driving dimensions, but different activity contexts between activities.
Example
The matched activity context opens in activity 2 when you complete the tasks for the corresponding activity context in the first activity. All tasks for the other
activity contexts are pending:
Activity
Driving Dimension
Activity Context
Status
Entity
Italy
Complete
Entity
France
Open
PUBLIC
Page 84 of 102
Entity
Italy
Open
Entity
France
Pending
1.6.1.2.4 Criteria for Reopening Activities

Use
You enable the reopen function when you are defining activities in the Process Template Designer interface. For more information, see Activities.
Features
When choosing a reopening criterion for an activity, consider the following guidelines:
The Allow Reopen checkbox must have been selected in the previous activity, which is the activity that you want to reopen.
The reopen function is only available for (the previous activity) the activity prior to the one that is now active (the current activity); you cannot reopen an
activity that is not consecutive.
The final activity cannot be reopened.
You must be an owner or reviewer in both the current activity (active activity) and the previous activity to be able to reopen that activity. If you are the
process owner you can reopen an activity, regardless of owner or reviewer assignment, from the process monitor.
You cannot specify which activity context to reopen, it is an activity operation.
The following sections describe how All and Matched criteria affect activities.
All Activity Context
Choosing All Activity Contexts as the reopening criterion for an activity introduces the following constraints:
You must be a participant in at least one activity context of the previous activity.
(The process owner can ignore this).
You must be a participant in at least one activity context of the current activity.
The opening criterion of the current activity is All .
The current activity must be fully active, which means that all the activity contexts of the current activity must be Open , Reopened , Rejected , or
Submitted .
Example
When you reopen activity 1, all activity contexts for activity 2 change to status Delayed :
Activity
Driving Dimension
Activity Context
Owner
Reviewer
Status
Entity
US
Reopen
Entity
Canada
Reopen
Entity
US
Delayed
Entity
Canada
Delayed
Matched Activity Context

Choosing Matched Activity Contexts as the reopening criterion for an activity introduces the following constraints:
You must be a participant of the matched activity context in the previous activity to reopen that activity context.
You must be a participant of the matched activity context in the current activity to reopen that activity context in the previous activity.
The opening criterion of the current activity is Matched .
The current activity must be an active activity , which means at least one of the activity contexts of the current activity must be Open , Reopened ,
Rejected , or Submitted .
Example
When you reopen activity 1, activity context Canada reopens. Canada changes to status Pending in activity 2.
Activity context US does not reopen as it is already complete in activity 2 - the activity context must be active in the current activity to reopen it in the previous
activity:
Activity
Driving Dimension
Activity Context
Owner
Reviewer
Status
Entity
US
Complete
Entity
Canada
Reopen
Entity
US
Complete
Entity
Canada
Delayed

PUBLIC
Page 85 of 102
Use
The owner designating dimension property is created in any dimension used as a driving dimension for a business process flow. You add the property to the
dimension with any name. We recommend using a naming convention that denotes the relationship to business process flow owners. A dimension can have one
or more owner designating properties as long as each is unique.
For example, if your business process dictates that an entity is the differing factor when it comes to entering data, the Entity-type dimension is the dimension that
drives the owner of the activity context. If your business process dictates that a department name is the differing factor, the Department dimension would have a
unique owner designating property that drives the owner of the activity context. The "Owner" property used for work status is a reserved property. The business
process flow owner properties must be named with a unique name.
Prerequisites
The dimension you select to drive must have at least an owner type dimension property. When more than one exists, you choose the appropriate property to use
in the business process flow.
Features
The owner designating property takes user and team names in brackets as values. You can enter multiple names and teams separated by commas. You must
also include the domain or server name in the path.
Activities
You do the following to set up an Owner property:
Set up the owner property by accessing the Dimension Library, choosing Maintain Dimension Property , and adding an owner.
Assign the owner property to a dimension by accessing Maintain Dimension Members . Define the owner property on a dimension such as Entity, then
define the property values. You can enter multiple names and teams separated by commas. You must also include the domain or server name in the path.
1.6.1.3 Defining Actions

Use
You can assign actions to activities. You can also assign review actions to activities, which require the approval of a reviewer.
Prerequisites
Activities have been defined in the Process Template Designer interface.
Procedure
You create action for an activity in the Workspaces section of the Activities tab.
1.
2.
3.
4.
Choose New to create a new performer workspace. A new workspace tab opens with the same name as the activity.
Select Add View and choose the layout that you require.
Drop the required elements into your view and configure according to the desired outcome.
Use the context menu of the new view to create an appropriate title for the action.
Repeat for all the actions to be associated with each activity in the process template.
You can specify that the reviewer uses the same workspace or that a reviewer has a specific workspace, which you can define in the same way.
Result
You have defined actions for your activity.
1.6.2 Creating Processes

Use
An authorized user can create a process in the Administration screen. This activates a process template using a specific process identifier, which enables enduser participation in the process. It also establishes the process owner.
Note
You can create up to 24 processes for each process template.
Generating a process creates all required activities and activity contexts. Once generated, the process is no longer associated with the template. Any changes to
the template definition do not impact previously generated processes.
Prerequisites
A process template has been created, validated, and deployed.
PUBLIC
Page 86 of 102
Procedure
In the Process Instances screen, choose New . This opens the New Process wizard that has the following steps:
1. Select the process template.
2. Choose the process owner.
3. Select context.
Select the category and time that define the context.
4. You can change the performer or reviewer for each activity.
Select an activity and click Change Performer or Change Reviewer as appropriate and choose a different user or team.
5. Review the process, select Start the process and click Finish .
The title of the created process is derived from the process template name and the context of the process.
Result
You have created a process. Click Refresh in the Process Instances screen to add the new process to the list; it is displayed with a status of Active .
You must manage the process and activate it before a user can see it in the interface. For more information, see Process Management.
1.6.3 Process Management

Use
You can perform actions on processes in the Process Instances screen.
Prerequisites
A process template has been created and a process has been generated from that template.
Features
You can perform the following functions for a process:
Function
Description
Start
To activate a process. This is normally only necessary to restart a suspended process.

The status changes to Active .
Suspend
To deactivate an active process, or a process waiting for finalization. The status changes
to Suspended . The process can be reactivated using Start .
An inactive process does not appear available for users and can only be seen in the
Administration screen.
Complete
A reviewer or process owner can mark a process as completed.

The status changes to Finalized .
Change Assignments
The Change Assignments wizard allows you to change the process owner and an
activity owner.
Reset
To reset processes back to activity 1, choose Reset . The system resets the status within
a process so that users must perform the steps again. It does not, however, reset
changes made to your metadata or transaction data.
Archive
To archive finalized or inactive processes, choose Archive.

An archived process does not appear available for users.
Refresh
To refresh the display when changes have occurred.
1.7 Features
Use
The following additional features are available in SAP Business Planning and Consolidation, version for SAP NetWeaver:
Work Status Setup
Journal Administration
Context Defaults
Drill-Through Setup
Document Types and Subtypes
Auditing
Time-Dependent Hierarchies
Parallel Execution
1.7.1 Work Status Setup

PUBLIC
Page 87 of 102
Use
This function allows you to lock a region (or slice) of data in a model. The work status setting overrides the member access privileges of a user to write to a given
region. A region of data is defined by three to five dimensions per model, one with property called Owner.
When you set up work status, you define the following:
Work Statuses - The codes that refer to a physical status of data (such as Submitted)
Level of security - The users or teams who can change data in the system, which is All , Locked (no one), Manager , or Owner . See Controlling Who
Can Change Data below.
The users or teams who can change the work status, which is Owner , Manager , or Owner and Manager . See Controlling Who Can Set Work Status
below.
Method of data update - The manner in which the customer updates data. See Method of Update below.
Push - Equivalent to the check box Include all children when setting work statuses, the option allows you to set one work status code to all children of a
member. This does not set the selected parent member.
After you set up work statuses, users can use them to apply a label to a current view and lock its data for review, approval, and so on. For example, your monthend close business process requires that a specific set of data is locked down so that accurate month-end reports can be created. After a data submission, the
owner sets the work status to Submitted. This locks the data intersection from subsequent submissions.
Prerequisites
To use this function, you must specify in the Base Hierarchy column of the work status dimensions the hierarchy (H1, H2, H3, ..., Hn) that uses work status
rules. See Setup of Work Status Dimensions.
Features
Controlling Who Can Change Data
You define who can change the data in the system:
All - All users with the appropriate member access rights can change data
Locked - No one can change the data
Manager - Only managers (parents of owners) can change data
Owner - Only owners can change data
Controlling Who Can Set Work Status
You define who can set the set the work status for a region of data:
Owner and Manager - The owner of the specific member ID and the owner of the parent to the specific member ID
Owner - The owner of the specific member ID
Manager - The owner of the parent to the specific member ID
Owner / Manager Determination:
Parent member owners act as an owner for that specific parent member ID
Parent member owners act as a manager for their direct children - the parent owner can change any specific direct child work status; can be both parent
and base members
When using Include all children - the owner of a parent can update all children (all levels) below
Base (leaf) members owners act as owner only
Members (top of a hierarchy) that have no parent but have children act as their own manager in addition to owner
Controlled By Rule
An owner is defined by only one dimension hierarchy, the OWNER dimension
A work status can be set on a specific single member ID, where the manager does not use Include All Children
A work status can be set on a series of member IDs, where the manager uses Include All Children
Setting the Work Status:
If the user is acting as an owner, they can select a work status controlled by Owner or Owner and Manager.
If the user is acting as an owner and the selected member has no parent, the user also acts as a manager (top of the hierarchy) and they can select a work
status controlled by Owner, Manager or Owner and Manager.
If the user is the parent owner in the role of Manager, then they can use the Include All Children option (to push the work status to children). This option is
not valid for a base member, the Owner role.
Consecutive Work Status Rules
You can set work status in a forward direction (progressive) or in a backward direction (regressive)
For a user acting as an Owner, the order matters
The user can only select the next (forward) work status that is controlled by either Owner or Owner and Manager
The user can select the previous (backward) work status that is controlled by either Owner or Owner and Manager
The user cannot select a work status that skips a work status controlled by Manager, either forward or backward
For a user acting as a Manager, the order does not matter
The user can only select a work status that is controlled by either Manager or Owner and Manager, either forward or backward
The user can select a work status that skips a work status controlled by Owner, either forward or backward
If you expand all records on the non-OWNER dimensions only, and find the current work status on each record, the model checks each and every
expanded record for the rules. If one record fails, the whole request is ignored
Bottom-Up Rule
A parent work status cannot be higher than its children (order matters)
The order of work statuses is determined top to bottom in the work status code screen. The first code is 0, the next code is 1, and so on.
A child can have a work status that is greater than or equal to its parent
For a user acting as owner:
If a child is set to Submit, it parent cannot be set to Approve.
If one or more children have a work status that is lower than the work status being set for a parent (forward), then an error appears
PUBLIC
Page 88 of 102
If the parent's work status has a higher work status, an error appears if you attempt to regress a child's work status (backward)
The rules above also apply when the user is acting as a Manager (where Include All Children is selected or the Manager sets a specific child work
status)
For all expanded records (non-OWNER dimensions), the immediate parent is checked to verify that it has a work status that is less than or equal to its
children. If one child fails this rule, all fail.
Method of Update
The areas of Planning and Consolidation for which you can control the level of security are as follows:
Data Manager ( DM ) - Controls data input from running a Copy, Import, or Move package
Journal ( JRN ) - Controls data input from posting journal entries
Manual Entry ( MAN ) - Controls data input manually
Comments ( COM ) - Controls data input from posting comments (unstructured data)
Documents ( DOCS ) - Controls posting documents with model context to the Document view (unstructured data)
Defining Work Statuses
Work statuses (or work status "codes") are defined for the entire environment (not per model). There is no limit to the number of codes you can create, but there is
a practical limit.
There is a default work status that must be first and cannot be changed. It has an internal code of 0 and is controlled by the Manager and Owner ( Controlledby
is set to Owner and Manager ). You can change the method of update for this code, but not the order or the Controlledby value. You can change the text
description.
The default code allows you to have a customized behavior for the environment. For example:
LOCKED for all methods is equivalent to preventing any data update until the work status is advanced to the next status (1)
ALL for all methods is equivalent to having all data open for update - this is the current and default behavior
SETUP applies to ALL of the models in the environment
WRITEBACK always checks for locks; if there are no locks in the lock table, the system behaves based on the setup of status (0)
Work status codes must be 20 characters or less, and their descriptions are limited to 40 characters (this is the same as a member ID).
You can change the order of work status, but once you change it, the system deletes all locks for all models in the environment. Deleting codes also deletes all
locks. Adding codes to the bottom of the list, changing a code definition, does not impact existing locks, but may impact business users. We recommend this only
during the testing phase.
For information about how to set up work status dimensions, see Setup of Work Status Dimensions.
Work Status Rules
The following rules describe work status behavior:
The default method for managing work status is bottom-up. That is, the status of a parent cannot be higher than the status of its children. (NetWeaver does
not support top-down)
The maximum status a parent can be set to is the lowest status of its immediate children.
If the status of a parent is set to Locked, you cannot unlock the children.
The minimum status a child can be set to is the status of its immediate parent. For example, if the parent status is Submitted, the child status must be at
least Submitted.
The owner of an entity can set the work status to any status designated as an Owner status.
The manager of an entity can set the work status to any status designated as a Manager status.
A manager is the owner of a parent-level member. The owner of a parent level member is the manager of all its descendants.
When setting a lock on the parent members of multiple dimensions, locks are set for all members under all parents (specifically, the Cartesian product is
stored as locked). For example, the following table shows the locks that are set when including all children for entity:p1, category:actual and time
2009.Q1.
Entity
Category
Time
Work Status
Child1
Actual
2009.Jan
Upload
Child2
Actual
2009.Jan
Upload
Child1
Actual
2009.Feb
Upload
Child2
Actual
2009.Feb
Upload
Child1
Actual
2009.Mar
Upload
Child2
Actual
2009.Mar
Upload
If you reorder work status codes in the Admin client, all locks are deleted. This also applies deleting a work status.
A parent value for a non-OWNER dimension is not stored. When the user selects a parent for a non-OWNER dimension, it is expanded to all base
members, and only stores the base members.
A parent value for the OWNER dimension is stored. For example, the following table shows what is stored for entity:p1, category:actual and time
2009.Q1.
Entity
Category
Time
Work Status
P1
Actual
2009.Jan
Upload
P1
Actual
2009.Feb
Upload
P1
Actual
2009.Mar
Upload
When applying rules, if the model encounters any error, it rejects the entire user request. In this case, no records are updated.
Sending E-mail Notifications to Owners and Managers
The system can send an e-mail notification to owners and managers to notify them when a change occurs in a work status.
Activities
You create work statuses to reflect the status of data as it moves through your business processes, such as unlocked, submitted, and approved. No predefined
work statuses exist within Planning and Consolidation. In the Administration screen, choose
Features
Work Statuses
New .
PUBLIC
Page 89 of 102
You can modify the order in which work statuses display in the system by choosing Reorder .
You can delete a work status that is not currently in use by selecting the work status and choosing Delete .
You can compose an e-mail notification to owners and managers and indicate whether to notify them if a work status has changed by choosing Notifications .
You can enable as well as view data lock settings by model on the lower half of the Work Status screen. To enable or modify them for a model, select the model
and choose Edit . You can enable data locking and select the dimensions to lock the process context, or disable data locking.
More Information
Setup of Work Status Dimensions
Work Status Example
1.7.1.1 Setup of Data Locking Settings

Use
Use this function to set up data locking settings for each model, which involves identifying 3 to 5 dimensions that define the variables in your business process.
Features
Use the following rules to define the dimensions used in data locking settings:
Specify a minimum of 3 and a maximum of 5 dimensions from the environment.
The dimensions should be variables in your business process, such as entity, category, and time. These are dimensions whose members change based
on who is submitting data. For example, the time dimension is typically a data locking dimension, since data is segregated based on time.
Dimensions such as account, data source, reporting currency, and so on, typically remain static, so those are considered non-data locking dimensions.
An Account-type dimension cannot be defined as a data locking dimension.
The dimension that contains the Owner property must be defined as a data locking dimension. For more information, see Owner Property.
Activities
1.
2.
3.
4.
In the Administration screen, choose

Features
Work Status .
Choose the model for which you want to enter data locking settings, then choose Edit .
Select Enable Data Locking , and set the dimensions you want to use.
Save your changes.
More Information
Work Status Setup
Work Status
Owner Property
1.7.1.2 Work Status Example

Use
The following setup is used for the examples.
Work status codes
Default code is set to Both.
All methods are open, that is, set to All.
Work State
DM
JRN
MAN
COMM
DOCS
ControlledBy
Locks Not Set
All
All
All
All
All
Both
Started
All
All
All
All
All
Owner
Upload
All
Locked
Locked
Locked
Locked
Mgr
Submit
Locked
Owner
All
All
All
Owner
Journal
Locked
Locked
Locked
All
All
Owner
Approve
Locked
Locked
Locked
Locked
Locked
Mgr
Model work status dimensions

Entity is used as the owner dimension.
Dimensions with Yes are non-owner dimensions.
Remaining dimensions are not considered when defining the scope or region of the lock.
Code Model Dimension Name
Work State
CATEGORY
Yes
ENTITY
Owner
PUBLIC
Page 90 of 102
P_ACCT
No
P_ACTIVITY
No
P_DATASRC
Yes
RPTCURRENCY
No
TIME
Yes
Entities structure
Owner of Top entity L1 is the tester's internal user ID (I#).
Remaining parents and children have test owners to help demonstrate the example.
ID
CURRENCY
DESCRIPTION
OWNER
PARENTH1
L1
EU
Top
SAP_ALL\I815086
LD1
US
Parent 10
DEVWDF46\TESTUSERC
L1
L9000
US
Parent 19
DEVWDF46\TESTUSERD
LD1
L9100
US
Child 191
DEVWDF46\TESTUSERE
L9000
L9200
US
Child 192
DEVWDF46\TESTUSERE
L9000
L9300
US
Child 193
DEVWDF46\TESTUSERE
L9000
LD2
US
Parent 20
DEVWDF46\TESTUSERF
L1
L8000
US
Parent 28
DEVWDF46\TESTUSERG
LD2
L8100
US
Child 281
DEVWDF46\TESTUSERF
L8000
L7000
US
Child 201
DEVWDF46\TESTUSERF
LD2
Examples
To begin, a user enters data into the model.
This example uses data for children of entity member L1 .
There are no locks set, so data can be entered freely.
Lock is set by owner
1. Owner TestUserE can set their own entity L9100 , and set a parent level non-owner dimension member 2008.Q1 .
2. However, the owner cannot view the current status of the entity L9100 and 2008.Q1 since the state is expanded to the child members for non-owner
dimensions (no storage of parent members for non-owner dimension).
3. The owner can view the individual state by the base member 2008.JAN .
An owner must set Controlledby work states in consecutive order. Upload can be set to Submit, but not to Journal, as the next work state after Upload is Submit.
This is also true in reverse: an owner cannot set a Controlledby owner work state that is not in order. You cannot set Journal to Started as this violates two rules:
The state before Journal is Submit. Therefore, this is the only valid selection possible.
Upload is a Controlledby Mgr work state, and is in between the Submit and Started work states. The owner cannot skip a Mgr work state.
Lock is set by manager 1
As the first status is an Controlledby Owner status, which is defined as open ( Locks Not Set), the next step is to have the manager progress to a locking
status of Upload.
1. Sign on as TestUserD , the manager of L9100 (owner of L9000 ).
2. Do not choose Include children in the data region . As a manager, you can update the status for individual members as long as the status is set to
Controlledby Mgr.
3. You cannot update the data after the lock is set, as this status locks out manual data entry.
Lock is set by manager 2
1. Sign on as TestUserC , the manager of LD1 (owner of L9000 ).
2. Attempt to set Controlledby Mgr work state for a specific child of L9000 (for example, L9100 ).
Only an immediate parent can set individual children. An error appears: User is not an owner/manager, work status cannot be
updated.
If you choose Include all children in data region , you can set all children (multi-level setting).
Controlled By Rule
1. Parent L9000 is set to Locks Not Set.
2. If the parent owner attempts to set the work state to Approve, this violates the Controlledby rule as Approve is a Mgr work state. An error appears: The
Controlledby rule is violated.
Note
The owner of a parent is not its own manager (the only exception to this is the top member of the hierarchy).
Bottom Up Rule
Parent L9000 is set to Locks Not Set.
Child L9100 is set to Upload; other children are set to None.
1. The owner of parent L9000 attempts to set to the work state to Started, which is Controlledby Owner.
2. This fails due to violation of the bottom up rule: a parent cannot have a status higher than its children. An error appears: The Bottom-up rule is
violated.
Pushing 1
L9000 , a parent owner (manager), can set the work state of all of its children using Include children in the data region .
PUBLIC
Page 91 of 102
1. A manager can skip work states, but they must be Controlledby Mgr.
2. If a manager selects a work state that is Controlledby Owner, this violates the Controlledby rule.
3. If the user setting the work state is neither the owner nor the manager of either the specific member or children of the specified member, an error appears:
User is not an owner/manager, work status cannot be updated.
Pushing 2
L9000 , a parent owner (manager) can set the work state of all its children using Include children in the data region .
The parent member work state is not set when Include children in the data region is chosen.
Only the parent of L9000 ( LD1 ) can set a Controlledby Mgr work state.
Reversing
Assume all children of LD1 are approved for 2008.Q1 (JAN, FEB, MAR).
1. The owner of a child member cannot set a work state lower than their parent. This violates the Bottom-up rule.
2. A parent can reverse the status to any of the Controlledby Mgr work states.
All Regions Must Pass Rule
Assume all children of LD1 are set to Approve for 2008.Q1 (JAN, FEB, MAR).
1. The parent sets all base members for Jan to Locks Not Set.
2. The parent sets remaining months to Approve.
3. The owner of one dimension attempts to set Q1 to Started. This fails because it violates the Bottom-up rule for two months (February and March).
1.7.2 Journal Administration

Use
Administrators set up and manage the Journals component of SAP BusinessObjects Planning and Consolidation.
Prerequisites
Before users can adjust data in the database using the Journals feature, an administrator must perform the following tasks:
Define a journal template. See Journal Template Creation.
Define journal security. See Journal Security.
Set journal model parameters. See Journal Model Parameters.
Features
Administrators can define special rules for using journals, such as the following:
A special work status that prevents data changes from SAP BusinessObjects EPM solutions, add-in for Microsoft Office data sends and allows only
changes made by journals. See Data Modification by Journal Entries Only.
Logic that is specific to journal postings. For the Microsoft version, see Script Logic. For the NetWeaver version, see Script Logic.
More Information
Journals
1.7.2.1 Journal Template Creation

Use
A journal template is an input form into which users enter journal entries. You can set up one journal template for each model.
Features
A journal template consists of the following:
Headers
Header dimensions, which are fixed, constant dimensions for all journals in a model.
The header dimensions set in a journal template become page keys for journal entries based on that template. The template header must always
include one dimension. Model dimensions that are not part of the header become detail dimensions for which users add line items when creating a
journal entry.
Additional header items containing clarifying information that are saved with the journal entry. These items are free text entry fields (limited to 60
characters) or lists of entries from which users make a selection. Alternatively, an additional header can be defined as a Date.
Adding additional header items is not required when creating a template, and if they exist in a template, users are not required to complete them. The
maximum length of an additional header item is 20 characters.
Detail dimensions, which are the remaining dimensions that are required to change the model data via the journal entry. The Account and Flow
dimensions are always included in the detail section of a template.
Detail dimensions are in columns, so each row under the dimension name becomes a detail line. You fill in members for each of the dimensions and
the debit or credit amount for that detail line. The maximum number of detail lines is determined when you create the journal entry.
Two additional options are available for detail header dimensions:
Balanced by Entity : If you select this option, for each entity in the journal entry, credits must be equal to debits.
Balanced by Currency : If you select this option, for each currency in the journal entry, credits must be equal to debits. There can be multiple
reporting currencies in a journal entry.
PUBLIC
Page 92 of 102
Note
If you have already created a journal template, creating a new template that changes the structure of the journal entries deletes the old template and all
journal entries associated with that template. This removes your audit trail, even though changes made to the model data (cube data) through posted
journal entries are maintained. If you recreate the journal template, all transaction data is deleted. However, if you add or remove one or more dimensions
from a model, the corresponding journal template is automatically updated and the journal entries are maintained.
Reopen Rules
Define translation information for the dimensions used in the reopen tasks. For more information, see Journal Reopen Rules.
Activities
To create a journal template for a model:
1.
2.
3.
4.
Select
Features
Journal Templates .
Select the row containing the model for which you want to create the journal template, then click New in the toolbar.
Select header dimensions and modify the order of the header and detail dimensions if desired.
Add additional header items if necessary.
Note
To create extra header text fields in a template and to change the header text fields to selection boxes, define sub-items for one of the additional header
items.
5. Define reopen rules.
6. Save and close.
More Information
Journals
Journal Reopen Rules
Journal Model Parameters
1.7.2.1.1 Journal Reopen Rules

Use
Before you can reopen journal transactions, you must define translation information for the dimensions used in the reopen tasks. The translation table defines the
Source and Destination accounts. You typically do this for specific accounts, but you can create translations for other detail dimensions.
Features
When you open the translation table for the first time, the system opens a default table based on the journal template of the environment. The default value is *,
which is interpreted as any dimension member. You can modify the table as needed.
The table is divided into two column groups: Source and Destination . The individual columns in each of these column groups are described below:
Column Heading
Description
Account Type
Displays the four required account types: AST, EXP, INC, and LEQ . The first time
the system creates the translation table for a model, it uses these required account types.
You can add additional account types by adding new rows, but these account types must
remain in the table.
<Filtering Property>
Select the filtering property from the Filtering Property dropdown list above the table.
<Source dimension members>
One or more columns that were selected during the template creation.
Column Heading
Description
Sign
Enter plus ( +) to keep the value in the same credit or debit position. Enter minus ( -) to
switch the value from the debit to credit, or credit to debit position.
<Target dimension members>
One or more columns that were selected during the template creation.
Activities
To define journal reopen rules:
1. Select
Features
Journals .
2. Select the row containing the model whose journal template you want to open, then click Open in the toolbar.
3. Select the Reopen Rules tab. Insert a new row for each additional account type (AST, LEQ, INC, EXP) by choosing the Add button. Remove rows by
choosing the Remove button.
4. For each account or dimension you want to convert, enter the source and destination member IDs' under the associated dimension.
More Information
Reopen Journal Entries
PUBLIC
Page 93 of 102
1.7.2.1.2 Journal Model Parameters

Use
You use model parameters to define conditions for journals.
Features
The following three journal parameters are available:
Enforce Balanced Journals
Select this parameter to specify that journals must be balanced when they are posted.
When selecting this parameter this affects all the journals that are generated from the given template. If you only want some of the journals to be balanced,
you must set this separately for each journal entry.
Allow Journals to be Reopened
Select this parameter to allow users to reopen journals. If selected, the Reopen button appears in the toolbar in the Journals page of Consolidation Central.
Activities
To set up journal model parameters for a model:
1. Select
Features
Journals .
2. Select the model whose journal parameters you want to modify and click Journal Parameters in the toolbar.
3. Make your selections in the Journal Parameters dialog box and click OK .
Note
By default, the parameters are not selected.
1.7.2.2 Journal Security

Use
Journal security is a component of task security that uses model member access rights to enforce your journal creation and posting policy.
Features
Journal security involves defining users that can administer (AdminJournal), create (CreateJournal), post (PostJournal), or unpost (UnpostJournal) journal entries.
With AdminJournal rights, a user can create templates and clear journal tables (see Journal Template Creation and Delete all Journal Entries from Model).
You set up journal security in Planning and Consolidation Administration.
Activities
Set up journal task security by performing the following steps:
Create journal task profile:
1. Select
Security
Task Profiles
and create a new task profile by clicking New in the toolbar.
2. In the Assign Tasks step expand the Journals folder in the Available Tasks list, then select one or more journal tasks.
3. Once you have reviewed the task profile, click Finish to create it.
Assign journal task profile to a user:
1. Select
Security
Users , select a user and click Edit in the toolbar.
2. In the Task Profiles tab, click Add/Remove in the Assigned to User list.
3. In the dialog box, choose the required journal task profiles from the Available Profiles list and add them to the Selected Profiles list.
4. Click OK .
Note
If users have create access but not write access to a data region, they cannot create journal entries for that data region.
Note
To assign one or more journal task profiles to multiple users, create a team and add the required users by selecting
Security
Team
in Planning and
Consolidation Administration. Once created, open the team for editing and in the Task Profiles tab, add the required journal task profile(s) to the team.
1.7.2.3 Delete All Journal Entries from Model

Use
You can delete all journal entries from a model database before moving from a development environment to a production environment. You delete journal entries
from a model in Planning and Consolidation Administration.
PUBLIC
Page 94 of 102
Caution
Although changes that were posted to the database by journals remain, deleting the journal entries removes the journals themselves and their audit trail from
the model.
Prerequisites
You have AdminJournal rights.
Activities
To delete all journal entries from a model, do the following:
1. Select
delete.
2. Click Delete Journals .
All journals for the model are deleted.
Features
Journal Templates
, and select the row of the model whose journals you want to
1.7.2.4 Limits to Dimension Members for Journal Entries

Use
You can limit the number of dimension members that are available to users during journal entry. All base-level members that the user has access to are
available when the user fills out a journal template. By using the EnableJRN property for a dimension, you can limit the members available to users when they
double-click member cells in the journal template.
Features
You can limit journal dimension member lists by adding the property EnableJRN to the dimension for which you want to limit journal access. Then, in its
dimension sheet, type a Y in the EnableJRN column of base-level members for which you want to allow users to post journal entries. Repeat this for each
dimension you want to limit, then process the dimensions.
Example
You might want only some account members used for journal entries, regardless of whether the users have access to other members.
1.7.2.5 Data Modification by Journal Entries Only

Use
You can set a work status to lock data so users are limited to modifying data only through journal entries , not input schedules.
Features
This enforces a separation between SAP BusinessObjects EPM solutions, add-in for Microsoft Office input schedules that send data to the database and your
review and analysis phase where all data modifications are made by journal entries.
Activities
To lock data so business users can modify it in journal entries only, do the following:
1. Set up a work status code to lock out EPM add-in for Microsoft Office changes to entities. During this process, assign owner and manager rights to set
status to journal changes only.
2. Since owners or managers set work status, entities can be set for journal input only. You can test this by logging into SAP BusinessObjects Planning and
Consolidation with a manager ID, setting the status for an entity to Journal Only , then trying to send data to that entity via an input schedule and a journal
entry.
Example
Set up a code named Journal Only , in which the entity owner can change a status from Unlocked to Submitted and set it back to Unlocked if desired. The
manager can change it from Submitted to Journal Only, which locks the data from changes by EPM add-in for Microsoft Office input schedules or Data Manager
data loads, but allow changes by journal entries. The manager can then set the status to Approved, which locks changes from any source, including journals.
1.7.2.6 BAdI for Generating Calculated Amounts When Saving a

Journal
Use
When saving a journal, you can add or calculate extra amounts by implementing the Business Add-In (BAdI) UJJ_CALCULATED_AMOUNT.
PUBLIC
Page 95 of 102
Features
Enhancement Spot
The BAdI is defined in the following enhancement spot: UJJ_CALCULATED_AMOUNT.
When implementing a new BAdI, a filter must be set with the following parameters:
Appset_id: Model ID
Application_id: Environment
Sample BadI Implementation
A sample implementation is located in the following implementation spot: CALCULATED_AMOUNT_SAMPLE_IMPL.
In the sample, when P & L entries are made, the resulting net profit (loss) impact is generated on the Balance Sheet retained earnings account. This impacts the
closing balance flow, every time a balance sheet account is booked.
Interface to Implement
You implement the following interface: IF_UJJ_CALCULATED_AMOUNT.
Method CALCULATE_AMOUNTS:
Import Parameter
Description
IT_JOURNALS Type UJJ_T_BADI_CA_JOURNAL
A table containing the list of journals to be saved.
Export Parameter
Description
ET_CALCULATED_AMOUNTS Type UJJ_T_BADI_CA_JOURNAL_AMOUNTS
A table of calculated amounts containing the amounts to be added to the journal list. The
output journal ID must match the input journal list.
Caution
When returning a table of calculated amounts, these amounts must contain only the values for the detail dimensions. If you set a value for a header dimension,
the BAdI returns an error.
Exception
Description
CX_UJJ_EXCEPTION
A journal exception that may be thrown.
Data Types
UJJ_T_BADI_CA_JOURNAL
Table for UJJ_S_BADI_CA_JOURNAL.
UJJ_S_BADI_CA_JOURNAL
The following fields are defined in the structure:
Field
Type
Description
APPSET_ID
UJ_APPSET_ID
Environment ID
APPL_ID
UJ_APPL_ID
Model ID
JRN_TMPL_ID
UJJ_JRNTMPL_ID
Journal Template ID
JRN_ID
UJJ_JRN_ID
Journal ID
DESCRIPTION
UJ_DESC
Description
USERC
UJ_USER_ID
The user who saves the journal
DATEMODIFIED
TIMESTAMP
The modification date
USERP
UJ_USER_ID
The ID of the user who has posted the journal
DATEPOSTED
TIMESTAMP
The posted date
STATUS
UJ_DESC
The status of the journal
IDJ_AUTO_REV
UJ_ID
The auto reversed ID
IDJ_OLD
UJJ_JRN_ID
The original ID of the journal
IDJ_GROUP
UJJ_JRN_ID
The ID of the group to which the journal belongs
AUTO_REVERSED
UJ_FLG CHAR
True if the journal is automatically reversed
MUST_BE_BALANCED
UJ_FLG
True if the journal must be balanced to be saved
MAY_BE_REOPEN
UJ_FLG CHAR
True if the journal may be reopened
EDITABLE
UJ_DIM_MEMBER
Multiple header dimension of a journal group
VARIABLET
UJ_DIM_MEMBER
Multiple value dimension ID
AMOUNTS
UJJ_T_BADI_CA_AMOUNT
Table of amounts
EXTRA_FIELDS
UJJ_T_KEYMEM
Table of additional headers
IS_BALANCED
UJ_FLG CHAR
True if the journal is balanced
PUBLIC
Page 96 of 102
Table for UJJ_S_BADI_CA_AMOUNT.

UJJ_S_BADI_CA_AMOUNT
Field
Type
Description
REMARK
UJ_STRING
Remark
AMOUNT
UJ_KEYFIGURE
The value of the amounts
DEBITCREDIT
UJJ_DEBITCREDIT
Set the value to:

C: if the amount is a credit
D: if the amount is a debit
UJJ_T_KEYMEM
This table contains the list of dimensions that defines the

journal amount. Both detail and header dimensions are
included in this table.
Field
Type
Description
TABKEY
TABKEY
The dimension ID
MEMBER
UJ_VALUE
The member value
IS_HDR_FLD
UJ_FLG CHAR
Set the value to True if the dimension is a header
MEMBERS
UJJ_T_KEYMEM
Table of UJJ_S_KEYMEM.
UJJ_S_KEYMEM
dimension; otherwise it is a detail dimension.
UJJ_T_BADI_CA_JOURNAL_AMOUNTS
Table for UJJ_S_BADI_CA_JOURNAL_AMOUNTS.
UJJ_S_BADI_CA_JOURNAL_AMOUNTS
Field
Type
Description
JOURNAL_ID
UJJ_JRN_ID
The journal ID
AMOUNTS
The table of amounts
1.7.3 Context Defaults

Use
Context is the model, dimensions, and associated members authorized to a user and applicable to what is displayed in a workspace, folder, or view.
Administrators can set the default context that users automatically work in when accessing in the Web client.
Prerequisites
You have accessed the environment for which you want to set the context defaults.
Activities
To set context defaults, perform these steps:
1. In the Administration screen, choose
Features
Context Defaults .
2. To set a specific model as the default, select the model, then choose Set as Default .
3. To set the context defaults for a specific model, do the following:
1. Choose a model in the list, then choose Edit above the list of dimensions.
2. For any dimension for which you want to set defaults, select reporting and data input members, whether to display the dimension and its name, and
how to display the member. You can display a member by its name, description, or both.
3. Save the context defaults for the model.
1.7.4 Drill-Through Setup

Use
You use this function to set up drill-through definitions. Drill-through definitions allow users to access source data from a report. Source data includes content that
can be accessed from a URL.
Prerequisites
PUBLIC
Page 97 of 102
Prerequisites
You must have proper security rights to define drill-through definitions. See the Planning and Consolidation Security Guide for more information. See More
Information.
Features
Setting up Drill-Through to a URL
You set up URL-based drill-through definitions within a model. After you set up at least one drill-through for a model, it is available to users of reports that reference
that model.
You can map the URL parameters to dimensions or user-defined values.
When you map a parameter to a dimension, you also choose a dimension property, such as ID or DESCRIPTION. When the user performs a drill-through in a
report, the parameter value is taken from the property value of the selected data cell. For example, if you select the ID property of a dimension, the member IDs
are mapped. If you select another property of a dimension, that property value is mapped. Therefore, you can send either the dimension member or the value of a
property.
When you map a parameter to a user-defined value, you can hard code a value or use %CurrentUser% or %CurrentDate%. If you specify a user-defined
value in the mapping, when the user performs a drill-through in a report, the parameter value is based on the user-specified value.
Note
The system supports the variables Current Date and Current User in the mapping. The format of Current Date is %CURRENTYYYYMMDD%, where
YYYYMMDD is replaced by the current year, month, and day. You could then use %CURRENTYYYY% for sending out only the current year. The format for
Current User is %CURRENTUSER%.
The system supports using environment parameters and model parameters in a URL. The format is %parameter%. When an environment parameter and
model parameter have the same name, drill-through uses the model parameter prior to the environment parameter.
Executing a Drill-Through
You can use the EvMNU macro MNU_eTOOLS_DRILLTHROUGH_RUN to execute a drill-through using the syntax
MNU_eTOOLS_DRILLTHROUGH_RUN("drillthrough id").
If you have defined a drill-through in the Administration view for a model, a menu item appears under the Drill-Through menu in the menu bar of the report. This
menu item has the same name as the description that was entered in the Administration view when the drill-through was defined. To access the drill-through
information, select a cell in the report and then select the menu item from the Drill-Through menu. A web browser opens. The information that displays depends on
the following items:
The URL specified in the Administration view
The URL parameters specified in the Administration view
The data cell that you selected in the report
Note
The URL and the URL parameters appear in the address bar of the browser. Also, even if the selected cell does not contain data, the drill-through is
performed.
Activities
To define a drill-through for a URL:
1. In the Planning and Consolidation Administration screen, select
Features
Drill-Through .
2. Select New , then enter a drill-through ID and description.
3. Enter the target URL, select the model from which the drill-through can be launched, and enter parameter mapping information to indicate one or more
dimensions and associated properties or user-defined values.
Example
You can specify http://www.google.com/search? as the URL and q, which is a known Google parameter.
4. Save the drill-through.
You can also edit and delete drill-throughs in the Planning and Consolidation Administration screen by selecting
Features
Drill-Through
Example
Example 1
This example describes a scenario of drilling through to a URL.
You want to search the member of Category in a Web site called MySite. You can define a drill-through, setting the URL as www.MySite.com. The parameter for
MySite is q so in the Parameter column, you enter q. In the Dimension or User-defined Value column, select the Category dimension.
In the report, users can execute this drill-through to see the search results.
Example 2
This example describes another scenario of drilling through to a URL.
When SAP BusinessObjects Financial Information Management (FIM) is used to load data into Planning and Consolidation from external data sources (flat files,
tables, 3rd party applications, or other EPM applications), this data is often transformed and aggregated. Planning and Consolidation only stores the final data, and
users may want to drill-through into the details of the data that is stored in a FIM repository (staging area). A URL-based drill-through makes this possible.
When defining the drill-through, the URL is set to the <FIM Application>. URL parameters are dimensions in the Planning and Consolidation model that pass the
context (for example, time, account, etc.), of the data being queried. All data associated with the context is returned and displayed in the FIM drill-through report.

PUBLIC
Page 98 of 102

Use
Document types and subtypes categorize Documents view postings. This is useful if you want to filter them to see only certain types.
Features
Document subtypes help you to further categorize documents when you post them in the Content Library. Administrators can define a list of subtypes from which
users choose, and users can create their own as needed.
While document types always appear in an alphabetical list, document subtypes appear in the order in which they were created. You can change the order of the
subtypes.
Activities
To add or remove document types and subtypes within a model, choose from the Administration screen
type or subtype, then choose Edit .
Features
Document Types
, select a document
To rearrange the order of subtypes while in Edit mode, select a subtype, then choose Move Up or Move Down .
While in Edit mode, you can rename and remove document types and subtypes.
1.7.6 Auditing
Use
Use this function to configure activity auditing and data auditing.
Features
You can perform activity auditing to track administrative and user tasks at the environment level and data auditing to track changes to transactional data at the
model level.
More Information
Activity Auditing
Data Auditing
Audit Reports
1.7.6.1 Activity Auditing

Use
This function tracks administrative and user tasks at the environment level.
Features
Administrators control whether activity auditing is enabled or not. The system can track changes for the following activities, showing the previous and new values
as well as the IP address and machine name associated to the user making a change:
Administration activities, including:
Security-related changes such as adding, changing, and deleting users, teams, task profiles, and member access profiles
Create, modify, delete, and copy operations for models and dimensions; dimension processing; create and delete operations for dimension members;
changes made to property or hierarchy values for a dimension member; delete and copy operations on environments and on drivers for driver based
calculations
Changes to environment and model setup options, global configuration settings and KPI definitions for automated performance analysis, document
types and subtypes, activity audit settings, and data audit settings
User activities, such as setting data locks
Business Process Flow activities, such as adding, deleting, and modifying business process flows, and saving business process flows to new names
User activities in business rules management
Activities
To enable activity auditing for the current environment, from the Administration screen, choose
auditing to enable.
Features
Audit
Edit
, then choose the types of activity
Once the system records an activity, you can run a report that shows activity based on specified criteria (see Reporting on Administration Activity).
You can set up Data Manager packages to archive activity audit information. See the EPM add-in help.

PUBLIC
Page 99 of 102

Use
This function tracks changes to transactional data at the model level, such as when and by whom records were changed within a model.
Features
Administrators control whether data auditing is active or not.
For each model within an environment, you select a category and one or more of the following tasks to audit:
EPM Add-in
Data Manager Import
Data Manager Clear
Script Logic Execution
Web Report Input
Journal Input
Business Rules Execution
Ownership
FIM Import
When selecting the tasks to audit for a category within a model, you can indicate whether you want to retain the logs of the data audits indefinitely or for a specific
number of days. Planning and Consolidation does not delete the logs; rather, it archives them after the number of days you indicate.
Activities
To enable data auditing, from the Administration screen, choose
Features
Audit . Select a model, then choose Edit . Select Yes for each task for which
you want to enable data auditing. You can also set the number of days in which to purge data audit history for each category. Save your selections and purge
setting.
Once activity is recorded, you can run a report that shows activity based on specified criteria (see Reporting on Data Changes).
You can also set up Data Manager packages to archive data audit information. See the EPM add-in help.
1.7.7 Time-Dependent Hierarchies

When you use the time dependent hierarchy feature, you can modify a hierarchy and still keep its history. Thus, you can create, modify, and delete different
versions of one hierarchy. You can display the different versions of that hierarchy by selecting key dates in EPM solutions, add-in for Microsoft Office.
The following information pertains to hierarchy version maintenance within various areas of Planning and Consolidation.
Admin Console
Using the hierarchy view of the dimension master data maintenance screen, you can create, modify, and delete time-dependent hierarchy versions.
Create a new hierarchy version by specifying a start date. A new version will be created starting with the date selected and end at the original end date of
the hierarchy version to which the start date originally belongs. In addition, it is possible to select a reference hierarchy version to indicate how the new
version of hierarchy should look at the beginning.
By selecting an existing hierarchy version from the dropdown list, you can modify any existing hierarchy version. It is also possible to modify an existing
hierarchy version in the list view.
You can select any hierarchy version to delete by selecting a previous version or the next version with which to merge it.
Data Manager
When you use the process chain /CPMB/MANAGE_TDH_VERSION to create and execute a Data Manager package, you can either create a new timedependent hierarchy version or delete an existing time-dependent hierarchy version.
When you load a master data hierarchy either from a flat file or from an infoobject to a time-dependent hierarchy enabled dimension, you can select which
hierarchy version to modify by selecting either a date or a version.. If you select a date, the system takes the version to which the selected date belongs. If you
select a version, your selection is based on a time range.
Reporting
As long as there is at least one dimension from a model that has time-dependent hierarchy enabled, you can select a key date reporting and input forms.
EPM add-in
You can select Key Date in the context bar or report editor when the current model has at least one dimension with a time-dependent hierarchy
enabled.
The selected key date affects all time-dependent hierarchy dimensions, meaning the version of the hierarchy of the time-dependent hierarchy
dimension depends on the selected key date.
You can specify only one key date for a report. Multiple reports from the same worksheet or workbook can have different key dates.
The default key date is the current date.
By default, three versions of the hierarchy for each time-dependent hierarchy dimension are cached on the client machine. The number of cached
versions can be changed by modifying in the client-side configuration file FPMXLClient.dll.config the line:
<add key="LimitTDHCountInCache" value="3"/>
The configuration file can be found in Microsoft Windows 7 at C:\Program Files (x86)\SAP BusinessObjects\EPM Add-In\ if the EPM add-in is
installed for all users, or at C:\Users\<username>\AppData\Local\Programs\SAP BusinessObjects\EPM Add-In\ if EPM the add-in is installed for a
single user.
Web Reporting
You can select a key date from the dropdown menu by choosing Manage Context when the current model has at least one dimension with timedependent hierarchy functionality enabled.
The selected key date affects all the time-dependent hierarchy dimensions, meaning the version of the hierarchy of the time-dependent hierarchy
dimension depends on the selected key date.
The default key date is the crrent date.
PUBLIC
Page 100 of 102
Security
A data access profile is always defined with the hierarchy version of the current date. At run-time, data security is always resolved with the hierarchy version of
the crrent date, no matter what key date is selected from the Reporting user interface.
Data Manager Packages
A key date selection is available when executing a Data Manager package if the model has at least one time-dependent hierarchy enabled dimension.
Logic Scripts
There is no keyword with logic script; it is not possible to specify a key date in a script file.
When a script is triggered by a Data Manager package, a key date is derived from the selection screen when the package is executed.
For default logic, a key date is derived from the input form.
For the script logic test transaction UJKT, the key date can be specified in the field PARAM with the format KEYDATE = yyyymmdd.
Consolidation
Consolidation always uses the current date to resolve a hierarchy.
Transport
A time-dependent hierarchy can be transported with dimension master data.
The global setting ENABLE_TIME_DEPENDENT_HIER cannot be transported. You must maintain this manually in all systems.
The Time-dependent Hierarchy setting in a dimension structure can be transported together with dimension transport. Note that the import process might fail
if the global setting ENABLE_TIME_DEPENDENT_HIER is not set to X in the target system.
Backup and Restore
All versions of a time-dependent hierarchy can be backed up and restored together with master data.
1.7.7.1 Enabling Time-Dependent Hierarchy Functionality

Prerequisites
To use time-dependent hierarchy functionality, you must have the following software installed:
Planning and Consolidation for the NetWeaver platform 10.0 SP09 or later
EPM solutions, add-in for Microsoft Office 10.0 SP13 Patch 1 or later
Procedure
1. To activate the necessary global setting, perform the following steps:
1. Go to the SAP NetWeaver backend using transaction SPRO.
2. Choose
SAP Reference IMG
Planning and Consolidation
Configuration Parameters
3. Insert a new flag with the field name ENABLE_TIME_DEPENDENT_HIER.
Set Global Parameters
4. Set its value to X, then save the entry.

2. To enable the time-dependent hierarchy functionality by dimension, perform the following steps. Note that all dimensions can enable time-dependent
hierarchy functionality except dimensions with the dimension type TIME.
1. Log onto the Planning and Consolidation web client.
2. Choose
Administration
Dimensions .
3. Choose the dimension, then select Edit Structure .
4. Choose Time-dependent Hierarchy , then save your selection.
1.7.8 Parallel Execution

Parallel execution can improve your system's performance by making better use of its processing capabilities.
You can use parallel execution for some of the functions that you run in Business Planning and Consolidation. Parallel execution can improve your system's
performance significantly by making better use of its hardware and the resulting CPU time and memory. When you enable parallel execution, the framework splits
the logic of the processed data when possible. The split parts are allocated to dialog sessions that the framework executes in parallel. This reduces the overall
time necessary to complete a whole process. Parallel execution does not affect the business logic of your operations; it affects only the performance.
Parallel execution is available for the following functions:
Loading data from an InfoProvider
Business rules for elimination and adjustment
Data Manager
1.7.8.1 Enabling Parallel Execution

To enhance Business Planning and Consolidation in terms of scalability and performance, you can enable parallel execution to leverage system resources such
as CPU, memory, and so on.
Procedure
1. Go to the SAP NetWeaver backend using transaction SPRO.
2. Set the following parameters:
Parameter Name
Description
ENABLE_PARALLEL_EXECUTION
Enables parallel execution mode.
PUBLIC
Page 101 of 102
3.
PARALLEL_SERVER_GROUP
The name of the server group where the dialog sessions will run.
MAX_SESSION_COUNT
The maximum number of dialog sessions that parallel execution can use. Default: 12
BUFFER_ROW_SIZE
The amount of data in a package. Default: 40000
BUFFER_MAX_ROW_SIZE
The maximum amount of data in a package. Default: 90000
REFRESH_STATUS_INTERVAL
The amount of time in seconds between session synchronization. Default: 10
BUFFER_MAX_PART_COUNT
The amount of partitions at most one input buffer instance can handle. Default: 1000
BUFFER_WAIT_TIME_TO_EXIT
The amount of time in seconds an input buffer should wait if there is no data. Default:
5
MONITOR_WAIT_TIME_TO_EXIT
The amount of time in seconds the main session should wait before exiting if it
cannot start an instance. Default: 10
Note
You have the option of enabling parallel execution for Data Manager to obtain better performance when processing large amounts of data. The
transaction data related process chains benefit from this framework to varying degrees. Among them, the process chain that loads data from the
InfoProvider sees a significant benefit.
Optional - Apply the following line into the Data Manager dynamic script by performing the following steps:
1. Choose
EPM client
Data Manager
Organize
Organize Package List .
2. Select a package.
3. Choose
Modify Package
Modify Script
Advanced .
4. Apply the line PARALLEL_EXECUTION(ON).
PUBLIC
Page 102 of 102

SAP Help - bpc10 PDF

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SAP Help - bpc10 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Administration

PDF download from SAP Help Portal:

1.5.2.2.5 *FUNCTION / *ENDFUNCTION

1.7.5 Document Types and Subtypes

1.1 Environment Management

1.1.1 New Environments

1.1.1 New Environments

1.1.2 EnvironmentShell Sample Environment

Dimensions specific to Consolidation

Dimension specific to Planning

Dimensions specific to the Rates model

Dimension specific to the Ownership model

1.1.3 Environment Status

Manage All Environments

1.2 Dimension Management

Dimensions and Models

1.2.1 New Dimensions

Permission, PublishedBooks, Rate, ReportParam, SectionDef,

Create dimension descriptions with a maximum of 255 characters.

You can assign new properties to a dimension.

Dimension Validation Rules

Reference Type ID - Description

Dimensions and Models

, then entering the

1.2.2 Dimension Types

Usually contains chart of accounts and other planning

represented by a hierarchy of accounts.

This represents the various data source that could be used

Represents the business units that are used to drive the

Reports consolidated results in multiple group currencies

Contains the intercompany codes for the entities. This

represents the intercompany codes for the purposes of

Contains the currency rates for all currencies in which

This is used to break down the account activity or flow. For

This represents any User-defined dimension that may be

1.2.3 Dimension Security

1.2.4 Dimension Processing

Dimensions and Models

, selecting one or more dimensions, then

1.2.5 Dimension Member Management

Dimensions and Models

1.2.6 Assignment of Dimensions to Models

1.2.7 Custom Measure Formulas

Click the Debugging button.

Sample - YTD on YTD Model

1.2.8 Dimension Properties

Adding properties to dimensions

Adding properties to dimensions in Consolidation,Ownership, and Rates models

When you add a property to a dimension in a consolidation, ownership, or rates model,

Modifying dimension properties

Adding property values

Removing dimension properties

Limiting the number of dimension members available to users

Indicates whether the member is calculated by means of a formula or is at a parent level.

1.6.1.2.5 Owner Property

1.2.8.2 Reviewer Property

When defining the property, the following rules apply:

1.2.8.3 Account Dimension Properties

Used by the currency conversion business rules. Value is optional.

Flag for ownership accounts to be used in Method-based multipliers.

1.2.8.4 Category Dimension Properties

A category dimension has the following required properties:

1.5.2.2.5 FUNCTION / ENDFUNCTION