Transaction Rating Before Billing

The system provides the flexibility to rate the transaction legs either prior to billing or during billing. Based on the business requirements, you can configure the system such that transactions mapped to some price items can be rated at a frequency which is different than the account's billing frequency. For example, daily, weekly, etc. This will help to reduce the performance issues which are caused when large volume of transactions are rated at the time of billing.

The system offers the following ways in which a transaction leg can be priced, rated and billed:

1. Rate the Transaction Leg During Billing - In this approach, you can use either of the following ways:

   1. Determine effective pricing for a transaction leg, create a billable charge for the transaction leg, and then determine the rate during billing.

   2. Determine effective pricing for a transaction leg, create a billable charge for aggregated transaction legs, and then determine the rate during billing.

2. Rate the Transaction Leg Prior to Billing - In this approach, you can use either of the following ways:

   1. Determine effective pricing and rate for a transaction leg, and accumulate pre-calculated charges in a pass through billable charge based on the distribution code, currency code, description on bill, aggregation parameter group ID (which is created based on the rate component characteristics). The pass through billable charge is then billed during billing.

   2. Determine effective pricing for a transaction leg, aggregate the transaction legs, determine rate for aggregated service quantities, and then accumulate pre-calculated charges in a pass through billable charge based on the distribution code, currency code, description on bill, aggregation parameter group ID (which is created based on the rate component characteristics). The pass through billable charge is then billed during billing.

   3. Determine effective pricing and rate for a transaction leg and create a pass through billable charge for the transaction leg which is billed during billing.

3. Ignore the Transaction Leg for Billing - In this approach, you can use either of the following ways:

   1. Determine effective pricing for a transaction leg, but the billable charge is not created for the transaction leg.

   2. Determine effective pricing and rate for a transaction leg, but the billable charge is not created for the transaction leg.

While defining a price item pricing, you need to specify the rating criteria which indicates how and when you want to the rate the transaction legs. The valid values are:

• Do Not Rate Transactions (DNRT)

• Aggregate transactions and then rate aggregated SQs (AGTR)

• Rate individual transactions and aggregate calc lines across transactions (RITA)

• Rate Transactions (RITX)

Along with the Rating Criteria field, the Ignore Transaction and Aggregate Transaction fields help the system to determine how and when the corresponding transaction leg must be rated. The following table indicates how to configure the system in order to use the above mentioned ways:

Let us understand the following transaction rating ways with the help of an example:

• 2a

• 2b

• 2c

The following table lists the account, price item, and price item parameters combination to which transaction T1 and T2 are mapped:

The following table lists the rate components available on the PA1, PA2, and PA3 price assignments:

Now, if you use RITA (2a) approach, the system will rate a transaction leg and accumulate pre-calculated charges in a pass through billable charge based on the distribution code, currency code, description on bill, aggregation parameter group ID, as shown in the following table:

In the above example, the BC1 and BC2 will have two pass through lines, whereas the BC3 will have one pass through line.

Now, if you use RITX (2c) approach, the system will rate a transaction leg and calculate charges for each transaction leg in a separate pass through billable charge, as shown in the following table:

In the above example, the BC1, BC2, and BC3 will have two pass through lines, whereas the BC4 will have one pass through line.

Now, if you use AGTR (2b) approach, the system will determine effective pricing for a transaction leg, aggregate the transaction legs, determine rate for aggregated service quantities, and then accumulate pre-calculated charges in a pass through billable charge based on the distribution code, currency code, description on bill, aggregation parameter group ID (which is created based on the rate component characteristics), as shown in the following table:

In the above example, the BC1 and BC2 will have two pass through lines, whereas the BC3 will have one pass through line.