Rules Engine Designer data processing on consolidation scenarios

Introduction¶

Rules Engine Designer on Consolidation Scenarios is a data processing that starting from input data on amounts and journals of proportional, converted and consolidable amount types, identified by a set of dimensions (tuple), allows amounts and journals to be generated by applying the rules and conditions defined by the Consolidator user.

Data Processing Requirements¶

The following conditions must be fulfilled for this data processing to take place:

In the Data Processing section of the process, the following items are selected
Rules Engine Designer > on Consolidation Area
There is an execution plan with at least one Entity included in the consolidation area and a rule node containing at least one rule parameterised with the following:
at least one input dimensions record
at least one input categories record
Rules can only be run if the following conditions are met:
The output account belongs to the process.
The output account belongs to the Accounts node that might be present as a filter on the Consolidation Scenario.
The Custom dimension is enabled in the Data Entry rules. For the Amount rules, the custom dimension must be enabled in the data entry rules of Gross and IC Amounts; for the Consolidation journal rules, the custom dimension must be enabled in the Journal data entry rules.
The elements of the Custom Dimension on which to generate output rows meet the restrictions of the output accounts.
Ctp Custom Dimension 2, if enabled on the rule, is handled in the Process(Relationship Type other than Entity).
Input and Output categories are set to Run.
Input and Output categories belong to the process.
Input and Output categories belong to the categories node that may be present as a filter on the Consolidation Scenario.
If the process type is by account/category, the output account/category pair must be eligible for the Process Types linked to the Entities to be processed.
In the case of rules with Periodic Calculation Mode, the periods selected at runtime must be consecutive.

Execution Plan Requirements¶

The following must be specified for each consolidation scenario period:

the entity or node of entities to be processed
as an alternative to Entities, it is possible to specify a consolidation method. In this case, the Entities that have the consolidation method indicated in the selected consolidation scenario/period are taken into account.
the rules node for each Entity/ Entity node to be treated

IMPORTANT: If the same Entity and original scenarios/period are contained in several rows of the execution plan definition, only the last one is considered.

Data processing on consolidation scenarios¶

Rules Engine Designer data processing on consolidation scenarios is run on the following amount types:

Consolidable: the data processing processes rules with Position equal to Consolidable and is launched after the Net Equity Reclassification and before the Calculation Logics. The input data rows of amounts and journals are read from the Consolidatable amount type and the output rows generated by the data processing are entered on amounts or consolidation journals on the Consolidatable amount type.
Converted: the data processing processes rules with Position equal to Converted and is launched after Conversion and before the Minorities calculation. The input data rows of amounts and journals are read from the Converted amount type and the output rows generated by the data processing are entered on consolidation journals on the Converted amount type.
Proportional: the data processing processes rules with Position equal to Proportional and is launched after Deconsolidation. The input data rows of amounts and journals are read from the Proportional amount type and the output rows generated by the data processing are entered on consolidation journals on the Proportional amount type.

For the data processing to be properly completed, the tuples to be processed must have been parameterised correctly.

For example, if a normal account is processed, the related detail/variation accounts must also be generated, otherwise the control groups in which the normal account is contained will be unbalanced.

For the entities and on the consolidation scenarios defined in the execution plan, the data processing runs the rules contained in the nodes by reading the input combinations on the Input category, and generates a new consolidation journal on the Output category.

IMPORTANT: No order of priority applies to the rules. All rules are processed concurrently, without any execution sequence.

For each rule, the final balance is calculated for the following elements:

Entity
Account
Managed custom dimensions
Ctp Entity
Custom dimension 2 of the counterparty entity (for Processes whose relationship type is Entity/Custom Dimension 2)
Ctp Entity for Segment
Custom dimension 2 of the segment counterparty entity (for Processes whose relationship type is Entity/Custom Dimension 2)
Currency:
Consolidation currency for rules with position 'Consolidable' and 'Converted'
Entity currency for rules with the position 'Proportional' for which the 'Write in same journal header' option is not enabled
for rules with position 'Proportional' for which the 'Write in same journal header' option is enabled, the final balance is calculated in the journal currency, in the entity currency and in the transaction currency
Category

