Back to Prepaid Billing Main Page

Prepaid Billing Run

Execution System Processes

The 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. 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 to in the following:

• Rating subscription services following a prepaid billing term scheme
• Debiting the related wallet The rating of Subscription Services following a Prepaid Billing Term Scheme.
• The debiting of 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 Optionally,

• The estimation of the date that the

  wallet balance

  Wallet Balance will be consumed

  ,

  based on the

  billing terms

  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

  Subscription Services.

Prepaid billing run Billing Run is performed following a series of steps:

• Identification (Mandatory)
• Rating (Mandatory)
• Start Services (Optional / Configurable)
• Stop Services (Optional / Configurable)
• Wallet Debiting Identification 
• Rating
• 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 The supported LifeCycle States for Prepaid Billing Runs 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

• ': 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 Prepaid Billing Run is recurring, then at the end of the execution a new prepaid billing run Prepaid Billing Run is created and scheduled to be executed on the date that was specified.

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

Anchor
identification identification

Identification Process

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

• Identify billable entities having billing term schemes entities with Billing Term Schemes classified as  prepaid Prepaid, filtered by the following billing run 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 Term Schemes included in Prepaid Billing Run Billing Term Schemes Conditions
• Accounts Receivable classifications included in Prepaid Billing Run Accounts Receivable Classification Conditions
• Accounts Receivable included in Prepaid Billing Run Accounts Receivable filter list that are in an 'Active' or 'Suspended' state
• Subscriptions included in Prepaid Billing Run Subscriptions filter list

• For each subscription 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”As Of Date.”
• Billing Directive is equal to “To be billed” Be Billed” or "To be creditedBe Credited."
• Post-rated Subscription servicesrated Subscription Services: The process retrieves all subscription service life cycle state 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”As Of Date.”
• Billing directive Directive is equal to “To be billed” to “To Be Billed” or "To be creditedBe Credited."
• Subscription service Service period started before the “Billing as of date”

Status
colour Red title Available from CRM.COM R9.0.0

 - Pre
• the “Bill As Of Date.”
• Pre-rated Subscription servicesServices: The  process retrieves 
  • Subscription serviceService's which have never not been rated before 
    or
  • The latest rated up to date "Rated Up To Date" is equal to or before the Prepaid Billing Run's performed date.

Anchor
rating rating

Rating Process

This The Rating step is calculating calculates and applying applies a rate on each service Service or physical good Physical Good to be billed, for a specific period of time, by creating rated billing items. The process is considering Rated Billing Item/wiki/spaces/WIP/pages/10008754 The process considers 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).Billing Run. 

• If a service Service is post-rated, then create a Rated Billing Item from the last rated up to date "Rated Up To Date" until the Prepaid billing runBilling Run's performed date

• Status
  colour Red title Available from CRM.COM R9.0.0

   - If the service If the Service is pre-rated, then create a Rated Billing item Item from the last rated up to date "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 

• the Billing Term Scheme.

Anchor

wallet

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

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 - 

Status
colour Red title 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

debiting wallet debiting

Wallet Debiting Process

The process is responsible for the generation of wallet debit transactionsWallet 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 logicsteps:  

• Gets Gather all related rated service periods, Rated Service Periods which are not yet to be billed, having billing effective date have a billing Effective Date before or equal to the billing as of date and life cycle state equal to “Not billed”Billing As Of Date, and a Life Cycle State equal to 'Not Billed'
• Sum the amount of all services Services related to each accounts receivableAccounts Receivable
• If the resulting amount is above zero positive then
• Create a wallet debit transactionWallet Debit Transaction, based on wallet definitions Wallet Definitions to debit the walletWallet. Create one wallet debit transaction Wallet Debit Transaction for each service (i.e. for each rated billed period). The wallet transaction type Wallet Transaction Type specified in the active wallet definitionWallet Definition's causes debiting wallets as a cause for debiting Wallets is used to create the wallet debit transaction Wallet Debit Transaction (see Wallets).
• Set the life cycle state Life Cycle State of all rated service periods Service Periods to “Billed”.

The amount of the wallet debit transaction Wallet Debit Transaction is calculated based on the using following logic:

• If Wallets with balance a Balance less than the stop service Stop Service threshold , are restricted through the active billing term definitions for subscriptions Billing Term Definitions for Subscriptions then

  • The amount will be equal to the remaining wallet Wallet available amount
• Else
  • The amount will be equal to the sum of the rated amount of all rated subscription servicesrated 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 runPrepaid Billing Run. The process is estimating estimates the date that the wallet balance on which the Wallet Balance will be consumed, based on the billing terms 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 Subscription Services.

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

• Wallets
  • Estimated Consumption Days: An estimation on of the number of days left until the whole wallet amount will be entire Wallet amount is 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
  • entire Wallet amount is consumed
• 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 of the number of days left until the whole wallet entire Wallet amount allotted for the specified product will be is consumed
  • Estimated Consumption Date: An estimation of the date on which the whole wallet entire Wallet amount allotted for the specified product will be is consumed
  • Estimated Consumption As of Date: The latest date that the estimation was performed.

There are 3 three options for consumption estimation every time the Billing Run is executedestimating consumption when executing Billing Runs:

• Skip Estimations: No estimations are donetakes place
• Re-estimate All: Estimation for all wallets is executedWallets takes place
• Re-estimate Wallets with changes: The system will decide which wallets have changes and make System decides which Wallets were modified and makes estimations, only for those walletsWallets. 
  The decision on whether a wallet Wallet has been changed modified 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
     

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

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