Entity corrections require information unique to the particular instance that is typically not provided by the interface. For example, the reason for the correction. Some types of entity corrections required even more specific details in order to produce the mass action. For example, the mass suppression entity correction type requires a suppression reason and suppressed entity to be defined. The product supports two different entity correction lifecycles based on whether or not the additional information is needed prior to the validation of the entities or not.
For use cases where the addition information is not required for validation of the entities, the lifecycle follows the pattern of Pending > Validated > Approval in Progress. Assuming that an interface creates the pending record and a deferred monitor batch job picks up the record for validation, the appropriate user group is alerted when the record is in the Approval in Progress state at which time the additional data may be provided.
For use cases where the addition information is required for validation of the entities, the lifecycle follows the pattern of Initial > Pending > Validated > Approval in Progress. A user need to get involved at two different steps.
A user group is alerted as soon as the record is created in Initial state at which time the additional data may be provided. Once the user enters the data, the record may be transitioned to Pending allowing the deferred monitor to pick up the record for validation.
Once the record is validated, a user group is alerted that the record is in the Approval in Progress state at which time the validation results can be reviewed and the record can be approved or rejected accordingly.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]