Journal submission and rejection
Introduction¶
In addition to submitting entities, in CCH Tagetik you can also run journal submission.
Just as you must submit an entity before submitting any contributor node to which it belongs, you must submit a journal before submitting the entity to which it belongs. This can be done for (contributor and consolidator) entity journals and for consolidation journals.
Running the data processing¶
You can also simultaneously run the submission of all automatic journals, or those for which rows with manual origin are not present (INPUT_WEB, INPUT_DEFORM, BREAK_BACK, QDL or MAP_%).
If several journals are submitted/rejected simultaneously, for each journal only the significant steps are submitted, i.e. those specified in the process’s Business Workflow mapping for the entity to which the journal is related. This happens when several journals are selected or when the submission of automatic journals is run.
Submission is performed starting from the first step of the journal submission, up to the step in which the submission was requested.
Rejection is performed starting from the last step of the journals submission, going backwards to the step in which the rejection was requested.
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.
Enabling journal submission¶
Journal submission is activated in the process’s Business Workflow mapping, specifying a task workflow for every entity (entity or consolidator node) for which you want to submit the journals. See Task Workflow page.
Users authorised to submit and reject journals¶
Journals can be submitted only by users responsible for the submitting the entity to which the journal belongs.
Only users responsible for the entity to which the journal belongs, or who are responsible for the parent, can run a rejection, according to the indications given. The operation is run according to the restrictions indicated in the User enabled for journal rejection option in the general rules of submission.
The parent node of an entity is the first node to submit or approve in the data collection process. It is obtained by going up the entity hierarchy tree associated with the process, starting with the given element (excluded). 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 node 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/step of the journal submission 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 run by the owners of those tasks (seeDefine Entity Restrictions and Task.).
Conditions for journal submission¶
Journals must be submitted before the submission of the entity to which the journals belong.
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.
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 option Edit submitted /locked data in editability in user rights active (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 of journal submission can be related to a specific task workflow.
This 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.
Conditions for journal rejection¶
Journal rejection can take place only if the entity to which the journals belong has not yet been submitted.
Other journal submission/rejection functions¶
CCH Tagetik allows you to use these additional functions to assist with submitting journals:
- You can send an email of approval or rejection of a journal. Sending this email can be activated using the send email rules of the process. For more details, see Manage the sending of emails.
- You can block the journal rows (manual or from Calculation Logics processing) at the time a journal is submitted. The system changes the origin of the rows, placing the "SUB_" prefix before the original origin. This way, even if the journal is rejected, the data will still not be editable. This is activated from the process submission rules, using the With manual origin on journal submission and With calculation origin on journal submission options.