Submission rules page

Admin

Application database > Data Processing tile > Data entry & Submission rules > Submission rules

Application database > Navigation panel > Processes & Workflow > Submission rules

Purpose of the page

This page allows you to set up the general rules that are run for submission.

These rules are valid for all submission data processing, but can be customised for individual processes. See Submission rules page.

Page sections

Section	Description
Submit	Defines specific behaviours for the data processing run on submission and for how to purge submission tables, run diagnostics on steps prior to the submitted step, and store diagnostic data offline.
Lock data	Defines the method that the system uses to make data that contributed to the submission of an entity or journal no longer editable, even if rejected. The origin is no longer manual and users must input new data to leave a trace of the corrections made.
Reject	Defines the specific behaviour for performing rejections
Override submission	Defines submission overrides.

Fields in the Submission section

Element	Description
Run data processing on submission	Allows you to run all data processing enabled on the process automatically in the submission launch step (with the exception of cash flow planning and closing).
Exclude Other calculation logics from the data processing on submission	Exclude the execution of all “Other” type calculation logics enabled on the process in the data submission step. Note: this option makes sense only if the Run data processing on submission option is selected.
Also include the stored procedure	On running the submission, it enables the execution of a stored procedure that meets the minimum requirementsCCH Tagetik. Note: this option makes sense only if the Run data processing on submission option is selected. Run restrictions for submission stored procedures: - The name of the stored procedures must begin with CPM_SP_. - The stored procedure must use the following parameters: - PROCESS: data collection process - ENTITY_HIERARCHY The process’s organisational hierarchy - STEP_LIST List of steps - 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
Exclude Purge submission tables	Allows the optional carryforward of submission information, when there is a change to the organisational hierarchy in a deployment step of entities in a data collection process.
Diagnose all the steps before the submitted step	During submission of the step, all the errors in all the previous steps are checked, or only those not yet submitted. This is useful if there are users who have the Edit submitted / locked data in editability option enabled in their user rights. See User Rights: define Attributes,
Store diagnostic result on submission	This generates and saves a PDF report containing the diagnostic results on conclusion of an entity submission. The report can be downloaded from the contributor or consolidator cockpit ().
Exclude check on open forms at submission	Makes it optional to check that there are no forms opened in data entry mode at the time of submitting an entity.

Fields in the Lock data section

Element	Description
With manual origin on the Journals submission	On successful submission of a journal, the system places the SUB_ prefix before the original origin on the journal rows with manual origin involved in the submission.
Calculation on journal submission	On successful submission of a journal, the system places the SUB_ prefix before the original origin on the journal rows calculated by the calculated accounts data processing involved in the submission.
With manual origin on submission of the entities/nodes	On successful submission of an entity, the system places the SUB_ prefix before the original origin on the amount rows (gross and intercompany) amount rows and journal rows with manual origin involved in the validation.
With calculation origin on the submission of the entities/nodes	On successful submission, the system places the SUB_ prefix before the original origin on the (gross and intercompany) amount rows and journals generated by the calculated accounts data processing involved in the validation

Fields in the Rejection section

Element	Description
Mandatory notes	Makes it mandatory to enter an explanatory note to allow rejection of the data.
Mandatory reason	Makes it mandatory to select a reason for rejection to allow rejection of the data. SeeReasons for Rejection Page.
User enabled for journal rejection	The rejection of an entity/journal is carried out by the users responsible for the parent entity. For journals, the users responsible for the entities to which the journals belong are often the same users that edit/submit them. This option raises the responsibility for the rejection by one level. - User responsible for the entity to which the journal belongs - User responsible for the parent node of the entity to which the journal belongs

Fields in the Override submission section

Element	Description
By user	Allows authorised users to submit the step even if there are blocking errors. This is only possible under the following conditions: - The user has the rights to submit the entity. - In user rights, the user selected the Submit even with blocking errors option. If it is not selected, in the presence of blocking errors the submission fails. See User lists.
With authorization of blocking errors	Allows you to submit the step, even if there are blocking diagnostic errors, provided they have been authorised. When the option is active, in the diagnostic result of the submission, errors with Blocking severity which were authorised pass to Authorised blocking. However, this occurs only if the Enable detected errors trace option is active in the validation rules. See Validation rules Page.