Defining Taxpayer Options
The definition of a taxpayer is someone (or something) with financial obligations with your tax authority. Within the documentation, the terms “taxpayer” and “customer” may be used interchangeably.
The system subdivides taxpayer information into the following records:
· Person. The person record holds demographic information about your taxpayers and every other individual or business with which your tax authority has contact. For example, in addition to normal registered taxpayers, person records may include contacts, accountants, related parties, mortgage brokers, related businesses in a corporate structure, overseas entities, persons of interest, and so on.
· Account. Accounts are the entities for which bills are produced and therefore you must create at least one account for every person who has financial obligations with your company. The account record contains information that controls when the bills are created and how the bills are formatted.
· Tax Role. A tax role is used to define an instance of a specific tax type for a specific account. It includes information that is specific to the tax type for the account, for example, the dates that the tax is applicable for the account and the filing calendar that defines the filing frequency.
· Obligation. An obligation is a contract between the tax authority and the taxpayer. For example, an obligation may represent a specific filing period where a taxpayer is expected to file a return for a given tax type. An obligation may represent an ongoing charge such as a tax preparer fee. An obligation may be used to hold miscellaneous financial information such as an excess credit to later be applied to unpaid tax or debt from a third party source.
Before you can define persons, accounts, tax roles and obligations, you must set up the control tables defined in this section.
Note. In this section, we limit the discussion to tables that control basic demographic and financial information about your taxpayers. Other sections describe the tables that control other taxpayer related functions like forms processing, penalty and interest and collections.
Setting Up Customer Contact Options
This section describes how the person, account, and obligation records are used to record your taxpayers’ demographic and billing options.
A Simple Example Of Joint Taxpayers
A Simple Example Of Joint Taxpayers
The following picture illustrates two joint taxpayers: Joe Smith and Pam Jones Smith. Joe and Pam are the "main taxpayers" on their own Income Tax Accounts with their own obligations for tax years 2001, 2002, and 2003. Joe and Pam get married and file a joint tax return for tax year 2004. A new account is established for their 2004 obligation. They are both financially responsible for tax year 2004 while they each remain responsible for their prior tax years. Joe and Pam are each linked to two accounts for tax years 2001-2003 and to the new joint account.
Persons
Person records hold demographic information about the individuals and businesses with whom your organization communicates. Demographic information includes phone number(s), names and aliases, identification numbers, employment information, etc.
In the above example, 2 person records would be needed, one for Pam Jones and another for Joe Smith.
A new person is added when you first have contact with a person; the person does not have to be a taxpayer before he or she is added. For example:
· If John Doe is the main contact for XYZ Corporation, John might not live in the taxing jurisdiction. You can add John as a new person and link him to any of the XYZ Corporation accounts as a contact (but not financially responsible).
· In situations with non-filers and investigations, you can add a new person and associate it with the case. If the tax authority thinks that ZZZ Corporation is operating as a business but not registered and paying taxes, the tax authority may create a person record at the beginning of the investigation to send correspondence.
Businesses are persons too. In addition to humans, you use person records to maintain basic information about the businesses with which your organization has contact.
For a description of the control tables that must be set up before you can define a person, refer to Setting Up Person Options.
Accounts
The system allows for a taxpayer to define one account for multiple types of taxes. For example, a corporation may have a single account for the corporate income tax, sales and use tax, withholding tax, various excise taxes, etc.
Alternatively separate accounts may be used for each type of tax.
Account / Person Cross Reference
Account ID Is Non-Intelligent
The unique number of an account is referred to as the “account ID”. You are probably very comfortable with this concept. You may, however, have difficulty dealing with the fact that the account id in this system has no intelligence built into it (e.g., many systems include the bill cycle and geographic location in the account id). In this system, the account ID is a random, system-assigned value.
Because the account ID contains no meaning, it can remain with a taxpayer for life, regardless of where they live, when they are billed, the type of service they receive, etc. This is important because it means that all of the financial history linked to the account remains with the taxpayer for life.
Technical note. The non-intelligence of the account ID is also important from the perspective of the parallel processing that takes place when the system creates bills. Because the collection of accounts to be billed in any given bill cycle will be randomly distributed through the number spectrum, the system can distribute account number ranges to parallel threads and each thread will process roughly the same number of accounts.
Account / Person Cross Reference
A person may be linked to zero or more accounts. A person won’t be linked to an account when they have no financial relationship with your organization. A person will be linked to multiple accounts when they have financial relationships with more than one account.
An account must reference at least one person (i.e., the main taxpayer), but may reference an unlimited number of individuals. Multiple persons are linked to an account when several parties have some type of financial relationship with the account (e.g., third party guarantors, account contact, bill copy recipients, etc.).
When Is An Account Created?
There a several instances when accounts must be created in the system. An account is created when:
· The taxpayer is registered for a tax obligation, or has any financial interactions with the tax authority.
· The taxpayer is registered for a new tax type. The account is created to track the obligations of the taxpayer to file or pay taxes.
· An estimated payment is received from a taxpayer for a tax that is not yet registered. The account must be created to hold the estimated payment.
· A non-filer is identified, and the tax authority decides to send a default tax assessment or penalty.
When Is An Account Expired?
Accounts never expire. Once a taxpayer has an account, the account remains in the system forever. Linked to the account are obligation records that define a taxpayer's obligation to file a tax return, and/or make a payment to the tax authority. When an account has obligations, the system pursues unpaid and overdue debt, refunds credits overdue to the taxpayer, and pursues obligations to file returns that have not been fulfilled. If the account doesn’t have active obligations, the system will not produce a bill for it. You can think of an account without active obligations as being “dormant”, waiting for the day when the taxpayer again files a tax return. If the taxpayer never re-files, the account (along with its financial history) remains dormant forever.
Tax Roles
Tax Roles represent the ongoing obligations of a given tax type within an account at a given point in time. It may be also be thought of as the reason a taxpayer must interact with the tax authority, or one of the taxpayer’s relationships with the tax authority.
Tax roles include the dates that the tax is effective. If you consider a business, some tax types are required for the entire time a company is in business, such as corporate income tax. Other tax types may only be in effect if the company is engaging in certain activities, which may change over time.
Contents
Filing Calendars for Filing Tax Types
When Is A Tax Role Created?
Most tax roles are created when the tax authority is aware that a tax type is applicable for an account. For example, when a business taxpayer registers their business and indicates the various tax types that are applicable or when an individual taxpayer files a tax form.
Filing Calendars for Filing Tax Types
For tax types that are filing period based, the onus is on the taxpayer to file the return and pay the appropriate assessment on time. The tax type typically defines the valid filing calendar(s) that govern the frequency of filing and the dates to file for each filing period. For some tax types a single calendar is valid for all tax roles of that tax type. For other tax types, one or more different filing frequencies (and therefore filing calendars) may be applicable and may change over the life of the tax role for an account.
Obligations
An obligation is a contract (either formal or implied) between the tax authority and a taxpayer. An obligation is linked to an account. There is no limit to the number of obligations that may be linked to an account.
When Is An Obligation Created?
Due Dates for Filing Period Based Obligations
Financial Transactions Are Linked To Obligations
When Is An Obligation Created?
For some tax types there is an ongoing obligation to file, such as sales tax. For obligations related to these types of taxes, it may be beneficial to include logic to create future obligations based on the start date, end date, and frequency of the obligation.
For other tax types, such as individual income taxes and excise taxes, obligation records may be created when the tax authority receives a tax return.
Due Dates for Filing Period Based Obligations
For tax types that are filing period based, the onus is on the taxpayer to file the return and pay the appropriate assessment on time. This section describes the configuration provided for defining and determining due dates.
When should the taxpayer file the return for a given filing period? When defining filing periods for a filing calendar you also define the statutory Due Date of the return along with the Grace Date. For taxpayers that request an extension to their filing date, an Override Filing Due Date may be defined on the specific obligation.
Typically the statutory payment due date for a filing period is the same date as the statutory filing due date. However, the dates may be extended independently. Extensions to a payment date are also defined on a specific obligation using the Override Payment Due Date. Also note that the grace date for the payment due date is calculated differently. Instead of using the explicit Grace Date on the filing calendar, the obligation type defines a Payment Grace Days. The logic in the base algorithms that determine if a payment is made on time (whether it be for the statutory due date or the override payment due date) considers the grace days in its calculations.
Financial Transactions Are Linked To Obligations
For more information about how financial transactions are linked to obligations, refer to The Financial Big Picture.
This section describes tables that must be set up before you can define persons.
Defining Person Relationship Types
Defining Identifier Types
When you set up a person, you may define the various types of identification associated with the person, e.g., their driver’s license number, their tax identity, etc. Every piece of identification associated with a person has an identification type. These identifier type codes are defined using Admin Menu, Identifier Type.
How are person identifiers used? The reason why identifiers are defined on a person is so that users you can look for a taxpayer using one of their person identifiers (see Control Central - Search Facilities for more information). In addition, person identifiers help prevent duplicate persons from being added to the database. This is because the system warns a user before they add a new person when a person exists with the same identifier.
Person identifier types are optional. An installation option controls whether at least one identifier type is required on every person.
Description of Page
Enter an easily recognizable ID Type and Description for the Identifier Type.
If the identifier type has a format against which validation can be performed, use Identifier Format to define the algorithm. To do this:
· Create a new algorithm (refer to Setting Up Algorithms).
· On this algorithm, reference an Algorithm Type that validates identifier types. Click here to see the algorithm types available for this plug-in spot.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_ID_TYPE.
Defining Person Relationship Types
It is possible to associate persons to other person. For example,
· You might want to define the subsidiaries of a parent corporation
· You might want to define spouses as separate persons and then link each person to another person
When you link a person to another person, you must define in what way the person is related to the other person by using a person relationship type code. These codes are defined using Admin Menu, Person Relationship Type.
Description of Page
Enter the following for each relationship type:
· Enter an easily recognizable Relationship Type code.
· Use Description (Person1=>Person2) to describe how the first person is related to the second person.
· Use Description (Person2=>Person1) to describe how the second person is related to the first person.
Person1 versus Person 2. When you link persons together, you do it in respect of one of the persons (which we call Person 1). For example, if you want to link the subsidiaries to a parent company, you do this in respect of the parent company (i.e., you define the parent company’s subsidiaries using the Person - Persons transaction.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_PER_REL_TYPE.
Defining Person Types
A person exists for every individual or business with which your tax authority has contact. Besides individual and business taxpayers, persons exist for contractors, accountants at corporate taxpayers, third party guarantors, collection agencies, etc.
The person type is used to define business rules for different types of persons. For example, for a business that is a limited liability partnership, you may wish to require that multiple individual partners be linked to the partnership.
A person type is governed by a business object. The base product provides business objects that you may use or extend. Refer to the BO definitions in the application. Or you may create your own.
Open Admin Menu, Person Type to define the person types used to categorize your persons.
The topics in this section describe the base-package zones that appear on the person type portal.
Contents
Person Type List
The Person Type List zone lists every person type. The following functions are available:
· Click the broadcast icon to open other zones that contain more information about the adjacent person type.
· The standard actions of Edit, Duplicate and Delete are available for each person type.
Click the Add link in the zone's title bar to add a new person type.
Person Type Actions
This is a standard actions zone. The Edit, Delete and Duplicate actions are available.
Person Type
The Person Type zone contains display-only information about a person type. This zone appears when a person type has been broadcast from the Person Type List zone or if this portal is opened via a drill down from another page.
Please see the zone's help text for information about this zone's fields.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_PER_TYPE.
This section describes tables that must be set up before an account can receive a bill.
Contents
Setting Up Account Management Groups
Setting Up Account Relationship Codes
Setting Up Account Management Groups
Users are informed that something requires their attention by entries that appear in To Do lists. For example, consider what happens when:
· A tax return fails validation for a math error.
· A tax return meets the business rule criteria to trigger a desk audit.
· A taxpayer refund exceeds the business rule review thresholds.
· A letter to a taxpayer is in error because the taxpayer does not have an address record.
You can optionally use account management groups (AMG) to define the respective role to be assigned to To Do entries that are associated with an account and a given To Do type. For example, you can create an AMG called Credit Risks and assign this to accounts with suspect credit. Then, whenever an account-oriented To Do entry is created for such an account, it will be assigned a role based on the Credit Risks AMG. Refer to Assigning A To Do Role for more information.
Account management groups are optional. You need only set up account management groups (and link them to accounts) if you wish to address specific To Do entries associated with specific accounts to specific roles.
Account management groups are defined using Admin Menu, Account Management Group.
Description of Page
Enter an easily recognizable Account Management Group code and Description for each account management group. Use the grid to define the ToDo Role to be assigned to entries of a given To Do Type that are associated with accounts that reference the Account Management Group.
Note. Only To Do entries that are account-oriented take advantage of the roles defined for an account management group (because only accounts reference an account management group).
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_ACCT_MGMT_GR.
Setting Up Account Relationship Codes
When you link a person to an account, you must define in what way the person is related to the account by using an account relationship code. These codes are defined using Admin Menu, Account Relationship Type.
Description of Page
Enter an easily recognizable Relationship Type and Description for each relationship type.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_ACCT_REL_TYP.
Setting Up Alert Types
Account based alerts that appear in control central have an Alert Type. To define valid alert types, navigate to Admin Menu, Alert Type.
Description of Page
Enter an easily recognizable Alert Type code and Description for each alert type. Specify the Alert Days to indicate the amount of time that alerts of this type will be effective by default. Specify a value of zero to indicate that alerts of this type will be effective indefinitely by default.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_ALERT_TYPE.
Setting Up Bill Messages
There are various informational and warning messages that may appear on an account’s bills. Each message is identified with a bill message code. To define a bill message code, open Admin Menu, Bill Message.
Description of Page
Enter a unique Message Code and Description for every bill message.
The following attributes control how and where the bill message appears on the taxpayer’s bill:
Priority controls the order in which the message appears when multiple messages appear on a bill.
Note. The values for this field are customizable using the Lookup table. This field name is MSG_PRIORITY_FLG.
Insert Code controls whether a document should be inserted into the bill envelope when the bill message appears on a bill.
Message on Bill is the actual verbiage that appears on the taxpayer’s bill. If the message text is not static (e.g., field values need to be substituted into the body of the message), you can use the %n notation within the Message on Bill to cause field values to be substituted into a message. Refer to Substituting Field Values Into A Bill Message for more information.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_BILL_MSG.
Setting Up Bill Route Types
Bill route types define the method used to route bills to accounts. To define a bill route type, open Admin Menu, Bill Route Type.
Description of Page
Enter a unique Bill Route Type and Description for every bill route type.
Bill Routing Method controls the type of information that may be defined when the respective Bill Route Type is selected on Account - Person Information. The following options are available:
· Postal. Use this method if the routing is via the postal service.
· Fax. Use this method if the routing is via fax.
· Email. Use this method if the routing is via email.
Note. The values for Bill Routing Method are customizable using the Lookup table. This field name is BILL_RTG_METH_FLG.
The next two fields control how bills that are routed using this method are printed (both in batch and online).
· Use Batch Control to define the background process that performs the actual download of the billing information. Refer to Technical Implementation of Printing Bills In Batch for more information about these processes.
· Use Extract Algorithm to define the algorithm that constructs the records that contain the information that appears on a printed bill. Refer to Printing Bills for more information.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_BILL_RT_TYPE.
Setting Up Bill Cycles
Refer to Defining Bill Cycles for a description of how to set up bill cycles.
Setting Up Account Types
When you set up an account, you must assign it an account type. The topics in this section describe the account type control table.
Contents
Account Type - Main
To set up account types, navigate to Admin Menu, Account Type - Main.
Description of Page
Enter a unique Account Type code and Description for every account type.
Use Collection Class to define the collection class that defaults onto new accounts that belong to this account type. An account’s collection class may be subsequently modified if the account has special collection problems or needs.
Use an Account Business Object to define a BO that may govern additional rules related to accounts of this type.
Turn on Business Activity Required if obligations linked to accounts with this account type require a Business Activity description to be entered.
Turn on Open Item Accounting if accounts belonging to this account type are subject to open-item account. Refer to Open Item Accounting for a complete explanation of the significance of this switch.
Turn on Non Tax Agency Payment if accounts belonging to this account type are used for payments made to reduce non-tax authority debt. For example, if your tax authority sends collection notices or offsets taxpayer refunds on behalf of other agencies, such as child support, college tuition, or parking violations, you should set up the following information to accept such payments:
Create a new account type called “Non Tax Authority Customer”.
· Create an obligation type for each type of non-tax authority payment that taxpayers can make. Make sure to enter a distribution code on each obligation type that references the appropriate revenue (or payable) account. Don’t forget to indicate that each obligation type is not billed.
· Create an account to which you’ll book such payments. Have this account reference the new account type. We recommend creating a separate account for each obligation type that you created in the previous step.
· Create and activate an obligation for the new account(s).
When someone pays for non-tax authority debt, the operator will add a payment for the above account. On the payment, the operator should record reference information in order to know exactly why the payment was made. Refer to Payment Event - Main for more information.
You must define a variety of business rules for every division in which an account type has taxpayers. You do this on the Account Type - Controls page. The grid that follows simply shows the divisions for which business rules have been set up.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CUST_CL.
Account Type - Bill Messages
When an account type has bill messages, the system will sweep these messages onto bills created for accounts belonging to the account type. Use this page to define an account type’s bill messages. Navigate to Admin Menu, Account Type, Bill Messages tab to maintain this information.
Description of Page
Use the bill messagescollection to define Bill Message codes that should appear on bills that created for accounts that belong to a given account type. For each message, also specify the Start Date and End Date when such a message should appear on the bill (leave End Date blank if the message should appear indefinitely).
Where Used
The system snaps account type bill messages on a bill during bill completion. For more information about bill messages, refer to The Source Of Bill Messages.
Account Type - Controls
You must define a variety of business rules for every division in which an account type has taxpayers. Open Admin Menu, Account Type, Controls tab to maintain this information.
Description of Page
The Account Type Controls scroll contains business rules governing accounts that belong to a Division and Account Type. The following fields should be defined for each Division:
· Use Days Till Bill Due to define the number of days after the bill freeze date that the taxpayer’s bill is due. If the due date is a weekend or company holiday, the system will move the due date forward to the next workday (using the workday calendar defined on the account’s division).
The grid that follows 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 (see the table that follows for a description of all possible events).
· 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 system processes. The absence of an algorithm may prevent the system from operating correctly.
You can define algorithms for the following System Events:
|
System Event |
Optional / Required |
Description |
|
Autopay Amount Over Limit |
Optional |
This algorithm is called to handle the situation when a system-initiated automatic payment is created that exceeds the taxpayer’s maximum withdrawal limit. Specifically, this algorithm is called when: - The account has a maximum withdrawal limit on their automatic payment options - The system attempts to create an automatic payment that exceeds this amount - The automatic payment algorithm that’s plugged into the installation record has logic that invokes this algorithm when the above conditions are true If you do not plug-in this type of algorithm and the above situation is detected, the automatic payment will be created and no error will be issued. Refer to How To Implement Maximum Withdrawal Limits for more information. Click here to see the algorithm types available for this system event. |
|
Bill Cancel |
Optional |
This algorithm provides the ability to include additional cancel logic when canceling online. Algorithms of this type can be called in two modes: D (Determine Bill Page Buttons) and X (Cancel Bill). Mode 'D' governs whether an action button to cancel the bill will appear on the Bill page and mode 'X' performs the actual cancellation logic. Click here to see the algorithm types available for this system event. |
|
Bill Completion |
Optional |
When a bill for an account is completed, bill completion algorithms are called to do additional work. Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process. Click here to see the algorithm types available for this system event. |
|
Bill Eligibility |
Optional |
Algorithms for this plug-in spot are called when generating a bill in batch billing. It provides the ability to determine if an account is ineligible for billing and should therefore be skipped from further processing. If an eligibility algorithm is not used, a bill is created for any account in the open bill cycle and is later deleted by the billing process if it detects that there in no information linked to the bill. Click here to see the algorithm types available for this system event. |
|
Bill Segment Freeze / Cancel |
Optional |
When a bill segment for an account in this account type / division is frozen or canceled, an algorithm of this type may be called to do additional work. Refer to Bill Segment Lifecycle for more information about freezing and canceling bill segments. Click here to see the algorithm types available for this system event. |
|
FT Freeze |
Optional |
When an FT is frozen, this algorithm is called to do additional work. For example, if you practice Open Item Accounting, you will need such an algorithm to handle the cancellation of match events when a financial transaction is canceled that appears on a match event. Refer to How Are Match Events Cancelled? for more information about cancellation. Click here to see the algorithm types available for this system event. |
|
Levy an NSF Charge |
Optional |
This algorithm is called when a payment is canceled with a cancellation reason that indicates an NSF. Refer to NSF Cancellations for more information about what happens when a payment is canceled due to non-sufficient funds. Only One Algorithm. Only one algorithm to levy an NSF charge may be defined for an account type / division combination. Click here to see the algorithm types available for this system event. |
|
Overpayment Distribution |
Required |
When a taxpayer pays more than they owe, this algorithm is called to determine what to do with the excess funds. Refer to Overpayment Obligations for a description on how to configure the system to handle your overpayment requirements. Only One Algorithm. Only one overpayment distribution algorithm may be defined for an account type / division combination. Click here to see the algorithm types available for this system event. |
|
Override Due Date |
Optional |
An account’s bill due date will be equal to the bill date plus its account type’s Days Till Due. If you need to override this method for accounts in a specific account type, specify the appropriate algorithm here. Only One Algorithm. Only one due date override algorithm may be defined for an account type / division combination. Click here to see the algorithm types available for this system event. |
|
Payment Cancellation |
Optional |
Algorithms of this type are called when a payment is canceled. Click here to see the algorithm types available for this system event. |
|
Payment Distribution |
Required |
This algorithm is called to distribute a payment amongst an account’s obligations. Refer to Payment Distribution for more information about how payment distribution works. Only One Algorithm. Only one payment distribution algorithm may be defined for an account type / division combination. Click here to see the algorithm types available for this system event. |
|
Payment Freeze |
Optional |
When a payment is frozen, this algorithm is called to do additional work. If you practice Open Item Accounting, you will need such an algorithm to link the payment’s financial transactions to the match event that was originally created when the payment was distributed. Refer to Payments and Match Events for more information. Click here to see the algorithm types available for this system event. |
|
Post Bill Completion |
Optional |
When an account type has algorithms of this type, they are called after the completion of a bill for an account linked to this account type. Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process. Click here to see the algorithm types available for this system event. |
|
Pre Bill Completion |
Optional |
When an account type has algorithms of this type, they are called immediately before completion starts for an account linked to this account type. These algorithms have the potential of: · Deleting a bill. You might want a pre completion algorithm to delete a bill if a condition is detected that should inhibit the sending of a bill to a taxpayer (e.g., the bill just contains information about recent payments). · Aborting the completion process and creating a bill exception. If the algorithm indicates this should be done, the bill is left in the pending state and a bill exception is created describing why completion was aborted. You might want a pre completion algorithm to do this if, for example, integrity checks detect there is something wrong with the account or its obligations. If the integrity check fails, the bill can be left in the pending state and a bill exception created describing why. Refer to the description of the Complete button under Bill Lifecycle for a description of when this algorithm is called during the completion process. Click here to see the algorithm types available for this system event. |
Setting Up Collection Classes
Refer to Setting Up Collection Classes for a description of how to set up collection classes.
This section describes tables that must be set up before you can define customer contacts.
Refer to The Big Picture Of Customer Contacts for more information about taxpayer (customer) contacts.
Contents
Setting Up Customer Contact Classes
Setting Up Customer Contact Types
Setting Up Letter Templates
You can set up a customer contact type to generate a form letter whenever a customer contact of this type is added. In fact, this is the only way to generate a letter in the system.
Refer to Printing Letters for more information about how letters are produced.
Every customer contact that causes a letter to be sent must reference a unique letter template. To define a letter template, open Admin Menu, Letter Template.
Description of Page
The following fields are required for each letter template:
· Letter Template is the unique identifier of the letter template.
· Use Description to enter a brief description of the letter.
· Use a Customer Contact Business Object to define a BO that may govern additional rules related to customer contacts of this type.
· Turn on Special Extract if this type of letter should only be created via a system generated event such as a collection letter. Turning on this switch is what prevents a user from adding a customer contact that references this type of letter template (because you don’t want a user to be able to request a letter associated with a system generate event by adding a customer contact, rather, they must execute the appropriate process and it will generate the customer contact).
· The next two fields control how letters of this type are printed (both in batch and online). Refer to Technical Implementation Of Batch Letter Production for more information about producing letters in batch. Refer to Technical Implementation Of Online Letter Production for more information about online letter production.
· Use Batch Control to define the process that creates the flat file that is passed to your letter printing software. If you use an Extract Algorithm to construct the downloaded information, you can use the LTRPRT process.
· Use Extract Algorithm to define the plug-in component that constructs the “flat file records” that contain the information to be merged onto letters of this type. This algorithm is called when a user requests an online image of a letter on Customer Contact - Main and it may also be called by the batch letter extraction process defined above. Click here to see the algorithm types available for this plug-in spot.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_LETTER_TMPL.
Setting Up Customer Contact Classes
Every customer contact record has a contact type that classifies the record for reporting purposes. And every contact type, in turn, references a customer contact “class”. The class categorizes customer contacts into larger groupings for reporting purposes.
Open Admin Menu, Customer Contact Class to define your customer contact classes.
Description of Page
Enter a unique Contact Class and Description for each customer contact class.
After you have created your customer contact classes, you’ll be ready to setup your customer contact types.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CC_CL.
Setting Up Customer Contact Types
Every customer contact record has a contact type that controls the behavior of the customer contact.
Refer to The Big Picture Of Customer Contacts for more information about customer contacts.
Open Admin Menu, Customer Contact Type to define your customer contact types.
Description of Page
Every customer contact type is identified by a unique combination of Contact Class and Contact Type.
Enter a brief Description of the customer contact type.
Only specify a Contact Shorthand if customer contacts of this type can be added in the Customer Contact Zone. The value you specify in this field is what the user selects to add a customer contact in this zone.
Use Contact Action if something should be triggered when customer contacts of this type are added. The only valid value in this release is Send Letter. If you select this option, you must also specify a Letter Template. Refer to Printing Letters for more information about how letters are produced.
Use the Customer Contact Type Characteristics collection to define characteristics that can be defined for contacts of a given type. Use Sequence to control the order in which characteristics are defaulted. Turn on the Required switch if the Characteristic Type must be defined on customer contacts of a given type. Turn on the Default switch to default the Characteristic Type when customer contacts of the given type are created. Enter a Characteristic Value to use as the default for a given Characteristic Type when the Default switch is turned on.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CC_TYPE.
Filing calendars are used to define the expected filing period dates for a given type of obligation. The valid filing calendar that governs an obligation's filing period is typically defined on the obligation's Tax Role or its Tax Type.
To set up a filing calendar and its filing periods, open Admin Menu, Filing Calendar.
Description of Page
Enter a unique Filing Calendar and Description for the calendar.
Use Calendar Type to categorize your calendar. For example, you may use calendar type to define the frequency like Monthly or Quarterly. You may also choose to use calendar type to distinguish special calendars like fiscal calendars. No base values are provided for this field.
Note. Define values for this field using the Lookup table. This field name is FILING_CAL_TYPE_FLG.
Specify the Begin Date, End Date, Due Date and Grace Date for each filing period. Refer to Due Dates for Filing Period Based Obligations for more information about due dates.
As time passes, you will need to return to this transaction to manually enter ensuing years. You can enter several years at a time or incorporate the task into end-of-year system maintenance.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_FILING_CAL.
The tax type is used to defined business rules for each type of tax you support. Tax type is required when defining any financial obligation so a catchall tax type of Other for write-offs, payment plans and other miscellaneous uses may be warranted.
A tax type is governed by a business object. The base product provides business objects that you may use or extend. Refer to the BO definitions in the application. Or you may create your own.
Open Admin Menu, Tax Type to define the tax types used to define information about the tax types you support.
The topics in this section describe the base-package zones that appear on the tax type portal.
Contents
Tax Type List
The Tax Type List zone lists every tax type. The following functions are available:
· Click the broadcast icon to open other zones that contain more information about the adjacent tax type.
· The standard actions of Edit, Duplicate and Delete are available for each tax type.
Click the Add link in the zone's title bar to add a new tax type.
Tax Type Actions
This is a standard actions zone. The Edit, Delete and Duplicate actions are available.
Tax Type
The Tax Type zone contains display-only information about a tax type. This zone appears when a tax type has been broadcast from the Tax Type List zone or if this portal is opened via a drill down from another page.
Please see the zone's help text for information about this zone's fields.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_SVC_TYPE.
This section describes tables that must be set up before you can define obligations.
Contents
Setting Up Contract Quantity Types
Obligation Type Controls Everything
Setting Up Industry Codes
An obligation can reference an industry code. This code is used to categorize obligations for reporting purposes. To define an industry code, open Admin Menu, Industry Code.
Description of Page
Enter a unique Industry Code and Description.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_SIC.
Setting Up Tax Exempt Types
Your rates will probably have provisions for the calculation of taxes of one type or another. Frequently you will have customers who are completely or partially exempt from these taxes. The obligations for these customers will need to have tax exemption information in order for them to be billed properly. Tax Exempt Type is used to define the precise nature of the applicable exemption. To define the Tax Exempt Types you will use, open Admin Menu, Tax Exempt Type.
Description of Page
Enter a unique Tax Exempt Type and Description for each type of tax exemption.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_TAX_EX_TYPE.
Setting Up Contract Quantity Types
You may have customers whose contracts (obligations) have contractual limits. For example, a vehicle tax account may have special considerations or limits on the amount it can be billed, such as vehicles for government agencies or diplomats. The obligations for these customers must have information regarding this quantity in order to be billed properly. Contract Quantity Type is used to precisely define the nature of the quantity. To define the Contract Quantity Types, open Admin Menu, Contract Quantity Type.
Description of Page
Enter a unique Contract Quantity Type and Description for each type of contract quantity.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_CONT_QTY_TYP.
Obligation Type Controls Everything
Every obligation references an obligation type. The obligation type controls all aspects of an obligation's behavior including how bills are created, how its financial transactions are booked in the general ledger, and much more. We don’t explain how to set up obligation types in this section because it’s only after you have set up all of the control tables in this manual that you’ll be able to finally define your obligation types.
For more information about obligation types, refer to Defining Obligation Types.
Financial Controls
There are also a number of control tables that must be set up to control the bills, payments, and adjustments that are linked to an obligation. For more information about these tables, please refer to Defining Financial Transaction Options.