Core information about a rate component is defined using .
Description of Page
Rate Component contains a concatenation of basic information about the rate component. This information only appears after the rate component has been added to the database. The adjacent up and down arrows cause the rate component immediately before or after this rate component to be displayed.
Rate Version defines the rate version to which the rate component is linked. Sequence defines the relative position of this rate component in respect of the other rate components. The position is important because it defines the order in which the system calculates the charges AND the order in which the calculated charges appear on bills. Rate Version and Sequence form the unique identifier of the rate component. Both fields become protected after the rate component is added to the database.
Re-sequencing rate components. You must use the Rate Version Merge transaction to reposition a rate component. If you use the up / down arrows on the Rate Version Merge, the system will change the rate component's Sequence and change all rate components that reference the old Sequence accordingly.
Leave gaps in the sequence numbers. Make sure you leave space between sequence numbers so that you can add new rate components between existing ones in the future. If you run out of space between rate components, you can use the Rate Version Merge transaction to re-sequence a rate version's rate components.
Eligibility criteria are highlighted. If the rate component has eligibility criteria, an indication of such appears.
Select the Rate Component Type that corresponds with the rate component. The screen will display the appropriate fields, which correspond with the categories of rate components described in Designing Rate Components. This field will be gray when the rate component is referenced on other rate components.
The Rate Component Type affects what you can enter on other parts of the window. The remainder of this section is devoted to those fields that can be entered regardless of RC Type. The subtopics that follow describe those fields whose entry is contingent on the RC Type.
Use Description to describe what the rate component does.
Rounding Type and Precision control how the system rounds the rate component's calculated value. Refer to Rate Component Rounding for a complete description.
Default note. Rounding Type defaults to Nearest and Precision defaults to a value consistent with the decimal positions defined on the rate schedule's currency code.
Turn on For Calculation Purposes Only (FCPO) if this rate component exists purely to calculate the percent / flat rate / unit rate used by another rate component. When this switch is on, the system does not include the calculated amount in the bill total.
When this switch is on:
You must define what is calculated in Result Type; permissible values are Unit Rate, Charge, Step Multiplier and Percentage.
Use Create a Bill Line to define if a bill line should be created for the rate component (if you don't need to show the results to the taxpayer or a user, there is no need to create a bill line).
If a bill line is being created, use the FCPO Retention Rule to define if the FCPO amount should be set to zero on the bill line or whether the bill line's amount should be set equal to the FCPO amount.
For each rate component, you will need to select the Value Type and Value Source. Valid values for the Value Type are Charge, Percentage and Unit Rate. More information to help determine which value type to choose is described in the How To sections below. Based on the Value Source entered, the remainder of this row will change.
If the Value Source is Rate Factor, then a prompt to indicate the Rate Factor will appear.
If the Value Source is Other Rate Component, then a prompt to indicate the RC Sequence will appear.
If the Value Source is Value, then a prompt to indicate the Value directly on the rate component will appear.
If the Value Source is Value Algorithm, then a prompt to indicate the Value Algorithm will appear.
If you plan to use this method, you must set up this algorithm in the system. This can be done with the following options:
Create a new algorithm (refer to Setting Up Algorithms).
On this algorithm, reference an Algorithm Type that calculates a rate component's value. Click here to see the algorithm types available for this plug-in spot.
For more information about which method to use, refer to Designing Rate Components.
If the charges associated with the rate component are only levied during a specific season, you must turn on the Seasonal options.
When Seasonal is turned on, you use Prorate Method to define how the system should prorate a seasonal charge when a bill segment's start and end dates are not entirely within the seasonal period (defined in Season). The following options are available:
Accounting Date Dependent. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the accounting date associated with the bill segment is within the seasonal period.
Bill End Date. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the bill segment end date is within the seasonal period.
Bill Start Date. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the bill segment start date is within the seasonal period.
Prorate. This option will prorate the charge calculated by this rate component based on the number of days in the adjacent season that is included in the bill period. For example, if a bill period is from 15-April through 15-May and the seasonal period is from 1-May through 31-October, the system will assume 15 / 30 of the charge should be levied.
Prorate seasonal RQ. This option is only pertinent if you have:
Seasonal rate quantity (RQ) charges, AND
You have a bill that crosses seasonal boundaries, AND
You have multiple rate versions effective across the bill period.
If this option is used, the system will prorate the charge calculated by a RQ rate component based on the number of days in the adjacent season that is included in the rate version's calculation period.
The Seasonal period is defined in the two adjacent fields. The first field contains the day and month when the season starts; the second field contains the day and month when the season ends. The day and month should be entered in the format defined in your display profile.
Override Seasonal Proration. If the seasonal functionality provided with the system does not work for your organization, you may override the logic using the Override Seasonal Proration plug-in spot on the installation record.
Description On Bill, Print, and Print If Zero all control if the rate component contributes a line to the taxpayer's bill. These fields can also be modified on Rate Version - Bill Print Info. You might find it easier to setup these fields on the rate version transaction as you can copy and paste descriptions between rate components. Refer to Rate Version - Bill Print Info for a description of these fields.
The other fields on this page are dependent on the type of rate component. See the "how to" subtopics below for more information.
Copyright © 2011, Oracle and/or its affiliates. All rights reserved.