Create or Modify Dimension Properties
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.
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 |
3 |
This property can have the following values:
|
|
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 dimension. |
|
RATETYPE |
10 |
This property determines the business rules to be applied when translating any given account from local currency to reporting or group currency.
|
|
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 InfoProvider, 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 InfoProvider, 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 |
Description of Property Values |
|---|---|---|
|
FX_SOURCE_CATEGORY |
20 |
The category for the source (LC) data. If blank, it is the current category. |
|
RATE_CATEGORY |
20 |
The category from which the rates are read. |
|
RATE_YEAR |
4 |
The year from which the rates are read. The value can be absolute (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 |
1 |
If Y, only the difference between the default values and the simulated values is stored. |
The business rules for copying opening balances can be controlled by assigning special properties to the category dimensions. If used, these properties affect the execution and are defined in the following table:
|
Property Name |
Length |
Description of Property Values |
|---|---|---|
|
CATEGORY_FOR_OPEN |
20 |
|
|
OPENING_YEAR |
4 |
|
|
OPENING_PERIOD |
10 |
|
Audit Dimension
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 |
Description of Property Values |
|---|---|---|
|
IS_CONVERTED |
1 |
|
|
IS_CONSOL |
1 |
|
|
DATASRC_TYPE |
1 |
|
|
COPYOPENING |
1 |
|
|
OPENING_DATASRC |
20 |
|
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 |
|---|---|---|---|
|
G |
GROUP_CURRENCY |
20 |
Can be any valid reporting currency. Used for currency translation. 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 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. |
|
G |
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. |
|
G |
STORE_GROUP_CURR |
1 |
Used for currency translation.
|
|
G |
STORE_ENTITY |
1 |
|
|
G |
STAGE_ONLY |
1 |
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 |
1 |
Used for the currency translation. |
|
FIRST_CONS_DATE |
10 |
|
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 sub-table 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 |
Description of Property Values |
|---|---|---|
|
FLOW_TYPE |
12 |
|
|
DIMLIST |
20 |
Used to group the flows for several business rules |
- OPENING
- CLOSING
- VARSCP
Activities
-
To manage dimension members and their property values:
-
In the navigation panel, go to Administration and under the Modeling section, choose Dimensions.
-
Select the row containing the dimension member required:
-
To manage dimension members, click Edit Members
-
To manage the property values, click Edit Structure
-