Mass Hold Request Creation

Oracle Revenue Management and Billing provides the ability to create multiple hold requests at once through the Upload Request feature. The C1-HoldUploadRequest business object enables you to create an upload request for mass hold request creation.

You need to create an upload request type for the C1-HoldUploadRequest business object. You can then upload a mass hold request creation file in the CSV format using the respective upload request type. The mass hold request creation file should contain records with the following information – hold request type, hold request start date, hold request end date, hold reason, hold entity, hold entity start date, hold entity end date, hold processes, hold process start date, hold process end date, and hold characteristics. For more information, see Mass Hold Request Creation CSV Format.

On uploading a mass hold request creation file, the system creates an upload request in the Draft status. The data records are created in the Pending status. The system then validates the following for each record:

• Hold request type, hold request start date, hold request end date, hold reason, and hold entity are specified in the record.

• If the hold entity is ACCT, either the account ID or account identifier type and account identifier is specified in the record.

• If the hold entity is PERS, either the person ID or person identifier type and person identifier is specified in the record.

• If the hold entity is BILL, the bill ID is specified in the record.

If the hold entity is ACCT and the entity ID is not specified in the record, the system derives the account ID using the respective account identifier type and account identifier combination. Similarly, if the hold entity is PERS and the entity ID is not specified in the record, the system derives the person ID using the respective person identifier type and person identifier combination. If the system could not derive the account ID using the account identifier type and account identifier combination or if the system could not derive the person ID using the person identifier type and person identifier combination, the status of the record is changed to Invalid. In addition, if any of the above validations fail, the status of the record is changed to Invalid.

On clicking the Validate button, the system checks whether the upload request must be validated in the real time (i.e., immediately) or in the deferred mode (i.e., in the background). If the total number of records in the upload request does not exceed the online record validate limit, the system validates the following in the real time:

• The hold request type given in the record is valid and active in the system.

• The hold reason is a valid and active value of the HOLD_​REASON_​FLG lookup field.

• The hold entity is a valid and active value of the HOLD_​ENTITY_​LVL_​FLG lookup field.

• The account ID given in the record is valid when the hold entity is ACCT.

• The person ID given in the record is valid when the hold entity is PERS.

• The bill ID given in the record is valid when the hold entity is BILL, and the outstanding amount of the bill is not equal to zero.

• The process’s start and end dates are within the hold request start and end dates.

• The entity’s start and end dates are within the hold request start and end dates.

• The entity’s start and end dates should fall within at least one process’s start and end dates.

• At least one process is kept on hold for the entity in the record.

• The value of each hold process in the record is set to either Y or N.

• The hold request start and end dates are set to either the system date or a future date.

• The start dates are not later than the end dates and the end dates are not earlier than the start dates.

• The same entity is not already kept on hold with the same hold reason through an existing draft or active hold request.

• The Overdue, Auto Pay, and Refund processes are not set to Y when the hold entity is set to PERS.

• The Bill Generation, Overdue, Auto Pay, Refund, and Delinquency processes are not set to Y when the hold entity is set to BILL.

• Both the Overdue and Delinquency processes are not set to Y at the same time in the record.

  Note: The Overdue process is valid for the financial services and health insurance domains, but the Delinquency process is valid only for the health insurance domain.

• The two or more records with the same entity ID do not exist in the upload request.

If any of above validations fail, the status of the record is changed to Invalid. However, if all the above validations are successful, the status of the record is changed to Valid. Once all the pending records in the upload request are validated, the status of the upload request is changed to Validated.

However, if the total number of records in the upload request exceeds the online record validate limit, the system changes the status of the upload request to Deferred Validation. The system then validates the records and changes the status of the upload request from Deferred Validation to Validated when the C1-UPLRQ batch is executed.

On clicking the Submit button, the system checks whether the approval is required for the upload request. If the approval is required for the upload request, the status of the upload request is changed to Approval In Progress. However, if the approval is not required for the upload request, the status of the upload request is changed to Submitted.

The approver can either approve or reject the upload request based on the observations. On approving an upload request, the status of the upload request is changed to Approved. However, on rejecting an upload request, the status of the upload request is changed to Rejected.

Once the status of the upload request is changed to Submitted or Approved, the system checks whether the upload request must be processed in the real time (i.e., immediately) or in the deferred mode (i.e., in the background). If the number of valid records in the upload request does not exceed the online record process limit, the system changes the status of the upload request to Processing. However, if the number of valid records in the upload request exceeds the online record process limit, the system changes the status of the upload request to Deferred Processing. The system then changes the status of the upload request from Deferred Processing to Processing when the C1-UPLRQ batch is executed.

Once the status of the upload request is changed to Processing, the system fetches a list of records which are in the Valid status. For each valid record with a unique combination of the hold request type, hold request start date, hold request end date, hold reason, hold entity, hold entity start date, hold entity end date, comments, hold process details, and hold characteristic details, the system creates one hold request using the entity business object specified in the upload request type. However, if there are multiple entity IDs with the same combination, the system adds all the entities in the same hold request.

If the Activation Approval option is selected in the respective hold request type, the status of the hold request is set to Activation Approval In Progress. However, if the Activation Approval option is not selected in the respective hold request type, the system checks the number of entities added in the hold request. If the number of entities added in the hold request does not exceed the defer processing count (specified in the hold request type), the status of the hold request is set to Active. However, if the number of entities added in the hold request exceeds the defer processing count, the status of the hold request is set to Deferred Processing.

Once the hold request is successfully created, the status of the record is changed to Processed. However, if any error occurs while creating the hold request, the status of the record is changed to Error. Finally, the status of the upload request is changed to Processed.