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,  /wiki/spaces/V4Manual/pages/9833452no 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 /wiki/spaces/V4Manual/pages/9833533 having a billing term which is classified as prepaid. This 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
    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 Rating(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 was is not yet executed yet
• Identification & Rating: The billing run was is executed up to this stepidentification and rating
• Completed: All billing run steps were executed 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 (see Platform FS), which /wiki/spaces/V4Manual/pages/9833128, 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 /wiki/spaces/V4Manual/pages/9833533 having billing term schemes classified as normal 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 /wiki/spaces/V4Manual/pages/9833399 included in prepaid billing run accounts receivable filter listSubscriptions
• Accounts receivable in an Active or Suspended state
  
• /wiki/spaces/V4Manual/pages/9833538included in prepaid billing run subscriptions filter list
  
• Accounts receivable in an Active or Suspended state
• 
  

• For each subscription the following billable entities are identified:
Usage Data Records:
• /wiki/spaces/V4Manual/pages/9833533 are identified:
• /wiki/spaces/V4Manual/pages/9833457: 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/wiki/spaces/V4Manual/pages/9833462: The process retrieves all subscription service life cycle state periods which were not already being fully raterated, 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 following 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)

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 /wiki/spaces/V4Manual/pages/9833592 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 /wiki/spaces/V4Manual/pages/9833339 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 (see Wallets FS). 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 (seeWallets FS)
• 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  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 can be found in Wallets FS.

 and related estimations visit Calculating Wallet Estimated Consumption - R5&R6 & Calculating Wallet Balance - R5&R6