Validation rules page
Admin
Application database > Data Processing tile > Diagnostic > Validation
Application database > Navigation panel > Data Processing > Diagnostic > Validation
Purpose of the page¶
This page allows you to set the validation rules for diagnostic checks.
Generic rules
| Field | Description |
|---|---|
| Validation | |
| Run data processing on diagnostic | Allows you to run all data processing enabled for the process (with the exception of cash flow planning and closing) when running the diagnostics. |
| Also includes the stored procedure | Only with Run data processing on diagnostic selected. Include a stored procedure that meets CCH Tagetik’s minimum requirements in the data processing to be run when diagnostics is launched. The stored procedure only works on original scenarios/periods. The stored procedures that can be run by the diagnostic are those whose name begins with 'CPM_SP_'. To enable the stored procedure to read the diagnostic's parameters, these must have the following names: - PROCESS: data collection process - ENTITY_HIERARCHY: process organizational hierarchy - STEP_LIST: steps list - ORIGINAL_SCENARIO_PERIOD_LIST: list of original scenarios / periods - ENTITY_LIST: list of entities - CONTRIBUTOR_NODE_LIST: list of contributor nodes - CONSOLIDATOR_NODE_LIST: list of consolidator nodes For more details on stored procedures, see Stored proceduresStored. |
| Diagnostic result: Show forms on row | Allows you to view, for every error on the control group or account in the diagnostic result window, the forms on which the control group accounts can be edited or the account itself. Note: From the diagnostics result window, standard (non-transactional) forms can be edited via Excel or web. |
| Categories for which to show the result | Opens a page to select the categories for which to display the validation of the year’s result, even in the absence of unbalanced amounts. Note: for control group $BS_ |
| Result log | |
| Enable detected errors trace | Allows you to log errors returned by diagnostics so you can consult, justify and authorise them. - Do not manage: errors will not be archived - Only manage for blocking signals: only blocking errors will be archived - Manage the table for all signals: all errors will be archived If you decide to store the errors, then they will be inserted/updated at each submission or each execution of the diagnostic with log update. Note: only logged errors are saved and can therefore be consulted over time. |
| Don't propagate the authorized blocking error information | This check looks for the presence of blocking errors authorised by users responsible for the entity on which diagnostics were run. - Do not run: the check is not performed. - Blocking: the check is performed and the presence of blocking and authorised errors is reported with blocking severity. - Non-blocking: the check is performed and the presence of blocking and authorised errors is marked as being of non-blocking severity. - Only Diagnostic: the check is only run if explicitly requested by manually running the diagnostic from the Detail summary (for the contributor) or Overview (for the consolidator) cockpit tabs; in this case it is possible to customise the filters before running the data processing. However, whenever diagnostics are run automatically (from the cockpit/from other data processing), the check is not performed. The prerequisites for running this check are: - the traceability of errors found by diagnostics is enabled - the submission mechanism is enabled in the submission rules via authorisation of blocking errors |
| Journals submission validation | |
| Diagnose Manual journals submission | The check verifies that the manual journals belonging to the entity on which the diagnostics were run have been submitted. Manual journals are those for which at least one row has a manual origin (INPUT_WEB, INPUT_DEFORM, BREAK_BACK, QDL, MAP_%, SUB_%). A prerequisite for the execution of this check is that journal submission is enabled on the process, i.e. task flowcharts for journal submission have been specified in the Business Workflow mapping. - Do not run: the check is not performed. - Blocking: the check is performed and the non-submitted manual journals are reported with blocking severity. - Non-blocking: the check is performed and the non-submitted manual journals are marked as being of non-blocking severity. - Only Diagnostic: the check is only run if explicitly requested by manually running the diagnostic from the Detail summary (for the contributor) or Overview (for the consolidator) cockpit tabs; in this case it is possible to customise the filters before running the data processing. However, whenever diagnostics are run automatically (from the cockpit/from other data processing), the check is not performed. |
| Diagnose Automatic journals submission | The check verifies that the automatic journals belonging to the entity on which the diagnostics were run have been submitted. Automatic journals are those that do not contain any rows with manual origin (INPUT_WEB, INPUT_DEFORM, BREAK_BACK, QDL, MAP_%, SUB_%). A prerequisite for the execution of this check is that journal submission is enabled on the process, i.e. task flowcharts for journal submission have been specified in the Business Workflow mapping. - Do not run: the check is not performed. - Blocking: the check is performed and the non-submitted automatic journals are reported with blocking severity. - Non-blocking: the check is performed and the non-submitted automatic journals are marked as being of non-blocking severity. - Only Diagnostic: the check is only run if explicitly requested by manually running the diagnostic from the Detail summary (for the contributor) or Overview (for the consolidator) cockpit tabs; in this case it is possible to customise the filters before running the data processing. However, whenever diagnostics are run automatically (from the cockpit/from other data processing), the check is not performed. |
| Intercompany Cockpit | |
| IC cockpit: Balancing threshold of Compensation reconciliation accounts | The threshold, if set, is applied during the matching of relationships resent in the IC Cockpit. Specifically, it will be used by the check that verifies the balancing of amounts linked to variation/detail types used on several matching rules. |
Specific rules
| Field | Description |
|---|---|
| Equality control groups | Opens a page to define specific rules to be applied to control groups with equality operators. |
| "Other" control groups | Opens a page to define specific rules to be applied to “other” control groups, namely control groups with an operator other than equality. |
| Accounts | Opens a page to define specific control rules for accounts. |