...
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
CDRatorRator'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 CDRator Rator billing functionality.
| Step | Name | Description |
|---|---|---|
| 1 | LOADING | CDR information is loaded into the database and named as billing records. The loading process applies CDRator’s 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 CDRatorRator:
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. |
...
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.
| Warning |
|---|
Knowledge of CDRator Rator Product Configuration is a prerequisite of this document. |
...
These are the activities performed after a CDR is loaded into a billing record and mediated.
| Drawio | ||||
|---|---|---|---|---|
|
1: Billing Record Information
...
Eventually the corresponding subscription record is found and from that the process load loads the corresponding billing_group_member record:
...
The algorithm is explained below.
| Drawio | ||||
|---|---|---|---|---|
|
Dot (".") as Plan Element Name
...
- 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.
| Drawio | ||||
|---|---|---|---|---|
|
In that case the bundle's rating logic is involved:
...
- 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.
| Drawio | ||||
|---|---|---|---|---|
|
| Warning |
|---|
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. |
...