The following diagram illustrates the general process flows for form batch headers and form upload staging records. This describes the lifecycles of the base product business objects supplied for form batch header (C1-StandardformBatchHeader) and form upload staging (C1-FormUploadStaging). The expectation is that implementations should be able to use these base business objects as supplied.
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 the state Form Upload In Progress 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. This validation is not related to the specific form data attached, but rather more general issues with the staging record itself. If any errors are found, the form upload staging transitions to Suspended requiring a user to 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 does not change. 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.
An error may be received in the process of attempting to map the data. This is typically a result of a problem with the submission and not something a user is able to fix. In this case, the record is rejected.
The mapping algorithm may perform some basic form validation, for example to detect missing data such as a receive date. In this case the record is suspended and a user must fix the problems before continuing.
If any of the form upload staging records are rejected, the batch header transitions to Review Needed so that a user can review the batch and decide what to do next. A user may take either of these actions:
If a large number of records were rejected, the user may decide that there is something corrupt with the transmission and choose to Cancel the batch. 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.
If a small number or records are rejected, the user may decide to let the batch complete and determine the specific issues related to the rejected records.
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.
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:
The sections above describe the batch processing and lifecycle transition of the form batch header and form upload staging records using the base business objects. Since this functionality is BO driven, it can be customized based on your specific implementation requirements.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.