Controlling Automatic Processing

The goal when processing forms is to automatically process as many forms that can be automatically processed as possible, without anyone needing to review the form. However, for a form being added or corrected by a user, they system should not inadvertently pick up the form for processing in case a user is not yet finished with it. The way the system controls this differs slightly for Tax Form and Registration Forms. Note that in both cases, the logic described here is the logic supplied with the base product parent business object for each type of form. Implementations may choose not to adopt this business practice.

Tax Forms

Tax forms include a field called Automatic Post that is set to Y only for scenarios where a user is not working on the form. The tax form background processes provided with the base product to process the forms only select forms with this flag set to Y along with the other selection criteria included in the background process.

A form that is created manually does not set the flag to Y so it will never be picked up for batch processing while in the Pending state. This applies to audit tax forms, tax forms that were created as a result of a transfer, tax forms that were created as a result of an adjustment and tax forms that are simply created manually. A user is able to spend as much time as needed to create the form (and do interim saves). When the form is fully entered, the user clicks Validate or Validate and Post to progress the form. If the user clicked Validate and Post and the form does not have any exceptions, the user is finished. Otherwise
- If the user clicks Validate and the form passes validation, it transitions to the Ready for Post status. The user can review the form at this point and make additional changes if needed using the Re-edit button. Once the form is in a state where the user is happy with it, the user can click Post to transition the form to Posted real-time or can click Batch Post, which sets the Automatic Post flag to Y such that the form will be processed the next time the batch monitor process runs.
- If the form does not pass validation and transitions to the Suspended status, the user may correct the form as needed. Once the form passes validation and transitions to Ready for Post, the logic as described above applies.
- If a validation form rule indicates that additional information is needed and transitions to the Waiting for Information status, the same logic applies as for the Suspended status. When a user determines that the needed information is received and re-validates the form, the form eventually transitions to Ready for Post and the logic as described above applies.
The form upload process sets the Automatic Post flag to Y when creating a form. Therefore, forms uploaded into Pending state are processed by the batch monitor assuming the other selection criteria configured the batch monitor are satisfied.
- If the form does not have any exceptions, it progresses to the Posted state and the form is finished.
- If the form does not pass validation and transitions to the Suspended status or the Waiting for Information status, the automatic post flag is reset to null because at this point a user needs to get involved to progress the form. The logic as described for manually created forms applies. Once the form is corrected and is in Ready for Post, it can be progressed further as previously described.
A special background process exists to detect tax forms that have been waiting too long in a given state. This allows implementations to detect manually created or corrected forms that are not progressing; and does this outside of the standard form processing batch jobs. The background process is C1-TXSTL.

Registration Forms

The process for registration forms is a bit simpler. It does not include an Automatic Post flag. In addition, it does not include a Re-Edit state so forms in the Ready for Post state are considered ready to progress to Posted without any further modification by a user.

A form that is created manually is not picked up for batch processing while in the Pending state. The background monitor process plugged into the Pending state only looks for forms that were uploaded along with additional selection criteria. (Refer to the background process C1-RGMU for more information). A user is able to spend as much time as needed to create the form (and do interim saves). When the form is fully entered, the user clicks Validate or Validate and Post to progress the form. If the user clicked Validate and Post and the form does not have any exceptions, the user is finished. Otherwise
- If the user clicks Validate and the form passes validation, it transitions to the Ready for Post status. At this point, the user can click Post to transition the form to Posted real-time or can simply let the form be picked up the next time the batch monitor process runs.
- If the form does not pass validation and transitions to the Suspended status, the user may correct the form as needed. Once the form passes validation and transitions to Ready for Post, the logic as described above applies.
- If a validation form rule indicates that additional information is needed and transitions to the Waiting for Information status, the same logic applies as for the Suspended status. When a user determines that the needed information is received and re-validates the form, the form eventually transitions to Ready for Post and the logic as described above applies.
Forms uploaded into Pending state are processed by the batch monitor assuming the other selection criteria configured the batch monitor are satisfied.
- If the form does not have any exceptions, it progresses to the Posted state and the form is finished.
- If the form does not pass validation and transitions to the Suspended status or the Waiting for Information status, the automatic post flag is reset to null because at this point a user needs to get involved to progress the form. The logic as described for manually created forms applies. Once the form is corrected and is in Ready for Post, it can be progressed further as previously described.
A special background process exists to detect registration forms that have been waiting too long in a given state. This allows implementations to detect manually created or corrected forms that are not progressing; and does this outside of the standard form processing batch jobs. The background process is C1-RGSTL.