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

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  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"
• Post-rated 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”
• AVAILABLE FROM CRM.COM R9.0.0 - Pre-rated Subscription services: The  process retrieves 
  • Subscription service's which have never been rated before
    or
  • The latest rated up to date is equal or before the Prepaid Billing Run's performed date

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).

• 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
• AVAILABLE FROM CRM.COM R9.0.0 - 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.

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 

Note: Changes on Price Plans or Additive discount made after a prepaid billing run pre-rates a prepaid service, will not affect the billing of these services. i.e. Once you have pre-rated a service any changes on pricing, done after the rating, will not affect the billing. No crediting will be executed. The changed prices will only be applicable in billing for upcoming periods that have not already been rated.

Optional Processes

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.

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.

Stopping a Pre-Rated Service - AVAILABLE FROM CRM.COM R9.0.0

In case that the service is a pre-rated type service, then it will be stopped if:

• the wallet's amount is not enough in order to keep the service as Effective during the period of time for which the service is already rated and billed for.
  In greater detail the system will perform the following checks:
  • The available wallet amount is equal or more than the amount which is needed in order to keep the service as effective for an upcoming period (for example for the next month)
    
  • The system considers any changes that might be applicable during that period, such as any scheduled changes, or any changes which will be applied by the action and will be credited (for example on upgrades, the existing product will be credited) 
• i.e.  The minimum required wallet amount in order to keep prepaid pre-rated services as Effective equals to the amount for which the service is pre-rated for

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

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

There are 3 options for consumption estimation every time the Billing Run is executed:

• Skip Estimations: No estimations are done
• Re-estimate All: Estimation for all wallets is executed
• Re-estimate Wallets with changes: The system will decide which wallets have changes and make estimations, only for those wallets. 
  The decision on whether a wallet has been changed is based on the following logic:
  
  For every wallet the system checks if between: the Latest Estimated Consumption As Of Date and the current date, one of the following changes have taken place:
  • A credit (payment) was made
  • A Life Cycle State change was made to one of the subscription services
     

More information on wallets and related estimations visit Understanding Wallets