The Markup percentage (default 100%) and the indicated Dynamic Markup, if any, is applied to the amounts obtained. The amount obtained is managed as follows:

If the Write off input data option is selected on the rule, the amount is written off from the input tuple at issue.
In other cases, the amount is allocated to the tuple specified in the output dimensions.

For rules that have the Enable carry forward Writing off for normal and detail accounts option enabled , for balance sheet, Guaranties & Commitments or other stock and normal/detail type accounts, the amount of the input data considered includes the value of the carry-forwards. Therefore, for the Consolidation Journals rules, rows with origin 'Carry forward - Rules Engine Designer' are written off. The write-off is carried out even if the rule definition rows have input accounts of variation type and output accounts of normal/detail type.

On the contrary, for rules that do not have the Enable carry forward Writing off for normal and detail accounts option enabled, rows with origin 'Carry forward - Rules Engine Designer' are not written off. This option is useful in cases where, in the rule definition for a given account, only part of the variation accounts belonging to a specific control group are reclassified to another account.

IMPORTANT: In order to take full advantage of the possibility of deactivating the write-off, even if the 'Write in same journal header' functionality is used, the note field of the rows produced by the RED must contain the information about the rule that generated them. For this purpose, it is necessary to ensure that in the Carry-forward Rules the 'Journals rows aggregation type' field is set with the options 'Don't aggregate' or 'Aggregate according to dimensions and notes'

For amount rules, the Notes field of the generated rows is defined with the code and description of the generating rule.

IMPORTANT:In the Amount rules, the option Swap Entity with Ctp Entity generates rows only if the Entity and Ctp Entity belong to the selected Entity node filter (both for the output dimension row and the input data write off row) .The Notes of the generated rows contain the prefix '[ Swap ]'.

Calculation method¶

For each rule, it is possible to choose the calculation method for the period data amount, i.e. P&L and other variation type input accounts, variation type accounts and group and minorities balance sheet net result accounts:

Year-to-daye: the year-to-date amount for the data processing period is processed by applying any dynamic markup for the period
Periodic - Start of period: the periodic amount is processed. The dynamic markup variance and the rule execution change with respect to the previous period are deemed to have occurred at the beginning of the period.
Periodic - End of Period: the periodic amount is processed. The dynamic markup variance and the rule execution change with respect to the previous period are deemed to have occurred at the end of the period.

The periodic calculation allows for more precise amounts in the presence of dynamic markup. Moreover, it allows the generation of variation flows for rule execution change with respect to the previous period.

The following rows are generated in the periodic calculation:

Period quota: the difference between the value of the current data processing period and that of the previous period (The calculation is carried out even in the absence of data from the data processing period.) Any dynamic markup is applied:
Start of period: dynamic markup of data processing period
End of period: dynamic markup of previous period
Copy from previous period: from the second period of the scenario, the rows generated in the previous period are copied.
Dynamic markup - variation compared to the previous period (only if parameterised):
Start of period: Parent account amount of previous period * markup variance
End of period: parent account amount of the data processing period * markup variance

The rows produced by the periodic calculation are identified by the content of the Notes field, which is labelled '[ Periodic ]'.

Generated journals¶

For consolidation journal rules that have the Write on same journal option enabled, the data processing generates rows in the same input journal. The code and description of the rule are indicated in the Notes field of the rows produced.

For the Consolidation journal rules that do not have the Write on same journal option enabled, the data processing generates a journal with the same rule/output category and entity.

The new headers are created by assigning the default attributes defined on the rule in the Journal attributes tab:

Enable carry forward
Minorities calculation method. For rules with Position equal to 'Converted' and 'Proportional'.

The pre-existing headers, generated by previous runs of the data processing, are updated every time it is run with the default attributes defined on the rule when the data processing is run.

The Many to many relationship option is enabled as the following rows can be available:

Rows with Counterparty entities that are different from the output entity
Rows with Ctp Entity for segment different from Output Entity
Rows whose Entity/Custom Dimension 2 pair is different from the header’s Entity/Custom dimension 2 pair (for Processes whose type is Entity/Custom Dimension 2)

IMPORTANT: If the input/output dimensions to be processed are changed between the scenario to be processed and the previous one, it is necessary to manually write off, i.e. override, the entries on the dimensions entered in the previous parameterisation.

