...
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
...
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.
...
Info | ||
---|---|---|
| ||
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 rate 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
...
Info | ||
---|---|---|
| ||
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.
...
- 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. |
...