After a billable quantity has been compiled, the system applies the obligation's rate to the quantity to determine how much to charge the taxpayer. We refer to this process as "rate application". Refer to Rates for detailed information about rates.
Not all obligations use a rate! The obligation's obligation type defines whether or not the obligation needs a rate. The bill calculation algorithm plugged-in on the bill segment type that's referenced on the obligation's obligation type controls whether or not the system calls the obligation's rate to calculate charges. Refer to Defining Bill Segment Types for a description of the various bill segment creation algorithms that are supported in the system.
Your proration choices impact what appears on a bill. A rate contains a variety of effective-dated information (e.g., the prices are effective-dated, the structure of the rate is effective-dated, etc.). If this effective-dated information changes during a bill period, the system may need to prorate the charges. For example, if the sales tax percentage changes mid-period, the system can prorate the tax change (e.g., 20 days at 6% and 11 days at 6.25%). When you setup a rate, you define exactly how the system handles changes that occur during a bill segment. For example, you can tell the system that sales tax changes should not be prorated. Rather, it should use the value effective at the start / end of the bill period (note, you have several other options). We mention this because your choices have a large impact on how a rate affects the information on bill segments. Refer to Effective Dates & Proration for more information.
Rate application is a very sophisticated process as it can affect every aspect of a bill segment. The following points describe how rate application works at a high-level:
The calculation details that were amassed earlier are passed into rate application.
Next, the rate schedule's rate quantity rules (if any) are executed. Rate quantity rules are used to calculate rate quantities (RQ) referenced in the rate that cannot be derived from the calculation details. For example, if you have a rate that has a charge based on the number of days in the bill period, a rate quantity rule would be necessary to calculate the number of days in the bill period.
The system determines which of the rate's rate versions should be processed. Note, a flag on the rate schedule allows you to control what happens if multiple rate versions are detected during the bill period. A bill segment "calculation detail" is created for each such rate version. Each calculation detail contains the results of executing the rate version's rate components (where a separate bill line is created for each rate component). Each bill line contains:
An audit of what was priced.
How the printed bill line should look (if the bill lines is printed).
How the amount of the bill line should be booked in the general ledger.
There are many plug-in spots available on a rate component. These plug-ins can manipulate virtually every aspect of the bill segment. This means if you require functionality that isn't support by the base package rate components, you can build additional rate component plug-ins to do whatever you need.
After every rate version is processed, rate application returns the calculation details to the process that called it. This point is important as it means that rate application executes in memory (i.e., it does NOT insert the calculation details on the database, rather, it returns them to whatever process called rate application). Because rate application executes in memory, it can be used to perform billing calculations in many parts of the system. For example:
Billing uses rate application to calculate the charges that are eventually saved on the bill's bill segments.
The Rate Check transaction calls rate application when you want to check a rate real-time. When you use this transaction, you enter the quantities that are passed into rate application and then rate application shows you the calculation details that result.
Refer to Rates for more information about how rates are constructed.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.