Submission and rejection of nodes and entities
Introduction¶
Nodes and entities can be submitted and rejected at three levels:
- by entity
- for contributor nodes, i.e. nodes to be submitted or approved in the data collection process
- for consolidator nodes, i.e. nodes to be consolidated in the consolidation process
Running the data processing¶
Submission and rejection are run only on the original scenarios/periods of the process that are not stored off-line and that the user has the right to edit.
Submission is performed starting from the first step of the process, up to the step in which the submission was requested.
Rejection is performed starting from the last step of the process, going backwards to the step in which the rejection was requested.
For entities and contributor nodes, the contributor and mixed steps are submitted or rejected. For consolidator nodes, the consolidator and mixed steps are submitted or rejected.
On the steps in the Business Workflow, you can activate the Allow submission option only if the previous step is submitted (seeSteps Page). In this case, you can:
- Start the submission of a step only when all the entities and contributor nodes have been submitted on the previous steps.
- Start the rejection of a step only when all the entities and contributor nodes have been rejected on the next steps.
Users authorised to submit and reject entities and nodes¶
Submission can be performed only by submission users, or managers of the entity.
Rejection can be performed only by submission users of the parent entity, or managers of the parent entity of the entity that you want to reject.
The parent entity of an entity or a contributor node is the first node to submit or approve in the data collection process. This is obtained by going up the entity hierarchy tree associated with the process, starting with the given element (exclusive). If that node is not found, take the first node to consolidate in the consolidation process, always by going up the tree starting from the given element (excluded).
The parent entity of a consolidator node is the first node to consolidate in the consolidation process. This is obtained by going up the entity hierarchy tree associated with the process, starting with the given element (excluded).
If the entity is related to a task workflow that requires the running of post-submission approval tasks and some of the approval tasks have not yet been run, the rejection can also be performed by the owners of those tasks (see Define Entity Restrictions and Task).
Conditions for submission of entities and nodes¶
To be able to submit an entity, there cannot be any forms open in data entry mode on the entity, unless the check has been disabled in the process submission rules, using the Exclude check on open forms at submission option.
In order for a contributor node to be submitted, all of its children (entities and/or contributor nodes) must first be submitted .
Instead, to submit a consolidator node, the following conditions must be met:
- All of its children, entities and/or nodes have been submitted.
- If the node also has to be submitted or approved in the data collection process, the related contributor node has been submitted.
If a start date is set for the submission (see Deadline Dates Page), the entity cannot be submitted before that date.
In addition to checking that the conditions necessary for the submission have been met, the submission data processing runs the diagnostic and checks that there are no blocking errors, either on the step in submission, or on the previous ones.
Note: the diagnostic will not be run during the submission of a contributor node "to be approved" in the data collection process.
Normally, the diagnostic on previous steps does not return blocking errors, because those steps have already been submitted. However, it may happen if there are users who have the Edit submitted / locked data in editability option active in User rights (seeUser Rights: define attributes). To avoid submission being blocked in this case, you can deactivate the Diagnose all the steps before the submitted step option in the submission rules of the process.
Also, an administrator user can enable the option to override the process submission , to make it possible to submit even in the presence of blocking errors. This can be done using two options that can be activated in the process submission rules:
| Rule | Description |
|---|---|
| Override submission: by user | Users who have the option “Submit even in the presence of blocking errors” in their User rights window can submit even in the presence of blocking errors. |
| Override submission: with authorisation of blocking errors | When the option “Enable detected errors trace” is active in the validation rules, blocking errors can be authorised, thus allowing the entity to be submitted. |
Submission from task workflow¶
Each entity/step to submit can be related to a specific task workflow. This can prevent multiple operational tasks from being run before the submission task. In that case, all these tasks must be run in order to be able to submit the entity.
The task workflow may require the running of approval tasks after the submission task. In this case, when the submission task is run, the data are blocked and are no longer editable.
However, for the submission to be considered complete, all the approval tasks must also be run.
If no alternative approval paths, or alternative approval sequences, have been enabled for the task workflow, some approval tasks might not be essential. For more details on the Enable alternative approval paths option, seeTask Workflow Page.
A task workflow with approval tasks is typically used when you want the various approvals to be made by different users. You can ensure this by restricting users by Entity and task, through the Run Submission tasks option. For for information on restrictions, see Define Entity Restrictions and Task.
Note: the “4 eyes” principle is applied if a user has run rights on multiple tasks in a task workflow; they can then run more than one task only if there are no other users that have run rights on the task or, if they exist, they have all run at least one task.
For nodes, if the Submit also underlying nodes and entities option is active on the submission task, the underlying entities will be submitted, in addition to the nodes. For contributor nodes, the underlying entities are the child contributor nodes and the entities. For consolidator nodes, the underlying entities are the child consolidator nodes.
Prerequisites for rejection of entities and nodes¶
To reject an entity, the parent node must have been rejected first.
To reject a consolidator node, its parent node, if any, must have been rejected.
To reject a contributor node, the following conditions must be met:
- The parent node, if any, has been rejected.
- If the node also has to be consolidated in the consolidation process, the related consolidator node has been rejected.
To reject a consolidator node, its parent node, if any, must have been rejected.
Other entity submission/rejection functions¶
CCH Tagetikallows you to use these additional functions to assist with submitting and rejecting entities:
- You can run all the data processing operations enabled for the process at the time the submission is run. It is activated using the Run data processing upon Submission option, and can be combined with the Exclude Other calculation logics from the data processing on submission and Also includes the stored procedure options.
- You can run a job on conclusion of submission or rejection: for example, an ETL that populates the list of projects once a new project has been approved. This is activated from the process submission rules, using the Execution plan of jobs to run on submission and rejection link in the Execution plan of jobs to run on submission and rejection Page.
- You can store the diagnostic result of the submission offline. This is activated from the process submission rules, using the Store diagnostic result on submission option. The PDF report stored offline can be downloaded from Show log, on the contributor and consolidator cockpits.
- You can send an email on submission/approval of an entity or the submission of the last entity in a node or, also, to send a reminder of submission. All these types emails to send can be activated using the send email rules of the process. For more details, see Manage the sending of emails.
- You can block the (gross and IC) amount and journal rows (manual or from Calculation Logics processing) at the time an entity is submitted. CCH Tagetik changes the origin of the rows, placing the "SUB_" prefix before the original origin. This way, even if the entity is rejected, the data will still not be editable. This is activated from the process submission rules, using the With manual origin on the submission of Entities/nodes and With calculation origin on the submission of the Entities/nodes options.
- You can make it mandatory to insert an explanatory note and/or a reason for rejection, at the time of rejection. This is enabled from the process submission rules, using theMandatory notes and Mandatory reason options.