Journal header¶

The journal headers generated by the data processing are identified by the journal number formed by the prefix RED_ followed by the rule code, the output category and the Entity. The description of the rule is indicated in the Notes field of the produced header.

If the Entity/Custom dimension 2 Relationship Type is defined for the process, the header shows the fields of Destination 2 with the Entity's default Custom Dimension 2.

Hence, the data processing generates only one header with the same output rule/category and Entity even if several elements of Custom Dimension 2 are moved. The single header facilitates the analysis of the journal and does not reduce the quality of Segment reports. These in fact do not read the header but only consider the information contained in the journal rows.

Origin¶

The origin generated by the Rules Engine Designer data processing is:

CONS_RED for rules with 'Consolidable' Position
CONS_RED_2_CONV for rules with 'Converted' Position
CONS_RED_1_DECO for rules with 'Proportional' Position

In the case of rows generated in the previous year and carried forward the following year, the origin generated by the carry forward data processing is:

PRCO_RESTORE_RED for rules with 'Consolidable' Position
PRCO_RESTORE_RED_2_CONV for rules with 'Converted' osition
PRCO_RESTORE_RED_1_DECO for rules with 'Proportional' Position

In the case of deconsolidation of rows on the converted amount type generated by rules with Position 'Converted', the origins generated by the deconsolidation data processing are:

CONS_DECONSOLIDATION_RED_2_CONV
CONS_COPY_PREVIOUS_RED_2_CONV

"Read input data from entities node" option¶

This option, available for rules with Position equal to 'Consolidable', is useful where it is necessary to read input data from several Entities.

A parameterisation that matches hierarchies of Entity nodes to output Entities allows the system to read input data from multiple Entities and generate the journal or the amounts on the output Entity.

For Amount rules, the notes of the generated rows contain the Entity node.

For Consolidation journals, the generated journal number contains the output Entity and the node.

The Read input data from Entities nodeoption combined with the Map dimensions based on sign option can be used when reclassifying the Credits for prepaid taxes / Debits for deferred taxes , all on Credits or all on Payables based on the sign of the sum of Credits and Payables of an Entities node and obtain the output journal on a reference Entity.

Parametrisation:

Read input data from Entities node must be enabled in the Advanced tab of the rule. This option cannot be enabled along with the Write in the same journal header option.
In the Entity Definition window, it is necessary to enter the Entity nodes from which to read input data and for each node, the output Entity on which to generate journals.
In the execution plan, it is necessary to associate the rule node with the Output Entity specified in the Entity definition.

The data processing calculates the sum of the input data of the Entities belonging to the node. The rule is applied to the input data aggregated by entity node.

IMPORTANT: In the sum of the aggregated input data per node, the Entity and the Ctp Entity for Segment are replaced with the Output Entity, while the Ctp Entity remains that of the input data.

Therefore, the following effects occur:

Conditions: Condition attributes on the Entity and the Ctp Entity for segment refer to the Output Entity. Condition attributes on the Ctp Entity refer to the input Ctp Entity as usual.
Generation of write-off journals: Entity and Ctp Entity for Segment are equal to the Output Entity. The Ctp Entity is the input entity.
Generation of journal's reclassification rows: the Entity is equal to the Output Entity, the Ctp Entity can be handled with the rule excluding the option Swap Entity with Ctp Entity, the Ctp Entity for Segment can be handled with the rule excluding the 'Equal to Input' option.

Journals with an impact on Net result¶

In the rule it is possible to specify that a normal account of BS nature is to be processed on a normal account of P&L nature or vice versa.

In such cases, there is likely to be an impact on the Net result account. In order to recognize the impact, the account calculation rules must be enabled to also be applied to the consolidation scenario.

There may be effects on the profit considered in its 'split' on the Custom Dimension even when an element of the Custom Dimension is treated.

Cases where no output rows are generated¶

In these cases, the data processing does not generate write-off rows or output rows, even if input tuples are present:

