Mass Billable Charge Creation (Financial Services)

Oracle Revenue Management and Billing provides the ability to create multiple billable charges for the financial services business at once through the Upload Request feature. You can create adhoc pass-through and SQI based billable charges and regular pass-through and SQI based billable charges through an upload request. To create a pass-through billable charge, you need to specify at least one pass-through charge line details. Similarly, to create an SQI based billable charge, you need to specify at least one SQI based charge details. The adhoc billable charges are considered during adhoc billing whereas the regular billable charges are considered during regular billing cycle. You can also create non-recurring (i.e., one-time) and recurring billable charges through an upload request.

The C1-BillableChargeUploadRequest business object enables you to create an upload request for mass billable charge creation. You need to create an upload request type for the C1-BillableChargeUploadRequest business object. You can then upload a mass billable charge creation file in the CSV format using the respective upload request type. The mass billable charge creation file should contain records with the following information – Contract or account details, start date, end date, description on bill, recurring details, pass-through charge line details or SQI based charge details, pricing information, and characteristic details. For more information, see Mass Billable Charge Creation CSV Format (Financial Services).

On uploading a mass billable charge 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:

• Start date, end date, and description on bill are specified in the record.

• Price item is specified in the record.

• Either the account details or contract ID is specified in the record.

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

If the contract ID is not specified in the record, the system derives an active contract of the account which is effective for the given date range. It considers that contract which is created using the contract type where the payment priority is set to highest, and the Eligible for Billing option is selected. If there are multiple active effective contracts with the same priority, the system considers any one contract randomly. However, if no active contract exists for the account for the given date range with the required specifications, the status of the record is changed to Invalid.

If the contract ID and account ID are 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 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 billable charge’s start date is equal to or later than the contract start date and earlier than or equal to the contract end date.

• The billable charge’s start date is equal to or earlier than the billable charge’s end date.

• The billable charge’s end date is equal to or later than the billable charge’s start date.

• At least one pass-through charge line or SQ based charge details is specified in the record.

• The Description on Bill, Amount, and Currency are specified when the record contains pass-through charge line details.

• The SQI and SQI Value are specified when the record contains SQ based charge details.

• The distribution code is required when the Memo Only flag of the respective pass-through charge line is set to N.

• The distribution code is not specified when the Memo Only flag of the respective pass-through charge line is set to Y.

• The distribution code given in the record is valid.

• The currency code given in the record is valid.

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

• The SQI given in the record is valid.

• The same SQI is not repeated multiple times in the record.

• The contract ID given in the record is valid and is not in the Canceled status.

• If both the account ID and contract ID are given in the record, the contract belongs to the account.

• The charge type given in the record is valid.

• The price item given in the record is valid.

• The Price Item Usage flag of the price item is set to Pricing and Billing.

• The contract type considered for billing should match the contract type specified in the price item.

• If the Use Calendar Billing field in the contract type is not set to Allow Advanced Billing, then bill after date is not earlier than the contract start date.

• The recurring flag in the record is either set to BP or FR.

• If the recurring flag is set to BP, then the bill period given in the record is valid. However, if the recurring flag is set to FR, then the frequency given in the record is valid.

• If the Multi Price Parameter option type of the C1_​PPARM_​FLG feature configuration is set to TRUE, then only the price item is given in the record.

• The price item parameters are not specified when the price item is not given in the record.

• The same price item parameter is not repeated multiple times in the record.

• The characteristic type given in the record is valid and its characteristic entity is set to Billable Charge.

• 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 mandatory parameter of the price item is included in the record when the billable charge start and end dates fall within the price item parameter date range.

  Note: If the billable charge start and end dates do not fall within the price item parameter date range, the billable charge can be created without the mandatory price item parameter.

• The adhoc, predefined, and reference price item parameter values are valid.

• The source entity of the price item parameter is set to Transaction.

• Both the price item parameter and its value are given in the record.

• The price item parameter should be valid for the price item in the given date range.

• The adhoc bill value in the record is either set to Y or N.

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, the system creates a billable charge against the contract. The status of the billable charge is set to Billable.

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