Back to Prepaid Billing Main Page

Prepaid Billing Run Execution System Processes

The Prepaid Billing process is used to bill Subscriptions whose Billing Term is classified as Prepaid. There are 2 models of Prepaid Services:

• Pre-rated Services: The System will bill a Service for an upcoming defined period (enough funds need to be available in the Wallet before the Service is activated).
• Post-rated Services: The System will bill a Service for a passed period.

The execution of this process results in the following:

• The rating of Subscription Services following a Prepaid Billing Term Scheme.
• The debiting of the related Wallet for the amount that was rated.
• Optionally,

  • The estimation of the date that the Wallet Balance will be consumed based on the Billing Terms and the usage of the Subscription Services.

Prepaid Billing Run is performed following a series of steps:

• Identification 
• Rating
• Wallet Debiting  (Optional / Configurable)
• Estimating Wallet Consumption Date (Optional / Configurable)

The supported LifeCycle States for Prepaid Billing Runs are the following:

• 'Draft': Not executed yet
• 'Identification and Rating': Executed up to this step
• 'Completed': Executed successfully
• 'Failed': Executed and no Bills were created
• 'Completed with Errors': Executed with minor errors and Bills were created

Prepaid Billing Runs can be performed once or on a recurring basis. If a Prepaid Billing Run is recurring, then at the end of the execution a new Prepaid Billing Run is created and scheduled to be executed on the date that was specified.

Prepaid Billing Runs are multi-threaded and are performed using the number of threads which are specified, with consideration to the maximum number of threads that can be used by batch processes, as specified in General Settings.

Anchor
identification identification

Identification Process

This step identifies all the unrated billable (chargeable or creditable) information which is ready to be billed and should be considered during the specific Billing Run. The process follows business rules defined for each type of unrated billable information. The process considers the generic Billing Run attributes and applies the following logic:

• Identify billable entities with Billing Term Schemes classified as Prepaid, filtered by the following Billing Run parameters:
• Billing Term Schemes included in Prepaid Billing Run Billing Term Schemes Conditions
• Accounts Receivable Classifications included classifications included in Prepaid Billing Run Accounts Receivable Classification Conditions
• Accounts Receivable included Receivable included in Prepaid Billing Run Accounts Receivable filter list Accounts Receivable in that are in an 'Active' or 'Suspended' state
• Subscriptions included in Prepaid Billing Run Subscriptions filter list

• For each Subscription the following billable entities are identified:
• Usage Data Records: The process retrieves all usage detail records which were not already fully rated, based on the following rules:
• Billing effective date is before or equal to “Bill As Of Date.”
• Billing Directive is equal to “To Be Billed” or "To Be Credited."
• Post-rated Subscription Services: The process retrieves all Subscription Service Life Cycle State periods which were not already fully rated, based on the following rules:
• Subscription Service “Billing Effective Date” is before or equal to “Bill As Of Date.”
• Billing Directive is equal to “To Be Billed” or "To Be Credited."
• Subscription Service period started before the “Bill As Of Date.”
• Pre-rated Subscription Services: The  process retrieves 
  • Subscription Service's which have not been rated before 
    or
  • The latest "Rated Up To Date" is equal to or before the Prepaid Billing Run's performed date.

Anchor
rating rating

Rating Process

The Rating step calculates and applies a rate on each Service or Physical Good to be billed, for a specific period, by creating Rated Billing Item/wiki/spaces/WIP/pages/10008754 The process considers all the unrated billable information and either rates them or not, based on the business rules specified on each Billing Run. 

• If a Service is post-rated, then create a Rated Billing Item from the last "Rated Up To Date" until the Prepaid Billing Run's performed date
• If the Service is pre-rated, then create a Rated Billing Item from the last "Rated Up To Date" plus the period for which the service will be billed in advance as this is defined in the Billing Term Scheme.

Anchor
wallet debiting wallet debiting

Wallet Debiting Process

The process is responsible for the generation of Wallet Debit Transactions, based on the amount denoted by the rated service periods generated in the rating step, or already existed but not processed. 

The process applies the following steps:  

• Gather all related Rated Service Periods which are yet to be billed, have a billing Effective Date before or equal to the Billing As Of Date, and a Life Cycle State equal to 'Not Billed'
• Sum the amount of all Services related to each Accounts Receivable
• If the resulting amount is positive then
• Create a Wallet Debit Transaction, based on Wallet Definitions to debit the Wallet. Create one Wallet Debit Transaction for each service (i.e. for each rated billed period). The Wallet Transaction Type specified in the active Wallet Definition's as a cause for debiting Wallets is used to create the Wallet Debit Transaction (see Wallets).
• Set the Life Cycle State of all rated Service Periods to “Billed”.

The amount of the Wallet Debit Transaction is calculated using following logic:

• If Wallets with a Balance less than the Stop Service threshold are restricted through the active Billing Term Definitions for Subscriptions then

  • The amount will be equal to the remaining Wallet available amount
• Else
  • The amount will be equal to the sum of the rated amount of all rated Subscription Services.

• If the Wallet Balance that is available for the rated Service minus the amount that the service was rated for, is less than the "Minimum Wallet Balance Threshold"  (as specified in the active Wallet Definition) then
  • The Subscription Service Prepayment State is set to invalid
  • The Subscription Service Last Date of Prepayment State Calculation is set equal to the date and time of execution
  • The Subscription Service is not rated as there was not enough amount in the wallet (for both post-rate and pre-rate)
• Else
  • The Wallet is debited, and the rest of the existing functionality is applied (i.e. rated billing items are created etc.)
  • The Subscription Service Prepayment State is set to Valid
  • The Subscription Service Last Date of Prepayment State Calculation is set equal to the date and time of execution.

Anchor
estimations estimations

Estimating Wallet Consumption Date Step

This step is performed only if it is enabled through the Prepaid Billing Run. The process estimates the date on which the Wallet Balance will be consumed, based on the Billing Terms and the usage of the Subscription Services.

The process estimates and sets the following information on each related Wallet and Wallet Product Consumption:

• Wallets
  • Estimated Consumption Days: An estimation of the number of days left until the entire Wallet amount is consumed
  • Estimated Consumption Date: An estimation of the date on which the entire Wallet amount is consumed
• Wallet Product Consumption
  • Available Amount: The amount of money which is available for the product as of the specified date
  • Estimated Consumption Days: An estimation of the number of days left until the entire Wallet amount allotted for the specified product is consumed
  • Estimated Consumption Date: An estimation of the date on which the entire Wallet amount allotted for the specified product is consumed
  • Estimated Consumption As of Date: The latest date that the estimation was performed.

There are three options for estimating consumption when executing Billing Runs:

• Skip Estimations: No estimations takes place
• Re-estimate All: Estimation for all Wallets takes place
• Re-estimate Wallets with changes: The System decides which Wallets were modified and makes estimations, only for those Wallets. 
  The decision on whether a Wallet has been modified is based on the following logic:
  
  • A consumption date is estimated only if the date falls within the maximum estimation period as specified on the active Prepaid Billing Run Definition.
  • The date threshold will be calculated relative to the daily price that is calculated during billing.
   

For more information on Wallets and related estimations refer to Understanding Wallets.