Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 89 Next »

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 2014Luca Casarini1.2New diagram, improved explanation.Nox  

Introduction

CDRator's billing functionality is aimed at generating Invoice Detail Lines out of CDR information received from the network.

Three major steps build up CDRator billing functionality.

StepNameDescription
1LOADINGCDR information is loaded into the database as billing records. The loading process applies CDRator’s customer's validation logic to the CDR files to e.g. discard duplicate information or files which don't correspond to the expected format.
2MEDIATION

Billing records have the same structure of CDRs, but with two additional fields added by CDRator:

  • rating code
  • rating key

Mediation is the process that determines these two fields from the information available in the billing record. Rating code and rating key are human-readable values that have a great impact in the subsequent phases of the billing process.

3.1RATING (standard prices)

The telecommunications market offers nearly always monthly packages which grant a limited amount of traffic (talk time, messages and data) for a fixed monthly fee. Nonetheless, every single minute of talk time, every message and every kbyte of GPRS has a basic price.


The CDRator Solution must be able to allow for the configuration of these basic prices because these will be valid after the amount granted in the monthly package is used completely. The CDRator Price Configuration is where these prices are configured and maintained. The CDRator Campaign and Bundle Framework models the monthly packages and any other exception to the prices determined by the CDRator Price configuration.

The first stage of the rating phase is always to determine the price of the billing record as per basic prices.

3.2RATING (campaigns)After the billing record is priced according to the basic prices, the process searches for exceptions. If a valid campaign/bundle is found, the process continues and it is up to the campaign/bundle's own logic to determine 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 page describes the activities that make up step 3.1 in the table above.

 

Knowledge of CDRator 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 use information on the billing record against the product configuration. 

 

Field(s)Description
Subscriber's informationAllow to identify the subscriber responsible for the usage. The fields depend on the network's specification, but normally one can expect ICC, IMSI or the A-Number to be there.
Event DateDate and time when the event began.
B-NumberThe number receiving the phone call, message. This applies only to certain types of usage.
DurationThe duration of the phone call or the amount of data. This applies only to certain types of usage and some network may define two separate fields: one for phone calls and one for data sessions.
Event TypeNetwork's defined fields that specify exactly the type of usage; e.g. national call to a fixedline number, premium SMS, roaming call, etc.
Cost PriceThe price of the usage as determined by the network.
Rating code, rating keyDetermined by mediation

 

2: Rate Plan

This step is aimed at finding the subscriber and his/her rate plan. Subscriber's info available in the billing record is used in tables like:

  • service
  • simcard
  • a_number

Eventually the corresponding subscription record is found and from that the process goes into billing_group_member:

Field(s)Description
subscription_idMatched against subscription.id.
from_date, to_dateMatched against the event date on the billing record. The configuration that is valid when the event began is the only one considered.
rate_plan_idThis 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 subscribers vie 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 matched against 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 up 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.

Example

In the screenshot below, the tele rates configuration of rate plan Fixedline. The rating code NATIONAL CALL is linked to the number plan Mobile National without date restrictions.

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.

There is a long list of possible methods provided by the Rator Platform; besides, customers can also require 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 operators can see which method 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.

Example

In the screenshot below, the b-number method for the number plan Mobile National is getRatingKey. This means that the billing record's rating key in the will be used to find the plan element.

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

Not always the plan element found by the best match algorithm is the one that points to the charges. The plan elements tree can be used to group several elements under one parent, which points to the 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 used against the start and end dates configured in the rate day itself.

Example

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.

 

 In the screenshot below, the rate day assigned to then MOBILE plan element is N-SINGLE and has an open start and end date.

7: Day Charge

Day charges are used to specify the charge depending on the day of the week (Monday to Sunday). Most of the times, a rate day has one single day charged which includes all the days of the week. 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 rate day in which charges are separate between weekdays and weekends is displayed below.

If usage date is on a Monday, Tuesday, Wednesday, Thursday or Friday the Weekdays day charge is considered by rating; otherwise it's Weekends.

8: Time Charge

Time charges are used to specify the charge depending on the hour of the day (00:00 to 24:0). Most of the times, charges are valid for the entire day: 00:00 to 24:00. The time in 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 once the day charge is selected.

Example

Day charge Weekends divides the day in three periods, each with its specific charges.

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 inp

11: Successfully Rated Billing Record

If there are no missing or misconfigured items in each of the above mentioned steps, and they run successfully, then the rating process will result in the successful rating of the billing record. The output of a successfully rated billing record is an invoice detail line, linked to the original billing record.

Icon

Any missing information or misconfigured items on any step of the rating process will result in failure of the rating process, and the respective billing record will end up in the 'Error Queue'.

 

 

  • No labels