Settings in the Rules Engine Designer list pages
Tile Data Processing > Basic Consolidation > Rules Engine Designer on Original Scenarios > Elements list > Gross Amounts tab > select rule > Advances tab
Tile Data Processing > Basic Consolidation > Rules Engine Designer on Original Scenarios > Elements list > IC Amounts tab > select rule > Advances tab
Tile Data Processing > Basic Consolidation > Rules Engine Designer on Original Scenarios > Elements list > Entity journals tab > select rule > Advances tab
Tile Data Processing > Basic Consolidation > Rules Engine Designer on Original Scenarios > Elements list > Consolidation journals tab > select rule > Advances tab
Data Processing tile > Basic Consolidation > Rules Engine Designer on Consolidation Scenarios > Elements list > Amounts tab > select rule > Advanced tab
Tile Data Processing > Basic Consolidation > Rules Engine Designer on Consolidation Scenarios > Elements list > Consolidation journals tab > select rule > Advances tab
Introduction¶
Further details on the more complex settings that can be applied are provided below.
Rule execution change vs opening/previous¶
In the Rule execution change vs opening/previous section, it is possible to set the data processing behaviour when a rule is applied only on the previous scenario/period or only on the data processing scenario/period.
IMPORTANT: completing this section is only useful for rules containing definition rows of the dimensions on input variation accounts with output variation accounts.
CCH Tagetik automatically generates the variation flows compared to the previous scenario / period in the journals and amounts related to rules that handle variation accounts, in order to ensure the balancing of the control groups.
The variation is calculated based on the previous scenario/carry forward period, except for rules related to consolidation scenarios with period-based calculation mode. In this case, starting with the second period, the change is generated based on the previous period.
This behaviour requires the following settings:
| Field | Description |
|---|---|
| First application of the rule | - Rules having a condition which is met for the first time in the data processing scenario / period - Rule which, for a given entity, is present in the execution plan for the first time in the data processing scenario/period - Rule that has the option Map dimensions based on sign active and the sum of the rule's input data changes sign between the previous scenario/period and the data processing scenario/period for which the following conditions occur: - The sign of the sum of the input data in the previous scenario/period (initial balance variations, except for rules with periodic calculation mode for which - starting from the second period - the value of the parent account from the previous period is taken into account) is different from the sign specified in the dimension definition row. Therefore, the row was not applied in the previous scenario/period. - The sign of the sum of the input data in the data processing period/scenario (variations indicated in the rule including the initial balance) is the same as the sign in the dimensions definition row, so the row is applied in the data processing scenario/period. |
| Rule no longer applied | - Rules having a condition which is met in theprevious scenario / period and no longer met in the data processing scenario. - Rule which, for a given entity, is no longer present in the execution plan associated with the data processing scenario/period. - Rule that has the option Map dimensions based on sign active and the sum of the rule's input data changes sign between the previous scenario/period and the data processing scenario/period for which the following conditions occur: - The sign of the sum of the input data in the previous scenario/period (initial balance variations, except for rules with periodic calculation mode for which - starting from the second period - the value of the parent account from the previous period is taken into account) is equal to the sign specified in the dimension definition row. Therefore, the row was applied in the previous scenario/period. - The sign of the sum of the input data in the data processing period/scenario (variations indicated in the rule including the initial balance) is different from the sign in the dimensions definition row, so the row is no longer applied in the data processing scenario/period. |
You can choose the variation type and thus the variation account to be used to balance the control groups.
The possible values for both fields are as follows:
- Area variation - Entry
- Area variation - Exit
- Modify % - Increase
- Modify % - Decrease
- Merger - Incoming
- Merger - Outgoing
- Change from/to equity method - Entry
- Change from/to equity method - Exit
- IFRS 5 reclassification - Entry
- IFRS 5 reclassification - Exit
- IFRS5 Reclassification - Initial balance write off on IC elimination journals
- Reverse
- Balancing
- Calculation logic
- Specific variation/detail type
Output rows on variation flows with respect to the previous scenario/period are only generated under the following conditions:
-
In the rule definition row, the input account and the output account are variation accounts.
-
The specified variation type is defined within the control group of the output account. If the rule has the option 'Enable input data Writing off' enabled, it must also be defined in the control group of the input account.
Note: only the control groups of variation type belonging to the process are taken into account.
The amount of the variation is:
- rules on original scenarios and rules on consolidation scenarios with Year-to-date calculation mode: initial balance variation amount from input data
- rules on Consolidation Scenarios with Calculation Mode 'Periodic - Start of Period': Parent account amount from previous period input data
- rules on Consolidation Scenarios with 'Periodic - End of Period' Calculation Mode: Parent account amount from input data for the data processing period
In case of rule definition rows with dynamic markup, the markup value of the data processing scenario/period is applied.
An exception is made for consolidation journal rules in consolidation scenarios where the 'Enable carry forward Writing off for normal and detail accounts' option is disabled. These rules, generally used to reclassify specific control group flows, require that the variation amount be determined in the following manner and be recorded on both the variation flow and the parent account:
- rules with Year-to-date calculation mode: parent account carry-forward amount from output data (source: carry-forward – Rules Engine Designer)
-
rules with 'Periodic - Period start' calculation mode Sum of:
-
parent account carry-forward amount from output data
- input data amount of the rule's flows for the previous period
-
rules with 'Periodic - Period end' calculation mode Sum of:
-
parent account carry-forward amount from output data
- input data amount of the rule's flows for the data processing period
In the presence of rule definition rows with dynamic markup:
-
the parent account carry-forward amount from output data is recalculated by dividing the amount by the dynamic markup of the carry-forward scenario/period and multiplying it by the dynamic markup of the data processing period.
-
the dynamic markup value of the data processing scenario/period is applied to the input data of the rule flows.
In order to obtain a correct amount on the rows of the variation flows, the following must occur:
-
All handled flows of the control group are entered as input accounts in the definition of the rule's dimensions. Alternatively, the rule is on consolidation scenarios and has the option 'Enable carry forward Writing off for normal and detail accounts' disabled. In the latter case, for the calculated value to be correct, the rule must have the following characteristics:
-
'Allow multiple relationship' option enabled, and definition rows in which the same input flow account is associated with:
- output variation accounts
- output parent account (this definition is necessary to obtain the carry-forward rows of the parent accounts with source: carry-forward - Rules Engine Designer).
-
if the Ctp Entity dimension is enabled on the rule:
-
if a condition is set on the Ctp Entity, the definition rows must ensure a unique correspondence between output Ctp entity for Segment and input Ctp entity for Segment with the same control group
- if a condition is set on the Ctp Entity for Segment, the definition rows must ensure a unique correspondence between output Ctp entity for Segment and input Ctp entity for Segment with the same control group
- if the rule does not have both the Ctp Entity and Ctp Custom dimension 2 dimensions enabled, the parent account and the rule end flow must have the same value as the IC Management option in the accounts list.
- the parent account is detailed on the Custom dimensions in the same way as the input flows.
- if the rule has the 'Write in same journal header' option enabled, the 'Journals rows aggregation type' option must be set to 'Don't aggregate' or 'Aggregate according to dimensions and notes' in the carry-forward rules. This configuration is required in order to keep the rule code in the notes of the carry-forward rows.
- The Allow multiple relationship option is not selected; In the definition of the rule dimensions, there are no longer multiple rows with the same control group (extracted from the account) and the same input dimensions; instead, there are rows with different output dimensions or dynamic markup. Otherwise, variation flows compared to the carry-forward scenario are generated using the output dimensions and dynamic markup of the definition row with highest sorting.
- In input data, the initial balance variation is detailed on the Custom dimensions in the same way as the input flows For rules with periodic calculation mode, the parent account is detailed on the Custom Dimensions in the same way as the input flows.
- the dimension definition of the rule does not include the following rows:
-
balance sheet input accounts and profit & loss output accounts (or vice versa)
-
input accounts or output accounts present in the Carry forward rules
-
If the rule has conditions defined with Opening Period option (seeRule application conditions), the following behaviour occurs:
| If... | Then... |
|---|---|
| the condition is verified in the carry-forward scenario/period. | the rule is applied on the data processing scenario/period. |
| if the condition is verified in the scenario/period preceding the carry-forward scenario/period (previous scenario of the previous scenario). | the rule is applied on the carry forward scenario/period. |
For Rules Engine Designer settings on Consolidation Scenarios, the following condition also applies:
- If the rule is for Consolidation Journals and the Write in the same journal header option is enabled, or if the rule is for Amounts and the output category is the same as the input category, then in the rule's dimensions definition, the parent accounts (either normal or detail type) of the specified flows are also included as input accounts.
For Rules Engine Designer settings on Original Scenarios, the following condition also applies:
- If the rule is set to 'Gross Amounts' or 'IC Amounts' and the output category matches the input category, the parent accounts of the specified flows are also included as input accounts in the rule dimensions definition. Alternatively, the rule has the 'Run Basic Calculation Logics' option enabled and there is a basic calculation logic that calculates the parent account as the sum of the flows.
For rules on original scenarios of Gross Amounts, IC Amounts and Consolidation journals that read data from amounts and Entity journals, when dimension definition rows include 'Swap Entity with Ctp Entity' option, the entity currency amount in the output dimension row is populated based on the transaction currency amount of the input initial balance row, applying the FX rate of the variation flow account from the data processing scenario/period (see Management of Swap Entity with Ctp Entity).
For rules with Periodic calculation mode, the rule execution change is not generated for the input accounts of Group and Minorities Balance Sheet net result(since these accounts are processed in periodic mode).
Dynamic Markup - Variation compared to the opening/previous¶
In this section, you can configure how the data processing behaves when there is a variation in the dynamic markup value between the data processing scenario/period and the previous one.
The variation is calculated based on the previous scenario/carry forward period, except for rules related to consolidation scenarios with period-based calculation mode. In this case, starting with the second period, the change is generated based on the previous period.
IMPORTANT: completing this section is only useful for rules containing definition rows of the dimensions on input variation accounts with output variation accounts.
CCH Tagetik automatically generates the variation flows compared to the previous scenario / period in the journals and amounts related to rules that handle variation accounts, in order to ensure the balancing of the control groups.
This behaviour requires the following settings:
| Field | Description |
|---|---|
| Increase | The markup of the previous scenario/period is non-zero and less than the markup of the data processing scenario/period. |
| Decrease | The markup on the data processing scenario/period is non-zero and less than the markup of the previous scenario/period. |
| 0 to N | The markup of the previous scenario/period is zero and the markup of the data processing scenario/period is non-zero. |
| N to 0 | The markup in the previous scenario/period is non-zero and the markup in the data processing scenario/period is zero. |
You can decide which type of variation and therefore which variation account to use for balancing control groups.
The possible values and conditions for obtaining a correct amount on the variation flows are the same as those specified for the Rule execution change.
The amount of the variation is:
- rules on original scenarios and rules on consolidation scenarios with Year-to-date calculation mode: initial balance amount * markup variance
- rules on consolidation scenarios with calculation mode 'Periodic - Start of period': Parent account amount of previous period * markup variance
- rules on consolidation scenarios with 'Periodic - End of Period' calculation mode: parent account amount of data processing period * markup variance
An exception is made for consolidation journal rules in consolidation scenarios where the 'Enable carry forward Writing off for normal and detail accounts' option is disabled. For these rules, which are generally used to reclassify only part of the control group variations, the variation amount is determined as follows and is written on both the variation flow and the parent account:
- rules with Year-to-date calculation mode: parent account carry-forward amount from output data / carry-forward markup * markup delta
-
rules with Calculation mode 'Periodic - Start of period'. Sum of:
-
amount reopening parent account of output data / markup carry-forward * markup delta
- input data amount of the rule's flows for the previous period * markup delta
-
rules with Calculation Mode 'Periodic - End of Period'. Sum of:
-
amount reopening parent account of output data / markup reopening * delta markup
- input data amount of the rule's flows for the data processing period * markup delta
when there is a change in the dynamic markup value in the case of a Rule that is no longer applied, both Rule Execution Change rows (using the markup in the data processing scenario/period) and Markup Change rows are generated.
In the case of first-time rule application, markup change rows are not generated.
For rules with Periodic calculation mode, the markup variance is not generated for the input accounts of Group and Minorities Balance Sheet net result (since these accounts are processed in periodic mode).
Allow multiple relationship¶
This option allows the same tuple of the input dimensions to be deployed and generated several times within the same rule.
If not selected, if the same tuple of input data is contained in more than one rule definition row, it is considered only once and the definition row with the highest sorting among those appearing in the window prevails.
If selected, the same tuple of input data is expldeployed in all definition rows with Action equal to Include that contain it, regardless of the order in which the rows appear in the rule's input/output dimension definition window. Rule definition rows with Action equal to Exclude are treated according to the order in which they are displayed.
This option allows the same input tuple to be used within the rule to generate multiple rows on different output dimensions (possibly using a % Markup or the Dimension Mapping based on the Sign functionality).
If this option is selected, but Map Dimensions based on sign is not selected, the option Enable Writing off is automatically deselected. In fact, if you have several definition rows in the same rule with the same input dimensions but different output dimensions, CCH Tagetik would perform the write off more than once, causing misalignments.
Map dimensions based on sign¶
This option allows you to manage a rule according to the sign of the input data. If selected, it shows the Sign field on the dimension definition page.
CCH Tagetik calculates the following values:
- Entity currency amount, for the rules of Gross Amounts, IC Amounts, Entity Journals and Consolidation Journals reading from entity journals and amounts
- the journal currency amount, for the rules of consolidation journals on original scenarios reading from consolidation journals
- the amount in consolidation currency, for the rules of Amounts and Consolidation Journals on consolidation scenarios
These amounts are calculated as the sum of all input data rows that match the rule definition rows. Output rows are generated only for definition rows that have the Sign field corresponding to the sign of the calculated total amount.
For rules containing accounts of variation type, the sum of the input data calculated to evaluate the sign includes the value of the initial balance variations.
If the same input tuple with the sign >=0 and sign <0 needs to be entered in the definition on two different output accounts/dimensions, it is necessary to enable the Allow multiple relationship option. In this way, the expected output account is chosen based on sign.
This can be useful, for example, for the reclassification of Deferred Tax Receivables / Deferred Tax Payables, all on Receivables or all on Payables according to the sign of the sum of Receivables and Payables. In this case, you can define a single rule in which the variations of the debits and credits are inserted with output account equal to Credits for prepaid taxes for the Sign >= 0 and Debits for deferred taxes for Sign < 0.
Run basic calculation logic¶
This option is only present for rules on original scenarios.
This option allows the basic calculation logic to be launched at the end of the processing of the rule, e.g. when it is necessary to calculate the Profit and Loss Result or the parent accounts as the sum of the flows.
If selected, the basic calculation logic with 'Sum' calculation type is executed on the rows generated by the rule. For Gross Amounts and IC Amounts rules, the calculation also considers the rows on the initial balance flow accounts with origin PREL_RESTORE_RED.
The origin generated is 'PROC_RED'. The notes field is filled in with the code of the calculation logic.