Mass Refund Request Creation

Oracle Revenue Management and Billing provides the ability to create multiple refund requests at once through the Upload Request feature. The system allows you to refund a credit bill, a credit bill line item (i.e., a bill segment or an adjustment), a specific payment, all the payments of a payment event, and/or a credit adjustment of an account through a refund request. The C1-RefundUploadRequest business object enables you to create an upload request for mass refund request creation.

You need to create an upload request type for the C1-RefundUploadRequest business object. You can then upload a mass refund request creation file in the CSV format using the respective upload request type. The mass refund request creation file should contain records with the following information – refund request type, account details, entity type, entity ID, refund adjustment type, refund amount, comments, and refund characteristics. For more information, see Mass Refund Request Creation CSV Format.

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

• Either the account ID or account identifier type and account identifier is specified in the record.

• Refund request type, entity type, entity ID and refund amount are specified in the record.

• If the entity type is Adjustment, then the adjustment ID given in the record is valid.

• If the entity type is Bill, then the bill ID given in the record is valid.

• If the entity type is Bill Segment, then the bill segment ID given in the record is valid.

• If the entity type is Payment Event, then the payment event ID given in the record is valid.

• If the entity type is Payment, then the payment ID given in the record is valid.

Based on the entity type and entity ID, the system derives the original amount and currency of the respective entity. If the adjustment type is not specified in the record, the system derives the adjustment type from the respective refund request type. Similarly, if the account ID is not specified in the record, the system derives the account ID using the respective account identifier type and account identifier combination.

If the system could not derive the adjustment type, or account ID using the account identifier type and account 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 account ID given in the record is valid.

• The entity type is a valid and active value of the REF_​WO_​ENTITY_​FLG lookup field.

• The entity type given in the record for the entity ID is correct.

• The entity (i.e., adjustment, bill, bill segment, payment event, or payment) exists for the respective account in the system.

• The payment ID given in the record is in the Frozen status and is matched against the suspense or excess credit contract.

• The bill ID given in the record is in the Complete status.

• The bill segment ID given in the record is in the Frozen status.

• The adjustment ID given in the record is in the Freezable or Frozen status.

• The refund request type given in the record is valid and in the Active status. Its action flag is set to Refund.

• The refund amount is greater than zero.

• The refund amount is not greater than the eligible refund amount and the eligible refund amount is not equal to zero.

• The adjustment type given in the record is valid and its A/P Request Type Code flag is set to Refund.

• One record with a bill (for example, B01) and another record with the bill segment (for example, BS01) or adjustment (for example, AD01) of the same bill (i.e., B01) are not present in the upload request.

• One record with a payment event (for example, PE01) and another record with the payment (for example, PY01) of the same payment event (i.e., PE01) are not present in the upload request.

• The amount matches the decimal positions of the respective currency.

• The entity is not already included in any refund request that is in the non-final status.

• The characteristic type given in the record is valid and its characteristic entity is set to Refund/Write Off Request.

• The adhoc characteristic values are validated as per the validations defined in the respective algorithm.

• The predefined characteristic value is already defined for the characteristic type.

• The foreign key reference characteristic value is valid.

• The two or more records with the same entity type and entity ID combination 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 refund request type and account ID, the system creates a refund request for the account. However, if there are multiple entity IDs with the same combination, it adds all the entities in the same refund request.

If the Approval Required option is selected in the respective refund request type, the status of the refund request is set to Approval In Progress. However, if the Approval Required option is not selected in the respective refund request type, the system checks the number of entities added in the refund request. If the number of entities added in the refund request does not exceed the online record process limit, the system creates the refund adjustments using the refund adjustment type and then changes the status of the refund request to Processed. However, if the number of entities added in the refund request exceeds the online record process limit, the status of the refund request is set to Deferred Processing.

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