Every obligation must reference an obligation type. The obligation type defines the responsibilities between the taxpayer and the tax authority. The obligation type dictates how returns, bills and payments are handled as well as how overdue debt is collected and how tax collections will be booked in your general ledger.
Setting Up Terms and Conditions
Setting Up Obligation Type Start Options
Obligation Type Start Options Merge
The topics in this section provide guidelines describing how to design obligation types. When designing obligation types you will want to consider what the obligation will be used for. Generally speaking, obligation types can be separated into two categories.
· The first type of obligation type relates to the specific tax types of a tax authority. Examples of these include corporate tax and property tax. The specific tax type dictates how bills are handled and what collections activities are available to the tax authority.
· The second type of obligation relates to specific events or transactions that require certain follow-up actions from the tax authority or taxpayer (or both). Examples of these include overpayment obligations and payment plan obligation. With overpayments, the tax authority has the responsibility to properly handle the excess credit a taxpayer has created with a payment. Payment plans are the responsibility of the taxpayer in that they are required to send in a series of payments on a predefined schedule. Each obligation must be monitored to ensure proper compliance.
Contents
Over/Under Cash Drawer Obligations
Payment Upload Error Obligations
Filing period obligations are one of the tax type specific obligation types. Examples of these tax types include individual income, sales and use, corporate, withholding, and fuel taxes. These are examples of return based taxes in which the taxpayer has the responsibility to file a return for each filing period obligation. There are usually statutory considerations when configuring these obligation types. You will want to consider the following when designing your obligation for these types of taxes.
· The obligation type must reference a defined tax type. The specific tax type will dictate the rules for that obligation. It should indicate that a Tax Role is required and should include the valid filing calendars for the tax type.
· The obligation type should be configured to indicate that a filing period is required.
· Distribution code and general ledger division for the obligation directs how the money is accounted. Different taxes may be moved to different accounts. While an individual income tax may go to the general treasury fund, a fuel tax may go the highway construction fund. The distribution code will reference an algorithm that directs how the money will be accounted for.
· Adjustment profile must be defined for the obligation. Adjustment profiles contain the individual listing of adjustment types that are available for that obligation type.
· An appropriate P&I control and P&I algorithms should be defined for the obligation type. Refer to P&I Rules for a P&I Control Define the Calculation for more information.
· Define the default debt category priority for credits linked to obligations of this type. Refer to Debt Categories and their Priorities for more information.
Each tax type will have its own unique attributes that will change how the obligation is set up. The more details you add to your obligation type, the more robust your processing of that obligation will be. Before configuring for this obligation type you should thoroughly review the statutory considerations and make sure they are all addressed when setting up your obligation type.
Property tax obligations are another type of tax specific obligation type. Property tax obligations are based off the assessed value of a taxpayer’s asset. Typically they are items such as real estate or automobiles but can include boats, RV’s, and other high value items. They differ from filing period obligations in that it is the tax authority’s responsibility to assess the value and calculate the amount of tax owed. It is then the taxpayer’s responsibility to either pay or appeal the assessed value. The considerations are very similar to filing period obligations.
· The obligation type must reference a defined tax type. The specific tax type will dictate the rules for that obligation.
· Payment plans are often utilized for property tax obligations. Due to their infrequent assessment and billing (once or twice a year) the amount is usually large enough where a significant number of taxpayers would have difficulty paying. If payment plans are utilized then make sure to check that option under the billing tab.
· Distribution code and general ledger division for the obligation directs how the money is accounted. Different taxes may be moved to different accounts. While an individual income tax may go to the general treasury fund, a fuel tax may go the highway construction fund. The distribution code will reference an algorithm that directs how the money will be accounted for.
· Rates may be utilized more often for property taxes. Property taxes tend to be a locally administered tax. The breakdown of how the tax is applied to local services can be done using the rate schedule option under the rate tab.
· Adjustment profile must be defined for the obligation. Adjustment profiles contain the individual listing of adjustment types that are available for that obligation type.
You create a billable charge whenever a taxpayer should be charged for a service that occurs outside the normal course of business. For example, if a taxpayer requires a review of their property assessment, you may charge them an administration fee. You can also use billable charges to “pass through” other bill ready charges generated outside the system, by another application, or by a 3rd party supplier.
A billable charge must reference an obligation. This obligation behaves just like any other obligation:
· Bill segments are created for the obligation. Whenever billing is performed for an account with billable charge obligations, the system creates a bill segment for each obligation with unbilled charges. If multiple unbilled charges exist for a given obligation, only one bill segment will be created and it will contain details about all of the billable charges.
· Payments are distributed to the obligation. Payments made by an account are distributed to its billable charge obligations just like any other obligation.
· Overdue debt is monitored. The credit and collections process monitors billable charge obligations for overdue debt and responds accordingly when overdue debt is detected.
Therefore, you must set up at least one obligation type to hold your billable charge debt. You may have multiple charges based on billing frequencies, A/R booking, debt monitoring, etc. It’s really up to you.
The easiest way to determine how many billable charge obligation types you’ll need is to define every conceivable billable charge (which you should have done when you designed your billable charge templates). Then ask yourself if they have the same billing and payment behavior, if so, you’ll have one obligation type. If not, you’ll need one obligation type for each combination.
When a taxpayer pays more than they owe, you must decide what to do with the excess money. The following points describe two possibilities:
· You could create a new obligation to hold the excess (let’s call it an overpayment obligation). The credit would need to be transferred from this obligation to the tax obligations at an appropriate time.
· You could direct the excess payment on one of the existing tax obligations.
You control which method is used by plugging in the appropriate Overpayment Distribution algorithm on each account type (i.e., you can choose a different method for different account types). If you choose to hold overpayments on a separate obligation, then you must set up an obligation type.
The following points highlight interesting information about overpayment obligation types:
· It should have an accounts payable distribution code. This is because when a payment segment is created for this type of obligations, the system must credit a liability (an overpayment is a liability).
· It’s important to indicate that the overpayment obligation is a one-time obligation. Why? Because this means that the system will automatically close the obligation when it’s balance falls to zero (i.e., when appropriate business processes transfer all of the overpayment to tax obligations).
· A bill segment type is not needed because the system never creates bill segments for such obligations (they exist only to hold excess credits).
· P&I controls and the P&I related algorithms are not needed.
· You may also want to turn on the alert message
· You must reference this overpayment obligation type as the parameter value on your overpayment algorithm (this algorithm is plugged in on the desired account types). Refer to Overpayment Algorithm for more information about this algorithm.
· You must design appropriate business procedures to use this overpayment when additional debt is incurred on tax obligations.
Some agencies may choose to transfer written of debt from the “normal” obligation onto one or more write-off obligations. When the debt is transferred to a write-off obligation, the distribution code on the “normal” obligation is credited (typically an A/R GL account), and the distribution code on the write-off obligation is debited.
You will almost always need a write-off obligation whose distribution code is the write-off expense. However, if you don't practice cash accounting, you may have uncollectible debt for liabilities (and you don't owe the liability if you don't get paid). In this case you’ll need another obligation type for the liabilities.
The following points highlight interesting information about write-off obligation types:
· The distribution code is either an expense or a liability account. This is because when debt is transferred to these types of obligations, the system must debit either an expense account (i.e., write-off expense) or a liability account. It’s important to note that in The Ramifications of Write Offs in the General Ledger we explain how this liability account may be overwritten with the liability account that was originally booked.
· They do not need a bill segment type because the system never creates bill segments for such obligations (they exist only to hold uncollectable debt)
Note. The adjustment type used to set the offending obligation’s current balance equal to its payoff balance is defined on each write-offable obligation type. The adjustment type used to transfer the delinquent debt to the write-off obligation is defined on the write-off obligation type.
An Alternative. If you have a limited number of liability accounts, you may decide to have a separate write-off obligation for each liability account. Doing this would proliferate the number of obligations created at write-off time. However, it would simplify the remittance of payment to the third party if the reversed liability is ever paid.
In order to balance a tender control that is out-of-balance, your organization must set up an account with an obligation whose obligation type references the over/under expense account. You will probably only have one obligation that references this obligation type, but you still must have it if you remit funds via a cash drawer.
For more information about over/under processing, refer to How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under).
The following points highlight interesting information about this obligation type:
· It has an expense distribution code. This is because when a payment segment is applied to this type of obligation, the system must debit an expense account for under amounts (and credit it for over amounts).
· It doesn’t need a bill segment type because the system never creates bill segments for such obligations (it only has over/under payment segments linked to it).
If the payment upload process detects an invalid account on a payment upload record, it will create a payment for the suspense obligation defined on the upload process’ tender source (see Setting Up Tender Sources). You should create a special obligation type for this obligation.
For more information about the payment upload process, refer to Phase 3 – Create Payment Events, Tenders, Payments and Payment Segments.
The following points highlight interesting information about this obligation type:
· It has an expense distribution code. This code should probably be a suspense account. All payment segments that are created for this obligation will eventually be transferred to a “real” obligation and therefore this GL account’s balance should be zero when no payments are in suspense.
· It doesn’t need a bill segment type because the system never creates bill segments for such obligations (it only has invalid account payment segments linked to it).
If you allow your customers to pay overdue debt using a payment plan, you need to set up obligation types for pay plan obligations.
For more information about pay plans, refer to Defining Pay Plan Options.
In this section, we explain how to create/maintain your obligation types.
Obligation Type - Main Information
Obligation Type - Adjustment Profiles
Obligation Type - Characteristics
Obligation Type - Pay Plan Recommendation Rule
Obligation Type - BC Upload Overrides
Open Admin Menu, Obligation Type and navigate to the Main tab to define core information about your obligation types.
Description of Page
Enter a unique combination of Division and Obligation Type for every obligation type.
Enter a Description for the obligation type.
Tax Type defines the type of service associated with the obligation type. If the obligation type has rates, only rates belonging to this tax type may be linked to the obligation type.
For more information about tax types, refer to Setting Up Tax Types.
Use an Obligation Business Object to define a BO that may govern additional rules related to obligations of this type.
Indicate if the Filing Period Applicability for obligations of this type is Required or Not Allowed.
Select the Distribution Code and GL division that defines the receivable account for receivable-oriented obligations. For non-receivable oriented obligations, this distribution code depends on the obligation type's function. Refer to Designing Obligation Types for some examples.
Select the Revenue Class associated with the obligation type (and its obligations). The revenue class may affect the revenue account(s) generated by the obligation’s rate.
Refer to Rate Component – GL Distribution for more information about revenue class.
Select the Payment Segment Type that defines how payment segments linked to obligations of this type affect:
· The obligation’s payoff and current balances
For more information about payment segment types, refer to Setting Up Payment Segment Types.
When a tender is canceled, a cancellation reason must be supplied. If the cancellation reason indicates a NSF (non sufficient funds) charge should be levied, the system invokes the Levy an NSF Charge algorithm specified on the tender’s account’s account type. Because adjustments must be linked to an obligation, the algorithm must determine the appropriate obligation to use to levy the adjustment based on business rules. The charge is levied using the NSF Adjustment Type of the appropriate obligation’s obligation type.
Warning! You must specify adjustment type profiles on the obligation type (on the Adjustment Type window) before adjustment types will appear in the above drop downs.
For more information about adjustment types, refer to Setting Up Adjustment Types.
Define the Payment Grace Days applicable for obligations of this type. Refer to Due Dates for Filing Period Based Obligations for more information about due dates.
Select the Payment Priority. This field is available for use by the algorithms that distribute partial payments amongst an account’s obligations. Higher priority obligations will have their debt relieved before lower priorities. Refer to Distribution Based on Payment Priority and Delinquent Payment Distribution Algorithm for information about payment distribution algorithms that use this field.
Note. The values for this field are customizable using the Lookup table. This field name is PAY_PRIORITY_FLG.
For more information about distribution priority, refer to Distributing A Payment Amongst An Account’s obligations.
Select the Delinquent Payment Priority. This field is available for use by the algorithms that distribute partial payments amongst an account’s obligations. Higher priority obligations will have their debt relieved before lower priorities. Refer to Delinquent Payment Distribution Algorithm for information about a payment distribution algorithm that uses this field.
Note. The values for this field are customizable using the Lookup table. This field name is DEL_PRIORITY_FLG.
Define the default Debt Category Priority for credit financial transactions linked to obligations of this type. Refer to Debt Categories and their Priorities for more information.
Turn on Do Not Overpay if the system is not allowed to distribute an overpayment to this type of obligation (i.e., the obligation is not allowed to have a system-created credit balance). This field is available for use by algorithms that distribute overpayments. Refer to Overpayments Held On Highest Priority Obligation for information about an overpayment algorithm that uses this field.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_SA_TYPE.
Open Admin Menu, Obligation Type and navigate to the Detail tab to define additional details about a given obligation type.
Description of Page
Turn on Display As Alert if Control Central should display an alert if an account has an obligation of this type that isn’t Closed or Canceled. If this switch is on, also enter the Alert Information to appear on Control Central. We recommend only using this feature on unusual obligation types (e.g., write-offs) so that a CSR is not presented with an alert for every obligation type.
If this obligation type is used for any of the special roles defined in the drop down of Special Role Flag, indicate which one. Valid values are: Billable Charge, Pay Plan, Write Off. This information is used on windows with functionality that can only be used by obligations used for specific roles. For example, the Billable Charge window group can only reference Billable Charge obligations.
If the Special Role is Write Off, you must also define the following adjustment types:
· Use Adjustment Type (Xfer) to specify the type of adjustment used to transfer funds from the uncollectable obligations to the write off obligation.
Warning! You must specify adjustment type profiles on the obligation type (on the Adjustment Type window) before adjustment types will appear in the above drop downs.
Turn on One Time Charge if this obligation type is used for one-time invoices. When a one-time invoice obligation is created, the system sets the stop date of the obligation to be equal to the start date.
Where Used
The alert information is used by Control Central to alert a CSR when unusual obligations exist for an account. Refer to Control Central – Main for more information.
Only obligation types designated as being Billable Charge may have billable charges linked to them. Refer to Maintaining Billable Charges for more information.
Only obligation types designated as Pay Plan may be used to set up pay plans. Refer to Pay Plans for more information.
Only obligation types designated as being Write Off may be specified as the write off obligation type on distribution codes. Refer to Setting Up Distribution Codes for more information.
Open Admin Menu, Obligation Type and navigate to the Billing tab to define how the system manages bill segments for obligations of a given obligation type.
Description of Page
Turn on Eligible for Billing if the system should create bill segments for obligations of this type.
Define the minimum number of days a bill segment (other than the final segment) must span using Minimum Days for Billing. This is useful to prevent initial bill segments that span only a few days.
For more information about minimum days, refer to Preventing Short Bill Segments.
Select the Bill Segment Type that controls both how bill segments for this obligation type will be created and how the related financial transaction affects the general ledger and the taxpayer’s debt.
For more information about bill segment types, refer to Setting Up Bill Segment Types.
Define the default Debt Category to assign to bill segment type financial transactions for obligations of this type. Refer to Debt Categories and their Priorities for more information.
Required for base algorithms. The base P&I calculation algorithm and the base Determine Detailed Balance algorithm require that every debit financial transaction reference a debt category.
Use Default Description on Bill to define the verbiage that should print on the taxpayer’s bill.
Rates overwrite this description. The Default Description on Bill is not applicable for obligations whose charges are calculated using a rate. Why? Because the description that appears on the bill segment is defined on the rate schedule’s rate version.
Billable charges overwrite this description. The Default Description on Bill is not applicable for obligations whose charges are calculated using a billable charge. Why? Because the description that appears on the bill segment is defined on the billable charge.
Use the Billing Processing Sequence if you need to control the order in which obligations linked to this obligation type are processed by billing processes.
Use Bill Print Priority to define the order in which the obligation type’s bill segments should appear on bills (relative to the other obligation types that appear on a bill).
Note. The values for this field are customizable using the Lookup table. This field name is BILL_PRT_PRIO_FLG.
Use Max Bill Threshold if you want the system to generate a bill error when a bill segment is produced in batch that exceeds a given value. These bill errors will appear on the standard billing queries and To Do lists. If, after reviewing the high value bill segment, an operator truly intends to send the bill out, they should regenerate the bill. Refer to How To Correct A Bill Segment That’s In Error for more information.
Warning! The value entered in this field will DEFAULT onto obligations of this type when they are first created. An operator may change the default value on an obligation in case a specific taxpayer has unusually high bills that continually error out. It’s important to be aware that if you change the value of High Bill Amount on an obligation type and there already exist obligations of this type, the existing obligations will contain the original value (the new value on the obligation type will not be propagated on the existing obligations).
Turn on Characteristic Location Required if a characteristic location must be linked to the obligation when the obligation is activated. The characteristic location is used to define the taxing authorities associated with the obligation’s bill segments. It is also used to identify where the obligation’s service is located on various windows.
For more information about how characteristic location is used, refer An Illustration Of A Rate Factor And Its Characteristics.
Use the Initial Start Date Option to control how billing should calculate the calculation period for the very first bill for obligations of this type. This field is important if your obligation has rate components that include daily charges. Set the field to Include First Day if the obligation's start date should be included in the daily charges. Set the value to Add 1 Day Always if the obligation's start date should never be included in the daily charges. Set the value to Add 1 Day for Back-to-back if the obligation's start date should only be included in the daily charges if no previous taxpayer was responsible for the charge (for example for property tax). This field is not applicable for obligation types with a special role of Billable Charge.
Obligations may have the end date of their bill segments defined on a user-maintained bill period schedule. This option is used when bill segments must fall on strict calendar boundaries (e.g., quarterly bills that end on the last day of the quarter). If this obligation type should be billed like this, select Use Bill Period in the Use Calendar Billing field. When this option is used, you must define the Bill Period whose schedule defines the bill segment end dates.
For more information about bill period schedules, refer to Defining Bill Cycles and Bill Periods. For more information about other bill end date methods, refer to Ways To Control The End Date Of A Bill Segment.
Instead of the Use Bill Period method, obligations may have their bill segment end date based on a specified date. If this obligation type should be billed like this, select Anniversary Future Billing or Anniversary Past Billing in the Use Calendar Billing field. When either option is used, you must define the Anniversary Bill Frequency. This frequency defines the amount of time between bill segments.
For more information about anniversary billing, refer to Using The Anniversary Method. For more information about other bill end date methods, refer to Ways To Control The End Date Of A Bill Segment.
Total Bill Amount indicates whether obligations of this type can use the total amount to bill field on the obligation page. Valid values are Not Allowed and Required.
If Required is selected, you must enter the Total Amount To Bill Label. The Total Amount To Bill Label defines the label that prefixes the total bill amount on the obligation page for obligations of this obligation type.
Recurring Charge indicates whether obligations of this type can use the recurring charge field on the obligation window. Valid values are Not Allowed, Optional and Required. If either Optional or Required are used, you must enter:
· Recurring Charge Amount Label. This defines the label that prefixes the recurring charge amount on the obligation window for obligations of this obligation type.
· Recurring Charge Frequency. This defines the following:
· Specifies the frequency at which the Recurring Charge Amount specified on obligations of the obligation type is to be billed.
· Serves as the basis for proration of the Recurring Charge Amount.
· Specifies the frequency at which obligations of the obligation type without a rate will be billed.
Set the Eligible for Pay Plan flag to Eligible if you want obligations of this type to be eligible to be covered by a pay plan.
Open Admin Menu, Obligation Type and navigate to the Rate tab to define the rates that may be referenced on obligations of a given type.
Description of Page
Turn on Rate Required if the bill segment creation algorithm for the obligation type expects a rate schedule to be referenced on obligations of this type.
For more information, refer to Rates.
Define the date the system uses when selecting an effective-dated rate (from the obligation’s rate history) using Rate Selection Date. Selecting Bill Start Date will cause the system to use the rate effective on the first day of the bill segment’s calculation period. Selecting Bill End Date will cause the system to use the rate effective on the last day of the bill period. Selecting Accounting Date will cause the system to use the rate effective on the accounting date associated with the bill.
The information in the Rate Schedules collection defines the rates that may be referenced on obligations of this type. The following fields are required for each obligation type:
Rate Schedule Specify the rate schedule; its description is displayed adjacent.
Use Rate As Default Turn on this switch for the rate to be defaulted on new obligations.
Where Used
This information is used to default and validate the rate specified on an obligation. Refer to Obligation – Rate Info for more information.
Open Admin Menu, Obligation Type and navigate to the Adj Profile tab to define the adjustment profiles that define adjustment types that may be referenced on obligations of a given type.
Description of Page
Define the Adjustment Type Profiles that, in turn, define adjustment types that may be referenced on obligations of a given type.
For more information about adjustment type profiles, refer to Setting Up Adjustment Type Profiles.
Where Used
This information is used to validate the adjustments linked to the obligation. Refer to Adjustments – Main Information for more information.
To define characteristics common to all obligations of a given type, open Admin Menu, Obligation Type and navigate to the Characteristics tab.
Description of Page
Use the characteristics collection to define a Characteristic Type and Characteristic Value common to all obligations of this type.
Note. You can only choose characteristic types defined as permissible on an obligation type record. Refer to Setting Up Characteristic Types & Their Values for more information.
Open Admin Menu, Obligation Type and navigate to the Algorithm tab to define the algorithms that should be executed for obligations of a given type.
Description of Page
The grid contains Algorithms that control important functions in the system. You must define the following for each algorithm:
· Specify the System Event with which the algorithm is associated (descriptions of all possible events are provided below).
· Specify the Sequence and Algorithm for each system event. You can set the Sequence to 10 unless you have a System Event that has multiple Algorithms. In this case, you need to tell the system the Sequence in which they should execute.
Warning! These algorithms are typically significant processes. The absence of an algorithm may prevent the system from operating correctly.
The following table describes each System Event for which you can define algorithms.
|
System Event |
Optional / Required |
Description |
|
Bill Completion |
Optional |
Thesealgorithms are executed whenever a bill is completed for an account that contains a non-canceled obligation of this type. Note. Algorithms of this type are called for all non-Canceled obligations, regardless of whether or not they are billed. If your algorithms should only be processed under certain conditions (for example, only process this algorithm for Active obligations), then it is the responsibility of the algorithm to check the conditions before continuing. Click here to see the algorithm types available for this system event. |
|
Break Pay Plan Obligation |
Optional |
These algorithms are executed when a pay plan is manually stopped via the pay plan maintenance page. Click here to see the algorithm types available for this system event. |
|
Cash Accounting True Up |
Optional |
This algorithm is responsible for making all necessary adjustments to the general ledger to transfer amounts from "holding" general ledger accounts to true payable accounts. It is executed when the Calculate P&I service has been called in Update mode, regardless of whether or not P&I is applicable for the obligation type. Refer to P&I and Cash Accounting for more information. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
Determine Detailed Balance |
Optional |
This plug-in spot is responsible for breaking down an obligation's balance into balances by separate assessments and debt categories (for example: tax, penalty, interest, fees, etc). It is used in the base P&I Calculation plug-in and several other services that require the balance of an obligation to be broken down by assessment and debt category. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
FT Freeze |
Optional |
These algorithms are executed whenever a financial transaction is frozen that is linked to an obligation of this type. Click here to see the algorithm types available for this system event. |
|
Obligation Activation |
Optional |
These algorithms are executed when an obligation status changes from Pending Start to Active. It performs any additional activities that are necessary to activate an obligation. Click here to see the algorithm types available for this system event. |
|
Obligation Cancel |
Optional |
These algorithms are executed when an obligation status changes to Canceled. It performs any additional activities that are necessary when an obligation is canceled. Click here to see the algorithm types available for this system event. |
|
Obligation Creation |
Optional |
These algorithms are executed when an obligation is created. Click here to see the algorithm types available for this system event. |
|
Obligation Information |
Optional |
We use the term “obligation information” to describe the basic information that appears throughout the system to describe an obligation. The data that appears in “obligation information” is constructed using this algorithm. Plug an algorithm into this spot to override the "obligation information" algorithm on installation options or the system default “obligation information” if no such algorithm is defined on installation options. Click here to see the algorithm types available for this system event. |
|
Obligation Stop |
Optional |
These algorithms are executed whenever an obligation’s status changes from pending stop to stopped. Click here to see the algorithm types available for this system event. |
|
Obligation Stop Initiation |
Optional |
These algorithms are executed whenever an obligation’s status becomes pending stop. Click here to see the algorithm types available for this system event. |
|
P&I Calculation |
Optional |
This plug-in spot is responsible for calculating penalty and interest for the input obligation. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
P&I Eligibility |
Optional |
This plug-in spot is invoked by the base Calculate Penalty and Interest plug-in. It receives an obligation id as input and returns an indication of whether the obligation is eligible or ineligible for P&I. Refer to P&I Eligibility for more information. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
P&I Post Processing |
Optional |
This plug-in spot is invoked by the base P&I Calculation plug-in after all the penalty and interest calculations are finished. Algorithms plugged into this plug-in spot are responsible for additional logic performed at the end of the P&I process. Refer to P&I Post Processing for more information. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
P&I Pre-processing |
Optional |
This plug-in spot is invoked by the base P&I Calculation plug-in and is used to populate information needed during P&I calculations. Refer to P&I Pre-Processing for more information. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
P&I Prepare Periodic Balance |
Optional |
This plug-in spot is called from the Calculate Penalty and Interest plug-in spot for each date range being calculated. It is responsible for passing the appropriate FTs to the Determine Detailed Balance plug-in for the current date range. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
|
Payment Freeze |
Optional |
These algorithms are executed whenever a payment is frozen. Click here to see the algorithm types available for this system event. |
|
Process Pay Plan Scheduled Payment |
Optional |
These algorithms are executed by the Pay Plan Scheduled Payment Processing background process whenever a scheduled payment is due. If the pay plan obligation is unmonitored, this algorithm is not called. This algorithm should be specified on pay plan obligation types to create the necessary adjustments for the pay plan obligation. Click here to see the algorithm types available for this system event. |
|
Retrieve FT List |
Optional |
This plug-in spot is responsible for retrieving the existing FTs for an obligation. It obtains all the data for each FT that is needed for P&I Calculation logic and the Determine Detailed Balance logic. Refer to The Big Picture of Penalty and Interest for more information. Click here to see the algorithm types available for this system event and for more information about the behavior of this plug-in spot. |
Open Admin Menu, Obligation Type and navigate to the Pay Plan Rec’n Rule tab to define the recommendation rules that are valid for pay plan obligations of this type.
Description of Page
If the obligation type’s special role is Pay Plan, you may define the Recommendation Rules that are valid on pay plan obligations of this type. Check the Use As Default box to indicate the default recommendation rule for obligations of this type.
For more informationabout pay plans, refer to Defining Pay Plan Options.
Where Used
The pay plan recommendation rules are used to recommend the payment amount and payment schedule for pay plan obligations. Refer to Maintaining Pay Plansfor more information.
Open Admin Menu, Obligation Type and navigate to the P&I Control tab to define the penalty and interest control record that governs the penalty and interest calculation rules for obligations of this type.
Description of Page
The P&I Control and its P&I Rules define the configuration governing the tax authority's penalty and interest calculations. As these rules change over time, a new P&I Control record with the new applicable P&I Rules is created and linked to the applicable obligation types for the effective date of the change.
The following fields display:
· Effective Date is the date the P&I Control rate becomes effective.
· P&I Control defines the P&I rules used to calculate the individual penalty and interest charges.
P&I configuration. Refer to Setting Up Penalty and Interest Options for more detail about the configuration required for calculating penalty and interest.
Where Used
This information is used by the P&I Calculation plug-in to apply specific rules.
Open Admin Menu, Obligation Type and navigate to the BC Template tab to define the billable charge templates that can be used on obligations of a given type.
Only billable charges have billable charge templates. Only obligations that are defined as Billable Charges (in the Special Role on the Details window) may use the grid on this window.
Description of Page
The information in the Billable Charge Template collection defines the obligation type’s permissible billable charge templates. A billable charge template contains the default bill lines, amounts and distribution codes used to levy a one-off charge. The following fields are required for each template:
Billable Charge Template Specify the billable charge template. Its description is displayed adjacent.
Use As Default Turn on this switch for the template to be defaulted on new billable charges linked to obligations of this type (if any).
Where Used
This information is used to limit the billable charge templates that can be used for a given obligation type.
The BCU2 – Create Billable Charge background process is responsible for creating billable charges for each billable charge upload staging record interfaced into the system. This process will override the values of the various switches referenced on a bill charge upload staging line if the respective obligation’s obligation type has an override value for the bill charge upload staging line’s billable charge line type.
This information is optional. If you don’t need to override the values of a Billable Charge Line Type you don’t need to set up this information.
Open Admin Menu, Obligation Type and navigate to the BC Upload Override tab to define override values for a given Obligation Type / Billable Charge Upload Staging Line Type.
Description of Page
Use the Billable Charge Overrides collection to define values to be overridden on billable charge lines uploaded from an external system (refer to the description above for the details). The following switches may be overridden for a given Obligation Type and Billable Charge Line Type.
· Use the Show on Bill switch to define the value to be defaulted into the Show on Bill indicator on billable charge upload lines that reference this line type.
· Use the Appear in Summary switch to define the value to be defaulted into the App in Summary indicator on billable charge upload lines that reference this line type.
· Use Memo Only, No GL switch to define the value to be defaulted into the Memo Only, No GL indicator on billable charge upload lines that reference this line type.
· Use Distribution Codeto define the value to be defaulted into the Distribution Code on billable charge upload lines that reference this line type.
Your obligation type start options can reference terms and conditions (T&C’s) that should be defaulted onto new obligations. Each T&C is identified with a terms and condition code. To define a terms and conditions code, open Admin Menu, Terms and Conditions.
Description of Page
Enter a unique Terms and Condition code and Description. Use Text to describe the exact terms.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_TC.
Obligation type start options save users time and prevent data entry errors because they default many values on an obligation (e.g., the rate schedule, recurring charge amount, contract riders, contract terms, characteristics, terms and conditions, etc. can all be defaulted onto an obligation from a start option).
An obligation type may have zero or more start options.
· An obligation type without start options is usually one that has a very limited number of options. For example, if an obligation type has a single valid rate and no taxpayer-specific contract values, you don’t need to setup a start option (the obligation’s default rate can default based on the information defined when you setup the obligation type).
· An obligation type with multiple start options is one where many different permutations are possible. For example, an obligation type that can have multiple rates and each rate can have multiple riders is a good candidate for start options (where each start option will default, for example, a specific rate and set of contract riders).
A start option’s default values may change over time (i.e., the information on a start option is effective-dated).
Start options can cause a great deal of information to be populated on an obligation. There are several ways to change this default information:
· A user may override this information using the obligation transaction.
· If the obligation is in active or pending stop states, a button appears on Obligation - Main called Apply New Start Option. When pressed, the user is allowed to define a start option and the date its terms become effective on the obligation. Refer to Changing A Start Option for the details of this functionality.
The topics in this section describe how to setup start options.
The merge transaction can save setup time. The Obligation Type Start Options Merge transaction can be used to construct a start option by copying pieces from other start options.
Obligation Type Start Option - Main
Obligation Type Start Option - Rate Info
Obligation Type Start Option - Characteristics & Qty
Obligation Type Start Option - Terms and Conditions
Open Admin Menu, Obligation Type Start Option and navigate to the Main tab to define an obligation type’s start options.
Description of Page
Every start option is uniquely identified by the following fields:
Division & Obligation Type Enter the division and obligation type to which the start option is linked.
Start Option Enter the unique identifier of the option. Pick something easy to recognize as this will be used by CSRs to pick an option when they start service.
Effective Date Enter the earliest effective date. It should be the same as the earliest effective date of the start option’s rate (although it doesn’t hurt for it to be earlier). The date defaults to the current date. (The status, below, should be Active.)
The remaining fields further describe a start option.
Enter a Description for the start option.
Indicate its Status. For new start options, the status should be Active. When it’s no longer applicable, change it to Inactive.
Enter the Rate Schedule that should be defaulted onto obligations created using this option.
Note. Only rates that meet the following criteria may be specified: 1) the rate must be defined as valid for the division / obligation type, and 2) the rate must have at least one Finished rate version.
For more information about an obligation’s rates, refer to Obligation - Rate Info.
Enter the Recurring Charge Amount that should be defaulted onto obligations created using this option. This field is only visible when the obligation type allows recurring charges. In addition, the prompt for this field is defined on the obligation type table on the billing window (e.g., it could appear as Payment Amount, Budget Amount, or Installment Amount).
Enter the Currency Code in which monetary amounts are denominated.
Default Note. The currency code defaults from the installation record.
Enter the Total Amount to Bill that should be defaulted onto obligations created using this option. The prompt for this field is defined on the obligation type table on the billing window.
Use Number of Payment Periods is not applicable in this release.
If your obligation type has a special role of Billable Charge, then you can setup the start option to automatically create a billable charge when an obligation is created using this start option. To use this feature you should turn on the Create Billable Charge switch and specify the Billable Charge Template that will be used to create the billable charge. These fields are only allowed for obligation types with special role of Billable Charge.
Refer to Setting Up Billable Charge Templates for more information about templates.
Open Admin Menu, Obligation Type Start Option and navigate to the Rate Info tab to define the start option’s default values for contract riders and contract values.
Description of Page
The information in the Contract Riders collection defines the contract riders to be defaulted onto obligations created using this start option. The following fields are required for each instance:
Rate Factor The rate factor defines the type of rider. You may only reference rate factors designated as being applicable for contract riders.
Number of Days The number of days the rider should be in effect. This value is used by the system to set the stop date on the obligation’s contract rider. If the rider has no expiration, set this field to 0. Default note: this field will be set to 0 if left blank.
For more information about a rate’s contract riders, refer to Defining General Rate Factor Information. For more information about an obligation’s contract riders, refer to Obligation – Rate Info.
The information in the Contract Values collection defines the contract values to be defaulted onto obligations created using this start option. The following fields are required for each event:
Rate Factor The rate factor defines the type of value. You may only reference rate factors designated as allowing values in contract terms.
Number of Days The number of days the value should be in effect. This value is used by the system to set the stop date on the obligation’s contract value. If the value has no expiration, set this field to 0.
Value The amount of the contract value.
For more information about a rate’s contract values, refer to Defining General Rate Factor Information. For more information about an obligation’s contract values, refer to Obligation – Rate Info.
Open Admin Menu, Obligation Type Start Option and navigate to the Characteristics & Qty tab to define the start option’s default values for characteristics and contract quantities.
Description of Page
The information in the Characteristics collection defines the characteristics to be defaulted onto obligations created using this start option. The following fields are required for each instance:
Characteristic Type This defines the type of characteristic. Note: You may only define characteristics valid on obligations.
Characteristic Value This defines the characteristic value that will be defaulted.
For more information about an obligation’s characteristics, refer to Obligation – Chars, Qty & Rec. Charges.
The information in the Contract Quantity collection defines the contract quantities to be defaulted onto obligations created using this start option. The following fields are required for each instance:
Contract Quantity Type This defines the type of contract quantity.
Contract Quantity The amount of the contract quantity.
For more information about an obligation’s contract quantities, refer to Obligation – Chars, Qty & Rec. Charges.
Obligations may contain legal terms and conditions (T&Cs) that govern the agreement the taxpayer has with the tax authority.
The system defaults T&Cs for an obligation from the start option used to initially create it, if applicable. You can change an obligation's T&Cs at will.
Open Admin Menu, Obligation Type Start Option and navigate to the Terms and Conditions tab to define the start option’s default terms and conditions.
Description of Page
The information in the grid defines the terms and conditions to be defaulted onto obligations created using this start option. The following fields are required for each instance:
Terms and Conditions This is the code that identifies a term and condition (T&C).
Number of Days The number of days the T&C should be in effect. This value is used by the system to set the end date on the obligation’s T&C. If the T&C has no expiration, set this field to 0. This field is defaulted to 0 if left blank.
Use this page to modify an existing obligation type start option (start option) by copying information from other start options.
Note. The target start option must exist prior to using this page. If you are creating a new start option, you must first go to the Start Option page to add the new start option and then navigate to the merge page to copy collection information.
Duplicate versus Merge. The Start Option page has Duplication capability. You would duplicate a start option if you want to a) create a new start option AND b) populate it with all the information from an existing start option. You would use the start option merge page if you want to build a start option using pieces of one or more start options.
Contents
Start Options Merge - Characteristics and Quantities
Start Options Merge - Terms and Conditions
Open Admin Menu, Obligation Type Start Options Merge and navigate to the Main tab to open this page.
Description of Page
Select the Original Start Option, which is the target for merging the start option collection information.
Select the Merge From Start Option, which is your template start option to copy the collections from.
Note. You may only copy information from one Merge From start option at a time. If you wish to copy information from more than one start option, select the first Merge From start option, copy the desired records, Save, then select the next Merge From start option.
The left portion of the page will display any existing records in the collections for the original start option. The right portion of the page will display the existing records in the collections for the Merge From start option.
You may use the Copy All button to copy all the records in all the collections from the Merge From start option to the Original start option. If you do not choose to copy all, you may copy records individually as described below.
The left portion of the Contract Riders collection initially displays existing contract riders linked to the original start option. In the Merge Type, you will see the word Original, for any of these records. The Rate Factor and Number of Days for each contract rider are displayed. In the right portion of the collection, the existing records in the merge from start option are displayed initially.
The left portion of the Contract Values collection initially displays existing contract values linked to the original start option. In the Merge Type, you will see the word Original, for any of these records. The Rate Factor, Number of Days and Value for each contract value is displayed. In the right portion of the collection, the existing records in the merge from start option are displayed initially.
The topics, which follow, describe how to perform common maintenance tasks:
Contents
Adding A New Row To A Start Option
Removing An Uncommitted Row From A Start Option
If you wish to remove a record linked to the Original start option, click the “-“ button to the left of the record.
You may move any of the records from the Merge From start option to the original start option by selecting the left arrow adjacent to the desired row. Once a record is moved it will disappear from the Merge From information and appear in the Original information with the word Merge in the Merge Type column.
The screen will redisplay with the characteristic moved to the left portion of the page.
If you have copied a row across by mistake, you may remove it by clicking on the right arrow adjacent to the appropriate record.
Refer to Editable Grid in the system wide standards documentation for more information about adding records to a collection by selecting from a list.
Open Admin Menu, Obligation Type Start Options Merge and navigate to the Characteristics and Quantities tab to copy rows in the characteristic and contract quantity collections.
Description of Page
The left portion of the Characteristics collection initially displays existing characteristics linked to the original start option. In the Merge Type, you will see the word Original, for any of these records. The Characteristic Type and Characteristic Value for each characteristic are displayed. In the right portion of the collection, the existing records in the merge from start option are displayed initially.
The left portion of the Contract Quantity collection initially displays existing contract quantities linked to the original start option. In the Merge Type, you will see the word Original, for any of these records. The Contract Quantity Type and Contract Quantity for each contract quantity are displayed. In the right portion of the collection, the existing records in the merge from start option are displayed initially.
Refer to Obligation Type Start Options Merge - Main for more information about how to perform common maintenance tasks for the grids displayed on this tab page.
Open Admin Menu, Obligation Type Start Options Merge and navigate to the Terms and Conditions tab to copy terms and conditions (T&Cs).
Description of Page
The left side of the Terms and Conditions grid initially displays the T&Cs linked to the original start option. On the right side, the T&Cs linked to the merge from start option are displayed initially.