Forms Upload Process Flow

Process Flow for Form Batch Headers and Form Upload Staging Records

The following diagram illustrates the general process flows for form batch headers and form upload staging records.

Form upload staging records are not processed until the form batch headers they belong to have passed validation.

Any errors during the validation of a form batch header cause it to suspend for user review. The user is responsible for resolving the issues and re-validating the form batch header. At this point, the form upload staging records are still in their initial states. In some cases, the user may decide that the batch needs to be canceled, in which case the related form upload staging records are also canceled.

When the batch header passes validation, its form upload staging records can start processing. The batch sits in that processing state until either all staging records are in some final state - i.e. form added successfully, rejected or canceled.

Each form upload staging record goes through a number of processing steps before the corresponding tax form or registration form can be added. Any issues from these processing steps prevent the corresponding form from getting added.

• The form upload staging is validated. Any errors during form upload staging validation cause the form upload staging to get suspended for user review. The user is responsible for resolving the issues and re-validating the form upload record. In some cases, the user may decide that the form upload staging needs to be canceled. Note that at this point, the corresponding form is not created yet.

• When a form upload staging suspends, its batch header status stays the same - i.e. in the 'processing' state. The idea is that a user may be able to fix the issue with the staging record or decide to cancel it. Either action on the current staging record should not prevent other staging records in the batch from being processed.

• When the form upload staging passes validation, it goes through the important step of mapping the fields from the raw XML into the target Form business object schema.

• Any problems with this transformation are likely to be technical issues (e.g. malformed XML) that a user would not be able to fix. As a result, the form upload staging record gets rejected.

• On the other hand, if the transformation is successful, the form upload staging goes into a state where the tax form or registration form can be added / loaded.

If any of the form upload staging records is rejected, the batch header requires a user to review the batch and decide what to do next. A user may take either of these actions:

• Cancel the batch. This is likely when a majority of the records are rejected. Canceling the batch also cancels its form upload staging records. Note that at this point, there are no forms existing yet because the batch is in a cancelable state.

• Let the batch complete. This happens if only a few records in the batch got rejected.

When all form upload staging records are either in Ready for Load state or are Canceled, the batch transitions to the Ready to Complete state. This interim state is one where batch cancellation is no longer possible. This ensures two things:

• That forms for that batch are added at the same time

• That once the forms are added, the batch cannot be canceled. Allowing batch cancellation when some forms are already added would require cleaning up the forms - i.e. canceling any pending / suspended / waiting forms get canceled and reversing any posted tax forms.

When the batch is in a Ready to Complete state, the forms in that batch can be added. When the forms are successfully added, their form upload staging records go to their final state, Form Added. Once all form upload staging records are in a final state, the batch is completed.

Forms Upload Batch Process Flow

The following diagram shows the forms upload process batch flow when using the base business objects for form batch header C1-StandardFormBatchHeader and form upload staging record C1-FormUploadStaging, and the base monitor background processes.

The processing of a form, from initial upload to posting is performed by the background processes as follows:

• C1-FBHMD (Form Batch Header Deferred Monitor)
  • Form batch header records transitioned from Pending to Form Upload in Progress.
  • Validates the form batch header records.
• C1-FUSDM (Form Upload Staging Deferred)
  • Form upload staging records transitioned from Pending to Ready to Load.
  • Validates the form upload staging records whose form batch header is in Upload in Progress.
  C1-FBHM (Form Batch Header Monitor)
  • Form batch header records transitioned from Form Upload in Progress to Pending Complete.
  • Updates the record counts on the form batch headers.
• C1-FUSPC (Form Upload Staging Deferred Monitor)
  • Form upload staging records transitioned from Ready to Load to Form Added.
  • Processes form upload staging records whose form batch header is Pending Completion.
• C1-FBHMD (Form Batch Header Deferred Monitor)
  • Form batch header records transitioned from Pending Complete to Complete.
  • Completes form batch header records.
• C1-TXMTD (Tax Form Deferred Monitor) and C1-RGFBD (Registration Form Deferred Monitor)
  • Tax form and registration form records are transitioned from Pending to Posted, Suspended, Waiting for Information.
  • Applying validation rules.
  • Create payments where applicable.
• C1-FBTC (Balance Form Batch Tender Controls)
  • Balances any tender control created for batch headers containing payments.