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:
-
Rate the Transaction Leg During Billing – In this approach, you can use either of the following ways:
-
Determine effective pricing for a transaction leg, create a billable charge for the transaction leg, and then determine the rate during billing.
-
Determine effective pricing for a transaction leg, create a billable charge for aggregated transaction legs, and then determine the rate during billing.
-
-
Rate the Transaction Leg Prior to Billing – In this approach, you can use either of the following ways:
-
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.
-
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.
-
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.
-
-
Ignore the Transaction Leg for Billing – In this approach, you can use either of the following ways:
-
Determine effective pricing for a transaction leg, but the billable charge is not created for the transaction leg.
-
Determine effective pricing and rate for a transaction leg, but the billable charge is not created for the transaction leg.
-
Once the rate is determined for transaction legs, a set of rate component characteristics and their values are grouped. For example, if a price assignment has the following rate components, the system creates two groups — Group A and Group B:
-
RC1, Char1=Y, Char2=Y
-
RC2, Char1=N, Char2=Y
-
RC3, Char1=Y, Char2=Y
Group A contains Char1=Y, Char2=Y and Group B contains Char1=N, Char2=Y. These groups are used for accumulating pre-calculated charges. A unique aggregation parameter group ID is generated for each group. If a group with a set of rate component characteristics and their values already exists in the system, a new group is not created. Instead, the existing group is used for accumulating pre-calculated charges. The aggregation parameter group ID is created when you attach an algorithm of the C1_RTCL_POPC algorithm type on the TFM - Rate Post-Processing algorithm entity in the Algorithms tab of the Division screen. Note that the system invokes the algorithm which is attached on the derived account’s division and not on the division to which the transaction belongs.
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:
Transaction Rating Approach and Way | Ignore Transaction (Yes or No) | Aggregate Transaction (Yes or No) | Rating Criteria | Batch in which the Rate is Determined |
---|---|---|---|---|
3a | Yes | Not applicable | Do Not Rate Transactions (DNRT) | Not applicable because ignored transactions are not considered for billing. |
3b | Yes | Not applicable | Rate Transactions (RITX) | Update Status (C1-TXNEX) |
1b | No | Yes | Do Not Rate Transactions (DNRT) | Not applicable because the rate is determined during billing. |
2b | No | Yes | Aggregate transactions and then rate aggregated SQs (AGTR) | Service Quantity Calculation (C1-TXNSQ) |
2a | No | Yes | Rate individual transactions and aggregate calc lines across transactions (RITA) | Update Status (C1-TXNEX) |
1a | No | No | Do Not Rate Transactions (DNRT) | Not applicable because the rate is determined during billing. |
2c | No | No | Rate Transactions (RITX) | Service Quantity Calculation (C1-TXNSQ) |
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:
Transaction | Transaction Volume | Transaction Date | Account | Price Item | Price Item Parameter Group ID | Price Assignment ID | Aggregation Schedule |
---|---|---|---|---|---|---|---|
T1 | 300 | 01/01/2015 | A1 | P1 | PG1 | PA1 | Monthly |
T1 | 300 | 01/01/2015 | A2 | P1 | PG1 | PA2 | Monthly |
T2 | 200 | 15/01/2015 | A1 | P1 | PG1 | PA1 | Monthly |
T2 | 200 | 15/01/2015 | A3 | P1 | PG1 | PA3 | Monthly |
The following table lists the rate components available on the PA1, PA2, and PA3 price assignments:
Transaction | Price Assignment ID | Rate Component | Currency Code | Distribution Code | Description on Bill | Aggregation Parameter Group ID (Rate Component’s Characteristics) |
---|---|---|---|---|---|---|
T1 | PA1 | RC1- 0.1*Transaction Volume | USD | BK-AR1 | XYZ | Char1=Y |
T1 | PA1 | RC2- 0.2*Transaction Volume | USD | BK-AR2 | ABC | Char2=Y |
T1 | PA2 | RC3- 0.3*Transaction Volume | USD | BK-AR3 | XYZ | Char1=Y |
T1 | PA2 | RC4- 0.2*Transaction Volume | USD | BK-AR4 | ABC | Char2=Y |
T2 | PA1 | RC1- 0.1*Transaction Volume | USD | BK-AR1 | XYZ | Char1=Y |
T2 | PA1 | RC2- 0.2*Transaction Volume | USD | BK-AR2 | ABC | Char2=Y |
T2 | PA3 | RC3- 0.3*Transaction Volume | USD | BK-AR3 | XYZ | Char1=Y |
T2 | PA3 | RC4- 0.2*Transaction Volume | USD | BK-AR3 | XYZ | Char1=Y |
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:
Billable Charge | Start Date | End Date | Transaction Leg | Rate Component | Calculation Details | Pass Through Charge ($) | Comments |
---|---|---|---|---|---|---|---|
BC1 | 01/01/2015 | 31/01/2015 | T1–A1P1PG1–PA1, T2–A1P1PG1–PA1 | RC1 | 300*0.1 = 30, 200*0.1 = 20 | 30+20 = 50 | The pass through charge is calculated for each transaction leg and then accumulated because the distribution code, currency code, description on bill, and characteristics of the rate components are same. |
BC1 | 01/01/2015 | 31/01/2015 | T1–A1P1PG1–PA1, T2–A1P1PG1–PA1 | RC2 | 300*0.2 = 60, 200*0.2 = 40 | 60+40 = 100 | The pass through charge is calculated for each transaction leg and then accumulated because the distribution code, currency code, description on bill, and characteristics of the rate components are same. |
BC2 | 01/01/2015 | 31/01/2015 | T1–A2P1PG1–PA2 | RC3 | 300*0.3 = 90 | 90 | The pass through charge is calculated for the transaction leg. |
BC2 | 01/01/2015 | 31/01/2015 | T1–A2P1PG1–PA2 | RC4 | 300*0.2 = 60 | 60 | The pass through charge is calculated for the transaction leg. |
BC3 | 01/01/2015 | 31/01/2015 | T2–A3P1PG1–PA3 | RC3, RC4 | 200*0.3 = 60, 200*0.2 = 40 | 60+40 = 100 | The pass through charges are calculated for the transaction leg and then accumulated because the distribution code, currency code, description on bill, and characteristics of the rate components are same. |
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:
Billable Charge | Start Date | End Date | Transaction Leg | Rate Component | Calculation Details | Pass Through Charge ($) | Comments |
---|---|---|---|---|---|---|---|
BC1 | 01/01/2015 | 31/01/2015 | T1–A1P1PG1–PA1 | RC1 | 300*0.1 = 30 | 30 | The pass through charge is calculated for the transaction leg. |
BC1 | 01/01/2015 | 31/01/2015 | T1–A1P1PG1–PA1 | RC2 | 300*0.2 = 60 | 60 | The pass through charge is calculated for the transaction leg. |
BC2 | 01/01/2015 | 31/01/2015 | T1–A2P1PG1–PA2 | RC3 | 300*0.3 = 90 | 90 | The pass through charge is calculated for the transaction leg. |
BC2 | 01/01/2015 | 31/01/2015 | T1–A2P1PG1–PA2 | RC4 | 300*0.2 = 60 | 60 | The pass through charge is calculated for the transaction leg. |
BC3 | 01/01/2015 | 31/01/2015 | T2–A1P1PG1–PA1 | RC1 | 200*0.1 = 20 | 20 | The pass through charge is calculated for the transaction leg. |
BC3 | 01/01/2015 | 31/01/2015 | T2–A1P1PG1–PA1 | RC2 | 200*0.2 = 40 | 40 | The pass through charge is calculated for the transaction leg. |
BC4 | 01/01/2015 | 31/01/2015 | T2–A3P1PG1–PA3 | RC3, RC4 | 200*0.3 = 60, 200*0.2 = 40 | 60+40 = 100 | The pass through charges are calculated for the transaction leg and then accumulated because the distribution code, currency code, description on bill, and characteristics of the rate components are same. |
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:
Account-Price Item-Price Item Parameter Group-Price Assignment-Aggregation Schedule | Total Transaction Volume | Billable Charge | Start Date | End Date | Rate Component | Calculation Details | Pass Through Charge ($) | Comments |
---|---|---|---|---|---|---|---|---|
A1P1PG1–PA1–Monthly | 300+200 = 500 | BC1 | 01/01/2015 | 31/01/2015 | RC1 | 500*0.1 = 50 | 50 | The transaction volume of T1 and T2 legs having the same price item and price item parameters combination and whose transaction date falls between the aggregation schedule is first aggregated and then pass through charge is calculated for aggregated service quantities. |
A1P1PG1–PA1–Monthly | 300+200 = 500 | BC1 | 01/01/2015 | 31/01/2015 | RC2 | 500*0.2 = 100 | 100 | The transaction volume of T1 and T2 legs having the same price item and price item parameters combination and whose transaction date falls between the aggregation schedule is first aggregated and then pass through charge is calculated for aggregated service quantities. |
A2P1PG1–PA2–Monthly | 300 | BC2 | 01/01/2015 | 31/01/2015 | RC3 | 300*0.3 = 90 | 90 | The pass through charge is calculated for the transaction leg. |
A2P1PG1–PA2–Monthly | 300 | BC2 | 01/01/2015 | 31/01/2015 | RC4 | 300*0.2 = 60 | 60 | The pass through charge is calculated for the transaction leg. |
A3P1PG1–PA3–Monthly | 200 | BC3 | 01/01/2015 | 31/01/2015 | RC3, RC4 | 200*0.3 = 60, 200*0.2 = 40 | 60+40 = 100 | The pass through charges are calculated for the transaction leg and then accumulated because the distribution code, currency code, description on bill, and characteristics of the rate components are same. |
In the above example, the BC1 and BC2 will have two pass through lines, whereas the BC3 will have one pass through line.