Skip to content

Authorisation of diagnostic errors

Introduction

For processes in which diagnostic data storage is enabled, it is possible to manually authorize blocking errors on the data. This operation changes the severity of the error from Blocking to Authorized Blocking and still allows submitting the Entity.

This function is enabled by the submission rules of the process with the option Override submission - With authorization of blocking errors(Submission Rules Page).

Detected errors can only be authorised by the users responsible for the parent Entity for which the error is detected, namely by the same users who can reject the Entity. For authorized errors, you can enter a comment; if you do not do so, a note stating that it is an authorized error is automatically added.

IMPORTANT: You can authorize multiple errors at the same time only if all of them are eligible for authorization. Otherwise, the system returns an error message: 'It was not possible to authorize some errors'.

To find out the exact reason why an error cannot be authorized, try authorising that specific error: the system will display the specific reason why it cannot be authorised.

When the archive's content is updated, it may happen that an authorised error that was previously present in the log is no longer detected by the diagnostics checks:

If... Then...
there are no comments on the error. the error is removed from the log.
there are comments on the error. the error is kept and labelled as 'Corrected'. Corrected errors are no longer taken into account, so if the same error occurs again, this is considered as a new error. Note: corrected errors are not normally displayed, due to a pre-set filter on the log. You can still configure CCH Tagetik to show them .

For processes that manage the diagnostic log with authorization of blocking errors, it may be useful to enable the diagnostic of authorized blocking errors (Diagnostic of authorized blocking errors).

Criteria for authorizing an error

For an error to be authorised, all the following conditions must be fulfilled:

  • The error's severity must be Blocking.
  • The error should not have already been corrected, namely it should not be an unbalanced amount that is no longer present in the system, but is still stored in the log because there are comments for it.
  • The error must not have already been authorised, unless it was authorised but then the authorisation was invalidated.
  • The entity the error refers to must not be submitted.
  • If the error concerns a journal for an entity for which the journals submission is required, the journal must not be submitted.
  • A justification for the error must be provided by a user different from the authorizing user.
  • The user must be enabled to authorize the errors, namely they must be responsible for the parent entity of the entity to which the error refers.

Information on authorised errors

When an error is authorised, the following information is saved in the log:

Attribute Description
Authorized This attribute indicates whether the error was authorised (= true) or not.
Authorized amount Amount at the time of authorization. - For control group errors: difference between the amount of the child accounts and the amount of the parent accounts - For gross sign errors: amount - For IC sign errors: IC amount - For IC capacity errors: difference, in absolute value, between the IC amount and the gross amount
User authorization Authorising user
Date authorization Date and time the error was authorised

Note: the data on authorised errors remain editable, so it is possible that when the log is next updated, some errors will no longer exist or the amounts will change.

Removal of error authorisation

The authorisation of an error can be removed. Only the authorising users are allowed to do it, i.e. the users responsible for the parent entity of the entity on which the error is detected. For errors whose authorisation is removed, it is possible to enter a comment; if no comment is provided, a note indicating that the authorisation was removed is added automatically.

IMPORTANT: It is possible to remove authorisation on several errors at the same time. If on some errors this is not possible, an error message is displayed: 'It was not possible to remove the authorization of some errors '.

To find out the exact reason why the authorisation on an error is not removable, try authorising that specific error. the system will display the specific reason why authorization on a given error cannot be removed.

It is not possible to submit entities with errors on which authorisation has been removed. Such errors will have to be authorised again.

Requirements for removing the authorization of an error

For the authorization of an error to be removed, all the following conditions must be fulfilled:

  • The error's severity must be Blocking.
  • The error should not have already been corrected, namely it should not be an unbalanced amount that is no longer present in the system, but is still stored in the log because there are comments for it.
  • The error must already have been authorised and the authorisation must not have been invalidated or removed.
  • The entity the error refers to must not be submitted.
  • If the error concerns a journal for an entity for which the journals submission is required, the journal must not be submitted.
  • The user must be enabled to cancel the authorization, namely they must be responsible for the parent entity of the entity to which the error refers.

Invalidation of errors

Since the authorization of errors does not correspond to a submission, the authorized amounts are always editable. Therefore, each time the log is updated, it may happen that some of the errors related to control groups, gross sign, IC sign, and IC capacity have changed in amount. If the unbalanced amount changes sign or increases in absolute value, CCH Tagetik will automatically invalidate the authorisation.

The invalidation will be displayed in the log in the 'Invalid' column.

It is not possible to submit entities with errors on which authorisation has been invalidated. Such errors will have to be authorised again.