Plausibility check logics page
Admin
Data Processing tile > Diagnostic > Plausibility Check logics > Elements list
Navigation panel > Data processing > Diagnostic > Plausibility check logics > Elements list
Page purpose¶
This page allows you to define the plausibility logics. In particular, this page allows you to configure:
- the scenario and the reference period against which the data is to be compared
- the filters to be applied to the data to be checked
- the aggregation criteria of data to check
- the checks to be performed, defined using an SQL expression
- the comparison thresholds for determining the severity of errors
When the data processing is launched, the following elements are defined:
- the scenario and the period to be compared
- the entity used to filter the data
Tabs on the page
| Element | Description |
|---|---|
| Attributes | Allows you to define the logic and specify which elements or categories to check, as well as the scenario and the comparison period. |
| Data to check | Allows you to specify the data type to be checked and to filter the data to which the logic is to be applied based on certain list elements. |
| % Impact calculation | Allows you to specify whether percentage calculations should be carried out on the amounts to be compared |
| Comparison | Allows you to define the formula to be used for the comparisons. Use SQL scripts and thresholds. |
| Relationships | Allows you to associate each plausibility logic with one or more nodes in the plausibility logics grouping. These nodes can then be associated with each Entity, contributor node and consolidator node within the process for which a plausibility diagnostic is to be performed. |
Fields in the Attributes tab
| Element | Description |
|---|---|
| Code | Unique ID of the plausibility logic |
| Description | Description of the plausibility logic. |
| Note | Any additional information to the description |
| Check for | |
| Check by Entity | This option is only available if ‘Check by contributor node’ is not selected. If selected, the check is performed on individual Entities. The logic operates on contributor entity categories (contributor amounts and contributor entity journals) and on groupings of categories containing only contributor entity categories. |
| Check by contributor node | This option can only be selected if ‘Check by Entity’ is not selected. If selected, the check is performed on contributor nodes, i.e. those nodes in the Entity hierarchy that are defined as ‘To approve’ or ‘To submit’ in the data collection process. The data is obtained by adding up the amounts related to the Entities that belong to the same nodes. The logic operates on contributor entity categories (contributor amounts and contributor entity journals) and on groupings of categories containing only contributor entity categories. |
| Include categories grouping with categories of the consolidator | This option is only available if ‘Check by contributor node’ is selected. If selected, the check is also performed on category groupings containing at least one consolidator Entity category. |
| Check by consolidator node | If selected, the check is performed on the consolidator nodes, i.e., the nodes that are defined as ‘To consolidate ’ in the Entity hierarchy within the consolidation process. The logic operates on the consolidator categories (consolidator amounts, consolidator entity journals, consolidation journals) and on categories groupings containing at least one consolidator entity category. |
| Reference data | |
| Scenarios | Specifies how to determine the scenario used to compare the data - Same as data to process (default): the scenario from which the data for comparison is read is the same as the one used to perform the data processing. - Fixed: the scenario from which the data for comparison is read is the one set out in ‘Fixed Scenario’. - Parametric: the scenario from which the data for comparison is read is the one set out in ‘Parametric Scenario’. |
| Fixed scenario | Only if Scenario =Fixed. Specifies the scenario from which the data is to be read. |
| Parametric Scenario | Only if Scenario =Parametric. The scenario from which the data is to be read, selected according to one of the following criteria. - PREV: scenario preceding the processed one - NEXT: scenario following the processed one - REF1... REF5: reference scenario 1... 5 matched with the processed scenario Note: if there are multiple values, they must be separated by commas (NEXT,REF1, ...). |
| Period | Specifies how to determine the period for the comparison of data. - Same as data to process (default): the period from which the data for comparison is read is the same as the one used to perform the data processing. - Fixed: the period from which the data for comparison is read is the one set out in ‘Fixed Period’. - Parametric: the period from which the data for comparison is read is the one set out in ‘Parametric Period’. |
| Fixed period | Only if Period =Fixed. Specifies the period from which the data is to be read. |
| Parametric period | Only if Period =Parametric. Period from which data is read, within the range −99 to 99. It is calculated as a “shift” from the period of the data being processed. |
| Period Length | Specifies how to calculate the data for comparison. - Year-to-date (default): the amount is based on the previous months, starting from the beginning of the year. For example, the amount of March is the sum of the amounts of January, February and March. - Periodic: the amount depends solely on the processed period. In this case, it is necessary to also specify how to calculate the previous period in the scenario. |
Fields in the ‘Data to check’ tab
| Element | Description |
|---|---|
| Data to read | Specifies the amount that will be read from the data tables. - Original amount: amount in original currency - Currency amount: transaction currency amount |
| Source filter | |
| Accounts | Accounts on which the logic operates. It can be a single account or a node in an account hierarchy. If not specified, all available accounts are taken into account. |
| Custom dimension | Dimensions on which logic operates. For each dimension managed, it can be either a single element or a node in a hierarchy defined on that dimension. If not specified, all elements available on the dimension are taken into account. |
| Category | Categories on which the logic operates. It can be a single category or a category grouping node. If not specified, all available categories are taken into account. |
| CTP entity | Ctp entities on which the logic operates. It can be a single entity or a node within an entity hierarchy. If not specified, all available Ctp entities are taken into account. If set, it applies only to the reading of IC data (amounts and entity journals). |
| Segment CTP Entity | Ctp entities for Segment on which the logic operates. It can be a single entity or a node within an entity hierarchy. If not specified, all available Ctp entities for Segment are taken into account. If set, it applies only to the reading of consolidation journals. |
| Counterparty custom dimension 2 | Ctp Custom dimension 2 on which the logic operates. It can be a single element or a node within a custom dimension 2 hierarchy. If not specified, all elements available on the custom dimension 2 are taken into account. If set, it is applied only to processes with relationship type "by entity – custom dimension 2" and only when reading IC data (amounts and entity journals) and consolidation journals (where the filter affects the Ctp custom dimension 2 for Segment). |
| Currency | Currency on which the logic operates. It must be a single currency. If not specified, all available currencies are taken into account. |
| Check by / Hierarchy | |
| Check by Account | Specifies how the logic behaves in relation to the account. - By element: the logic operates on a single account. - By total: the logic operates on the algebraic sum of the data movements. - By node: the logic operates on the algebraic sum of data movements across accounts belonging to the first level nodes associated with the specified hierarchy |
| Check by Custom dimension | For each managed custom dimension, this specifies how the logic behaves with the custom dimension. - By element: the logic operates on each individual element of the dimension - By total: the logic operates on the algebraic sum of data processed across the dimension's elements. - By node: The logic operates on the algebraic sum of data processed across dimension elements belonging to the first-level nodes associated with the specified hierarchy. |
| Check by Category | Specifies how the logic behaves with respect to the category. - By element: the logic operates on a single category. - By analytic element: the logic operates on individual entity or consolidation journals. If the category type is amount, then it operates on a single category - By total: the logic operates on the algebraic sum of data movements across categories. - By node: the logic operates on the algebraic sum of data movements across categories belonging to the first-level nodes of the specified hierarchy |
| Check by CTP Entity | Specifies how the logic behaves with respect to Ctp Entity. - Gross: the logic analyses only gross amounts. - By element: the logic operates on a single Ctp entity - By total: the logic operates on the algebraic sum of data movements across Ctp entities. - By node: the logic operates on the algebraic sum of data movements across Ctp Entities that belong to the first-level nodes associated with the specified hierarchy. |
| Check by Ctp entity for Segment. | Specifies how the logic behaves with respect to Ctp Entity for Segment. - By element: the logic operates by Ctp entity for Segment. - By total: the logic operates on the algebraic sum of data movements across Ctp entities for segment - By node: the logic operates on the algebraic sum of data movements across Ctp Entities for segment belonging to the first-level nodes associated with the specified hierarchy |
Fields in the '% impact calculation' tab
| Element | Description |
|---|---|
| Check percentage impact | Specifies whether percentages are to be calculated on the amounts to be compared. - No: no calculations are performed. - Yes: the amounts to be compared are added together in accordance with the settings in the ‘Sum up’ section. The proportion of each element or node is then calculated. Enable the following fields. |
| Sum up / Hierarchy | |
| Sum up account. | Specify how the account helps to determine the totals by which the individual amounts to be compared are to be divided. - No: the logic does not consider the account to determine the totals. - By element: the logic calculates a total for each account. - By node: the logic calculates a total for each first-level node associated with the specified hierarchy to which the accounts belong. |
| Sum up Custom dimension. | For each custom dimension managed in the environment, it specifies how the elements of the dimension contribute to determining the totals by which the individual amounts to be compared are divided. - No: the logic does not consider the elements of the dimension when calculating the totals. - By element: the logic calculates a total for each element of the dimension. - By node: the logic calculates a total for each first-level node associated with the specified hierarchy to which the dimension's elements belong. |
Fields in the Comparison tab
| Element | Description |
|---|---|
| Preliminary check | Optional check; the same rules as for the Plausibility check apply. |
| Plausibility check | Mandatory check An expression in SQL syntax to be applied to the amounts to be compared. The amounts related to the first data collection must be referred to via the "A1" string, while those related to the second data collection, via the "A2" string. Case when A1<>0 then ABS((A2-A1)/A1)*100 end |
| Check currency | Currency used to compare the result of the preliminary and plausibility check expression. If defined, the amounts will be converted accordingly. In fact, the amounts of the thresholds defined below are expressed in this currency; otherwise, they are expressed in the currency of the entities/journals being checked. The Fx rate used for the conversion is the Fx rate specified for the account of the current data collection. |
| Threshold for preliminary check | Threshold used to compare the result of the preliminary check expression, if specified. If the result of the expression is below the specified threshold, the subsequent checks are not performed and the diagnostic function does not record any errors for the data set being analysed. |
| Threshold for plausibility check: trivial error | Threshold used by the system to compare the result of the plausibility check expression and to determine if the error is trivial. If the result of the expression is below the specified threshold, the diagnostic assigns a‘Warning’ severity to the data set being analysed. |
| Threshold for plausibility check: non-blocking error | Threshold used by the system to compare the result of the plausibility check expression and to determine if the error is non-blocking. If the expression result is above the trivial error threshold and below the specified threshold, then the diagnostic assigns to the current data collection the “Non blocking” severity. |
| Threshold for plausibility check: blocking error | Threshold used by the system to compare the result of the plausibility check expression and to determine if the error is blocking. If the expression result is above the non-blocking error threshold and below the specified threshold, then the diagnostic assigns to the current data collection the “Blocking” severity. |
| Threshold exceptions for currency | Opens the page where you can set specific thresholds for the currencies of your choice. Useful when the Check Currency is not specified; in this case, amounts are assumed to be expressed in the currency of the entities or journals in the data set being checked. |
IMPORTANT: To ensure that the plausibility check is performed correctly, you must specify at least one of the thresholds. Moreover, the defined threshold values must be in increasing order; that is, the blocking error threshold must be greater than the non-blocking error threshold, and the non-blocking error threshold must be greater than the trivial error threshold.