...

...

Introduction

CDRatorRator's billing functionality is aimed at generating Invoice Detail Lines out of CDR 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.

...

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 document describes the activities that make up step in steps 3.1 and 3.2 in the table above, and can be used to trouble shoot rating errors.

...

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 compare fields of the billing record against with elements of the product configuration. 

...

2:

...

Rate Plan

This step is aimed at finding looks for the subscriber and his/her rate plan. SubscriberThe 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 loads the corresponding billing_group_member record:

Once the rate plan is known, its tele rates configuration is matched against 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.

...

Example

...

...

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 A long list of possible methods is provided by the Rator Platform; besides, customers can also require request the development of custom methods.

The most common B-Number Methods methods are getRatingKey and getBNumber: they . They will use return the billing record's rating key and B-Number respectively.

Best Match

TODO

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.

Image Removed

...

, respectively.

5: Find the Plan Element

The rating process finds the plan element via 'Best Match' using the b-number method information. Once the plan element has been found, the rating process looks at the rate day information associated with that plan element. In order to look at the plan element, use the b-number method to select a plan element from the 'Plan Elements' panel.

For example, if the b-number is getRatingKey, then compare the value of the rating key with the available plan elements. In the screenshot below, 'MOBILE..Mobile national' is the plan element selected when looking at the rating key in the billing record (for example the rating key = MOBILE).

Image Removed

Dot and double dot

When handling plan elements, there are a few important things to consider. In particular, sometimes the dot "." must to be used in order to have a proper plan element tree configuration. The lack of usage of this character will make the rating fail. 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.

 Image Removed

In the example above,the price is defined in the element below the charges are defined by the element Group 1. The elements below children of Group 1 do  do not point to a charge item; the parent defines the price. Remember that if double dot ''..'' is not put in the beginning of the children, then they will not call the parent ''.'' for accessing the charge item, hence the rating would fail. Since the parent Group 1 is defining the charge item so it is being edited to use ''.'' in the beginning and not the double dot ''..''.

Step 6 - Check the Rate Days

Now the rating process looks at the configured rate days. The rating process will compare the event/charge date present within the billing record the charges.

Image Added

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 listed configured in the 'Rate Day' configuration.

In order to look at the 'Rate Day' configuration, select the relevant plan element and then have a look at the 'Rate Day' panel. Please note that the charge/event date should be equal to or should lie between the configured dates. In the screenshot it can be seen that the rate day is 'N-SINGLE' and has an open start and end date.

Image Removed

Step 7 - Check the Day Charges

After the rating process has found the rate day, it looks at the day charges. It again compares the charge/event data present in the billing record with the configured day charges.

In order to look at the 'Day Charge' configuration, select the relevant 'Rate Day' and then click Edit. On the 'Edit Rate Day' pop-up, there will be a 'Day Charge' panel. Please note that the day the charge/event took place should be within the configured days. In the screenshot it can be seen that all the days of the week are selected for the rate day 'N-SINGLE'.

Image Removed

Step 8 - Check the Time Charges

After looking at the day charge, the rating process looks at the time the event occured. The rating process would look at the start and the end time configured for the day the event occurred.

In order to look at the 'Time Charge' configuration, select the relevant 'Day Charge', to see the 'Time Charge' configured for the selected day. Please note that the time the event took place should be within an already configured time charge. In the screenshot below the time configured is 00:00 til 24:00.

Image Removed

Step 9 - Find the Charge Items

The rating process will now look at the charges defined for the time the event took place. It would pick up the relevant charge and use it for rating the event.

In order to look at the configured charge items, double click or Edit the 'Time Charge'. In the 'Edit Time Charge' pop-up, the configured charge items are present. Please note that the charge item for the time selected should be present, otherwise there can be no rating and the rating would fail. In the screenshot below, both the 'Initial' and 'Recurrent' charge items have been configured.  

Image Removed

...

rate day itself.

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.

Example

A day charge in which charges are separate between weekdays and weekends is displayed below.

Image Added

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.

9: Charges

Each time charge can define the initial charge, the recurrent charge or both of them.

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 mentioned steps, and they run successfully, then the steps 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.

...

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.

Rating (campaign)

How Does the Rating Detect the Demand for a Campaign?

In order for rating to involve a campaign:

1. The subscriber must be assigned to an active campaign.
2. 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:

1. The invoice detail line generated according to the price configuration is input to the bundle rating.
2. The output of the bundle rating depends on the bundle itself, but generally can be:
   1. An updated version of the original invoice detail line (e.g. zero-rated or 50% discounted).
   2. 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).
   3. The same original invoice detail line plus another one which gives the subscriber a credit of the same amount.
   4. 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. 

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:

1. After loading and mediation the billing record goes through the rating according to the standard prices.
2. 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.
3. The bundle will assign temporary rating code and rating key values to the billing record.
4. 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.