The output account is not present in the Entity Process Type or in the filter of the Consolidation Scenario.
The output category is not enabled in the process or filter of the Consolidation Scenario.
The account/category pair is not enabled in the Entity’s Process type.
The rule is defined for a Custom dimension that is not managed on the process for the amounts (for Amount rules) or for the journals (for the Consolidation journal rules).
The management of the Ctp Custom Dimension 2 is enabled for the rule, while the process relationship type is by Entity.
The rule contains rows that do not consist of the dimension definition or definition rows with undefined input dimensions (active in the header).
The conditions in the rule are not fulfilled.
The dimension definition row has a dynamic markup equal to zero or that cannot be calculated.
Rules with the Write in the same journal header option enabled - case in which it is not possible to Swap the Entity with the Ctp Entity. In the consolidation journals, the Ctp Entity might be different from the two header Entities (even if the Many-to-many Relationship option is disabled), if the Manage Counterpart regardless of header relationship option is enabled in the header rules. In this case, input data rows that have Ctp Entity other than the two header Entities are not processed in the rule definition rows that have the Ctp Entity dimension active and Selection = Swap Entity with Ctp Entity. The swap is not possible because the entity cannot be defined as anything other than the two header entities. If the relationship type is entity/custom dimension 2, the system excludes input rows whose Counterparty entity/Counterparty custom dimension 2 is different from the two Entity/Custom Dimension 2 pairs in the header.

Further conditions on the application rule¶

Below are the options available for each condition that the input data must fulfil in order for the rule to be applied.

Condition	Options
Entity - Consolidation Method	- Line-by-line - Proportional - Equity - Cost - Not present. The Entity is not included in the consolidation area.
Entity - Deconsolidation Method	- Not to deconsolidate - Initial balances - From previous period - From current period
Entity - Equity Type	- None - Associate - Joint Ventures - Non-consolidated controlled entity
Entity - Holding Consolidation Area	- Only applies to the holding company - Applies to all entities excluding the holding company
Entity - Merger event	- Incorporating - Incorporated - Not present as Incorporating Entity - Not present as Incorporated Entity
CTP Entity - Consolidation Method	- Line-by-line - Proportional - Equity - Cost - Not present. The CTP Entity is not included in the consolidation area.
CTP Entity - Deconsolidation Method	- Not to deconsolidate - Initial balances - From previous period - From current period
CTP Entity - Equity Type	- None - Associate - Joint Ventures - Non-consolidated controlled entity
CTP Entity - Merger event	- Incorporating - Incorporated - Not present as Incorporating Entity - Not present as Incorporated Entity
CTP Entity for Segment - Consolidation Method	This condition is considered only for input data on Consolidation Journal categories. - Line-by-line - Proportional - Equity - Cost - Not present (the Segment CTP entity is not present in the consolidation area)
CTP Entity for Segment - Deconsolidation Method	This condition is considered only for input data on Consolidation Journal categories. - Not to deconsolidate - Initial balances - From previous period - From current period
CTP Entity for Segment - Merger event	This condition is considered only for input data on Consolidation Journal categories. - Incorporating - Incorporated - Not present as Incorporating Entity - Not present as Incorporated Entity

Period of application of the conditions¶

For all conditions, except Entity - Holding Consolidation Area, an application period can be defined. For this purpose, the following options are available:

Current Period: the condition is verified on the consolidation area of the data processing scenario/period except for the Merger Event conditions which are verified on the merger events of the original scenario associated with the data processing consolidation scenario and merger period equal to or preceding the processing period
Opening Period: The condition is verified on the consolidation area of the carry forward scenario/period except for the Merger Event conditions which are verified on the merger events of the original scenario associated with the previous consolidation scenario and any merger period.

Conditions application specificities¶

For input data rows with an unvalued Ctp entity, the following conditions on the CTP Entity cannot be fulfilled as they are based on the Ctp Entity:

CTP Entity - Consolidation Method
CTP Entity - Deconsolidation Method
CTP Entity - Equity method type
CTP Entity - Merger event

In addition, rules that have conditions on the field CTP Entity for Segment and input categories of Amounts and Entity journals are also applied to the rows of input data of Amounts and Entity journals and the condition is always considered fulfilled. If the condition on the segment counterparty entity’s consolidation method is combined with the OR operator or another condition, the set of conditions is always satisfied for the Amounts and Entity journals input data.