What does this section cover?

What is Prepaid Billing Run?

Prepaid billing run is a billing mechanism which is used in cases where customers pay in advance and after that start using the services that were subscribed to, by deducting the used amount from the paid amount, using the wallets module.

 It is usually performed on a daily basis and is responsible to:

• Identify the service usage
• Rate the used services
• Debit the related wallets based on that usage

In addition there are optional services to:

• Stop subscription services which are left with no wallet credit
• Start services which were stopped and are now having enough wallet credit
• Estimate the date that the wallet amount will be consumed by the subscription services, based on their existing usage and billing term schemes.

Unlike Normal Billing Run, no bills or financial transactions are generated by the prepaid billing run and it is only applicable on Subscriptions.

Prepaid Billing Run Execution System Processes

This process is used to bill billable entities having a billing term which is classified as prepaid. The execution of this process results to the following:

• Rating subscription services following a prepaid billing term scheme
• Debiting the related wallet for the amount that was rated
• And optionally
  • Starting services that were not effective if the wallet amount which is available to be used by those services is above the threshold specified in the prepaid billing run definitions
  • Stopping services that were effective if the wallet amount which is available to be used by those services is equal or below the threshold specified in the prepaid billing run definitions
  • Estimating the date that the wallet balance will be consumed, based on the billing terms and the usage of the subscription services.
    The date which is calculated is a near proximity estimation of the consumption date, meaning that it can slightly be different to the actual date, if it is more than 6 months ahead.

Prepaid billing run is performed following a series of steps:

• Identification (Mandatory)
• Rating (Mandatory)
• Start Services (Optional / Configurable)
• Stop Services (Optional / Configurable)
• Wallet Debiting (Optional / Configurable)
• Estimating Wallet Consumption Date (Optional / Configurable)

Prepaid billing runs can be performed up to a specific step and resume their execution starting from the step that they have reached. The progress of each prepaid billing run is determined by its life cycle state. The supported life cycle states are the following:

• Draft: The billing run is not yet executed
• Identification & Rating: The billing run is executed up to identification and rating
• Completed: All billing run steps are completed successfully
• Failed: The billing run was not executed and no bills were created
• Completed with errors: the billing run was 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 were specified considering also the maximum number of threads that can be used by batch processes, as specified in General Settings, which can never be exceeded.

Mandatory Processes

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 which are defined specifically for each type of unrated billable information. The process is considering the generic billing run attributes and applies the following logic:

• Identify billable entities having billing term schemes classified as normal  prepaid filtered by the following billing run parameters:
• Billing term schemes /wiki/spaces/V4Manual/pages/9833520included in prepaid billing run billing term schemes conditions
• Accounts receivable classifications/wiki/spaces/V4Manual/pages/9833391 included in prepaid billing run accounts receivable classification conditions
• Accounts receivable included in prepaid billing run accounts receivable filter list
• Accounts receivable 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 being 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"
• For subscription services: The process retrieves all subscription service life cycle state periods which were not already being 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 “Billing as of date”

Anchor
rating rating

Rating Process

This step is calculating and applying a rate on each service or physical good to be billed, for a specific period of time, by creating rated billing items. The process is considering all the unrated billable information and it either rates them or not based on the business rules specified on each billing run. 
The same logic as in normal billing run is applied, although there are some rules which are never applicable on prepaid subscriptions (as specified in billing term definitions).

Prepaid Billing Run Rating process also handles Flexible Product Bundle billing. Go to Rating of Flexible Bundle Products to check out how Flexible Bundle Products are being billed 

Optional Processes

Anchor
start service start service

Starting Subscription Services Process

This step is performed only if it is enabled through the prepaid billing run. 
The process is starting subscription services belonging to a prepaid subscription, that are not effective, if the wallet amount which is available to be used by those services is above the threshold specified in the prepaid billing run definitions.

A start service subscription action is created for each subscription, including the services that should be started, which is executed imminently.

Anchor
stop service stop service

Stopping Subscription Services Process

This step is performed only if it is enabled through the prepaid billing run. 
The process is stopping services belonging to a prepaid subscription, that are effective, if the wallet amount which is available to be used by those services is equal or below the threshold specified in the prepaid billing run definitions.

A stop service subscription action is created for each subscription, including the services that should be stopped, which is executed imminently.

Anchor
wallet debiting wallet debiting

Wallet Debiting Process

This step is performed only if it is enabled through the prepaid billing run and if the prepaid billing is included in the causes debiting wallet rules, specified in the active wallet definitions. The process is responsible for the generation of wallet debit transactions, based on the amount denoted by the rated service periods, which were generated in the rating step, or already existed but not processed. 
The process applies the following logic:

• Gets all related rated service periods, which are not billed, having billing effective date before or equal to the billing as of date and life cycle state equal to “Not billed”
• Sum the amount of all services related to each accounts receivable
• If the amount is above zero 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 causes 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 based on the following logic:

• If Wallets with 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

Anchor
estimations estimations

Estimating Wallet Consumption Date Step

This step is performed only if it is enabled through the prepaid billing run. The process is estimating the date that the wallet balance will be consumed, based on the billing terms and the usage of the subscription services. The date which is calculated is a near proximity estimation of the consumption date, meaning that it can slightly be different to the actual date, if it is more than 6 months ahead. The process is estimating and setting the following information on each related wallet and wallet product consumption:

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

More information on wallets and related estimations visit Understanding Wallets