Rating and Billing Process Flow
- Former user (Deleted)
- Mohamad Zind
- Søren Duusgaard (Deactivated)
- Former user (Deleted)
Document Logs
Change log:
Date: | Author: | Version: | Changes: | Completed | Ext. | Int. | Is in Core |
|---|---|---|---|---|---|---|---|
27 October 2011 | Rida Riaz | 1.0 |
| No | x |
|
|
31 October 2011 | Luca Casarini | 1.1 | Review | No | x |
|
|
31 October 2011 | SD | 1.1 | Checked | Yes | x |
|
|
| 9 May 2014 | Luca Casarini | 2.0 | Reorganized the document, added bundle rating and introduction. | No | x |
Introduction
Rator's billing functionality is designed to generate invoice detail lines based on Call Detailed Record (CDR) information received from the network.
Three major steps build up Rator billing functionality.
| Step | Name | Description |
|---|---|---|
| 1 | LOADING | CDR information is loaded into the database and named as billing records. The loading process applies Rator customer validation logic to the CDR files to e.g. discard duplicate information or files which do not comply with the expected format. |
| 2 | MEDIATION | Billing records have the same structure of CDRs, but two additional fields are added by Rator:
Mediation is the logic that determines these two fields from information available in the billing record. Rating code and rating key are human-readable values that have a great impact on the subsequent phases of the billing process. |
| 3.1 | RATING (standard prices) | The telecommunications market often offers monthly packages which grant a limited amount of traffic (talk time, messages and data) at a fixed monthly fee. Nonetheless, every single minute of talk time, every message and every kbyte of GPRS has a basic or standard price.
The first stage of the rating phase always determines the price of the billing record in terms of basic prices. |
| 3.2 | RATING (campaigns) | After the billing record is rated according to the basic prices, the process searches for exceptions. If a valid campaign/bundle is found, the process continues, and now the campaign/bundle's own logic determines the actual price of the billing record. |
If errors occur during the process above, the billing record is moved into an error queue for manual investigation and handling. Therefore, knowledge of the rating and billing process is key for the investigation and resolution of rating errors.
This document describes the activities in steps 3.1 and 3.2 in the table above, and can be used to trouble shoot rating errors.
Knowledge of Rator Product Configuration is a prerequisite of this document.
Rating (Standard Prices)
These are the activities performed after a CDR is loaded into a billing record and mediated.
1: Billing Record Information
Several steps of the process will compare fields of the billing record with elements of the product configuration.
| Field(s) | Description |
|---|---|
| Subscriber's information | Allows identification of the subscriber responsible for the usage. The fields depend on the network specification, but normally one can expect the presence of ICC, IMSI or the A-Number. |
| Event Date | Date and time when the event began. |
| B-Number | Number receiving the phone call, message. This applies only to certain types of usage. |
| Duration | Duration of the phone call or amount of data. This applies only to certain types of usage and some networks may define two separate fields: one for phone calls and one for data sessions. |
| Event Type | Network's defined fields that specify exactly the type of usage, e.g. national call to a fixedline number, premium SMS, roaming call, etc. |
| Cost Price | Price of the usage as determined by the network. |
| Rating code, rating key | Determined by mediation. |
2: Rate Plan
This step looks for the subscriber and his/her rate plan. The subscriber's info in the billing record is used in tables like:
servicesimcarda_number
Eventually the corresponding subscription record is found and from that the process loads the corresponding billing_group_member record:
| Field(s) | Description |
|---|---|
subscription_id | Compared to subscription.id. |
from_date, to_date | Compared to the event date on the billing record. The configuration that is valid when the event began is the only one considered. |
rate_plan_id | This points to the rate plan that will be used by the following steps. |
Customer Care
For investigation purposes, operators can use IMSI/ICC information of the billing record to find the subscriber via the advanced search. The rate plan is displayed in the subscription details.
3: Number Plan
Once the rate plan is known, its tele rates configuration is compared with the billing record's rating code. The rate plan's tele rates configuration is where every possible rating code is assigned to a number plan. This assignment is valid on a specified range of dates; again the billing record's event date is used to find the number plan attached to a rating code.
Product Configuration
The tele rates configuration of a rate plan can be analyzed by selecting the rate plan in the Product Configuration GUI and clicking the Edit button.
This will open the Edit Rate Plan popup. Select the rating code on the table on the left (Tele Rates frame, Service Code column). The associated number plan is displayed on the right (Number Plans frame). The columns From Date and To Date specify whether the link between a rating code and a number plan has restrictions on time.
4: Execute the B-Number Method
The number plan's B-Number method is executed. This method uses some fields of the billing record to construct a string that is then used to find a plan element via Best Match.
A long list of possible methods is provided by the Rator Platform; besides, customers can also request the development of custom methods.
Product Configuration
For investigation purposes it is important to know the logic of the B-Number method. Click on the number plan on the Product Configuration GUI and then the Edit button. This will open the Edit Number Plan pop-up GUI where the operator can check the method that is configured for the number plan and read its description.
The most common B-Number methods are getRatingKey and getBNumber. They will return the billing record's rating key and B-Number, respectively.
5: Find the Plan Element
The rating process finds the plan element via Best Match using the outcome of the B-Number method.
Best Match Algorithm
The algorithm is explained below.
Dot (".") as Plan Element Name
The plan element found by the best match algorithm is not always the one that points to the charges. The plan elements tree can be used to group several elements under one parent, which points to charges that are valid for all its children.
If a plan element is named by using a dot ''.'' then that plan element is defined as the holder of the charges on behalf of its sub-elements.
In the example below the charges are defined by the element Group 1. The children of Group 1 do not point to the charges.
6: Rate Day
The process loads the relevant rate day attached to the plan element. The billing record's event date is compared with the start and end dates configured in the rate day itself.
Product Configuration
In the Product Configuration GUI, click on a plan element and the GUI will automatically display the corresponding rate days in the Rate Day frame below the plan elements tree.
7: Day Charge
Day charges are used to specify the charge depending on the day of the week (Monday to Sunday). In most cases, a rate day has one single day charge which includes all the days of the week. The billing record's event date is used again to find the relevant day charge.
Product Configuration
Day charges are displayed in the Edit Rate Day pop-up GUI. Select a rate day and click the Edit button on the Rate Day frame.
Example
A day charge in which charges are separate between weekdays and weekends is displayed below.
If the usage date is on a Monday, Tuesday, Wednesday, Thursday or Friday, the Weekdays-day charge is considered by rating, otherwise the Weekends-day charge is used.
8: Time Charge
Time charges are used to specify the charge depending on the hour of the day (00:00 to 24:00). In most cases, charges are valid for the entire day, 00:00 to 24:00. The time in the billing record's event date is used to find the relevant time charge.
Product Configuration
Time charges are displayed in the Edit Rate Day pop-up GUI, Time Charge frame once the day charge is selected.
9: Charges
Each time charge can define the initial charge, the recurrent charge or both of them.
Initial and recurrent charges are displayed in the Time Charge frame of the Edit Rate Day pop-up GUI. Alternatively, select one time charge and then click the Edit button on the right. This will open the Edit Time Charge pop-up GUI which configures the charge items that define the charges.
10: Execute the Rating Method
Once the charges are known, they are given as input to the number plan's rating method. The rating method may also use information from the billing record, such as duration or cost price.
11: Successfully Rated Billing Record
If there are no missing or misconfigured items in each of the above steps the rating process will result in the creation of an invoice detail line based on the standard prices. The process will eventually continue with involving campaigns and bundles according to the price configuration.
At this point of the process the invoice detail line is not yet persistent in the database.
Rating (campaign)
How Does the Rating Detect the Demand for a Campaign?
In order for rating to involve a campaign:
- The subscriber must be assigned to an active campaign.
- The campaign must have one bundle mapped to the very same plan element (or one of its ancestors) used during the standard prices rating.
In that case the bundle's rating logic is involved:
- The invoice detail line generated according to the price configuration is input to the bundle rating.
- The output of the bundle rating depends on the bundle itself, but generally can be:
- An updated version of the original invoice detail line (e.g. zero-rated or 50% discounted).
- An updated version of the original invoice detail line with a new public representation (e.g. the discounted phone calls are listed under a new invoice level which contains only the discounted lines).
- The same original invoice detail line plus another one which gives the subscriber a credit of the same amount.
- The original price if e.g. the customer has finished the bonus.
Bundle Rating: Restrict Active Framework
The prominent feature of the Restrict Active framework is on-the-fly mediation. Bundles can change the rating code and rating key of a billing record and then the billing record is rated against another number plan/plan element which implements the new price according to the business rules.
This change is not persistent in the database. The billing record will always have the rating code and rating key determined by mediation.
It is possible to define two different sets of values for rating code and rating key: one to be used for the part of the usage inside the bundle, and one for the part outside the bundle. Bundles that implement this framework are capable of splitting usage of billing records that overflow the bundle.
Excluding corner cases such as overflow and splitting, this is what happens:
- After loading and mediation the billing record goes through the rating according to the standard prices.
- If a valid campaign is detected, then the bundle's logic is involved. Otherwise the invoice detail line is saved on the database and process is finished.
- The bundle will assign temporary rating code and rating key values to the billing record.
- The billing record goes through the very same standard rating process it has just left. This time, different rating code and rating key values will make it hit (possibly) a different rate plan, number plan and plan element. This will lead to the creation of a new invoice detail line.
Since the billing record essentially passes through the standard rating process at least twice, it is even more important to understand how the standard product configuration and the Restrict Active framework work. Remember that the new set of rating code and rating key are not persistent; therefore it is up to the operator to find out which campaign/bundle was involved and what happened during the on-the-fly mediation.