This section describes control tables that are used throughout Oracle Enterprise Taxation Management.
Contents
Defining General Ledger Divisions
Defining Banks & Bank Accounts
The topics in this section describe the various installation options that control various aspects of the system that are specific to the Oracle Enterprise Taxation Management product.
Refer to Installation Options - Framework for options that are common to products on the same framework.
Contents
Installation Options - Account
Installation Options - Billing
Installation Options - Collections
Installation Options - Financial Transaction
Installation Options - Algorithms
Select Admin Menu, Installation Options and use the Main tab to define system-wide installation options.
Description of Page
Use Quick Add Tender Type to define the tender type defaulted on payments added using the Payment QuickAdd transaction.
Use Starting Balance Tender Type to define the tender type of the starting balance recorded on your tender controls (this will almost always be the tender type associated with "cash"). This value is used during tender control balancing as a separate balance is required for each tender type in order to balance a tender control. Refer to The Lifecycle Of A Tender Control for more information.
For more information, refer to Setting Up Tender Types.
Use the Location Geo Type to indicate whether at least one geographic identifier (e.g., GPS coordinate) is Required or Optional on a location. Refer to Defining Geographic Types for more information.
The Alternate Representation flag should be set to None unless your organization uses multiple character sets for a person’s main name and / or a location’s address. Alternate representations are typically only used in countries where multiple character sets are used. For example,
· In Hong Kong, a person’s name may be written in both Chinese characters and in English.
· In Japan, a person’s name may be written in both Kanji and Katakana.
In both of the above situations, users need to be able to use both representations to find a taxpayer or a location.
Alerts that should appear adjacent to a person’s name or address. If your organization doesn’t use multiple character sets, you might want to consider using this functionality to implement critical person or location alerts. For example, if you have a taxpayer who’s supported by a specific account representative, you could enter the account rep’s name as the person’s alternate name. If you do this, the account rep’s name would appear in parenthesis following the taxpayer’s name. In addition, you can search for the taxpayers supported by the account rep on Control Central by entering the account rep’s name.
If your organization uses alternate representations of person name or address, set this flag to one of the following values:
· Use a value of Address if you only use alternate representations for location addresses.
· Use a value of Name if you only use alternate representations for a person’s primary names.
· Use a value of Name & Address if you use alternate representations for both location addresses and person names.
The following points describe the ramifications of this flag in the system:
· If you support alternate representations of a person’s primary name,
· The name grid on Person - Main allows you to specify an Alternate name for the person.
· If you use the base package name formatting algorithm, a person’s name will be shown throughout most of the system in the format AAA (BBB), where AAA is the person’s primary name and BBB is the person’s alternate name. Note, this format does not apply to names that appear in search results (i.e., the alternate name is not concatenated to the main name in search results; however you can search for information using the alternate name).
· Most of the system’s person name-oriented searches will allow users to use both a person’s primary and alternate names to search for information.
· If you support alternate representations of a location’s address,
· A new tab is available on the Location page that allows a user to define an alternate address for a location.
· If you use the base package premise formatting algorithm, a location’s address will be shown throughout most of the system in the format AAA (BBB), where AAA is the location’s primary address and BBB is the location’s alternate address.
· Most of the system’s location-oriented searches will allow users to use both a location’s primary and alternate addresses to search for information.
Set the CTI Integration flag to Yes if your organization integrates with an external computer telephony integration (CTI) system that supports a "get next caller in the queue" function. If this flag is set to Yes, then Next Call button will appear in the action toolbar allowing customer service representatives to request the next taxpayer waiting in the queue to speak to a CSR.
Warning! In order to improve response times, installation options are cached the first time they are used after a web server is started. If you change this field's option and you don't want to wait for the cache to rebuild, you must clear the cached information so it will be immediately rebuilt using current information. Refer to Caching Overview for information on how to clear the system login cache (this is the cache in which installation options are stored).
Select Admin Menu, Installation Options and use the Person tab to define person-specific installation options.
Description of Page
Use the Person ID Usage to indicate whether or not at least one form of identification is Required or Optional when a new person is added.
Each form of identification has an identifier type. For persons that are humans (as defined by the person type's person/business identifier), the Person page defaults the identifier type defined in Identifier Type (Person). For persons that are businesses (as defined by the person type's person/business identifier), the Person page defaults the identifier type defined in Identifier Type (Business).
Select Admin Menu, Installation Options and use the Account tab to define account-specific installation options.
Description of Page
When a new account is added on the Account page, the system requires it have an account type. If the main taxpayer linked to the account is a human (as defined by the taxpayer’s person type), the system defaults the account type defined in Account Type (Person). For persons that are businesses (as defined by the person type), the system defaults the account type defined in Account Type (Business). For more information, refer to Setting Up Account Types.
In addition to requiring an account type when a new taxpayer is added, the system also requires a "main taxpayer" (i.e., a reference to a person who is identified as the main taxpayer for the account). Enter the default Account Relationship Type code to be used to define the main taxpayer relationship. For more information, refer to Setting Up Account Relationship Codes.
Enter the default Bill Route Type to be used to define how bills should be routed to a taxpayer. For more information, refer to Setting Up Bill Route Types.
Select Admin Menu, Installation Options and use the Billing tab to define billing-specific installation options.
Description of Page
The Bill Segment Freeze Option controls when an obligation’s balance and the general ledger are affected by bill segments and certain types of adjustments. Refer to Preventing Obligation Balances And The GL From Being Impacted Until Bill Completion to understand the significance of this option.
The Accounting Date Freeze Option controls how the accounting date defined on financial transactions is populated. Refer to Forcing The Freeze Date To Be Used As The Accounting Date to understand the significance of this option.
Define the Minimum Amount for Final Bill.If a final bill is less than this amount, the bill is still produced; it’s just not printed.
Typically, the system sets a bill’s Bill Date equal to the date on which it is completed. If you want to be able to specify a bill’s Bill Date when you complete a bill, turn on User Can Override Bill Date. You would only want to override the bill date if you are setting up sample bills from historical period whose bill date needs to reflect the respective historical period.
Select Admin Menu, Installation Options and use the Collections tab to define collections-specific installation options.
Description of Page
Enter what you consider to be an excellent compliance rating in Beginning Compliance Rating. Overdue events can cause an account’s compliance rating to decrease. When an account’s compliance rating falls below a certain level, different overdue processes may ensue.
Use Compliance Rating Threshold to define when an account’s compliance rating becomes risky. When an account’s compliance rating falls beneath the Compliance Rating Threshold, the system will show an alert in Control Central highlighting such.
Select Admin Menu, Installation Options and use the Financial Transaction tab to define financial transaction installation options.
Description of Page
Use G/L Batch Code to define the batch process that is used to interface your financial transactions to your general ledger. The process is snapped on FT download records by the GLS background process.
Use A/P Batch Code to define the batch process that is used to interface your check requests (initiated with adjustments with an adjustment type that reference an A/P request type) to you accounts payable system.
Use Fund Accounting to indicate if fund accounting is Practiced or Not Practiced at your organization. By default, the installation indicates that it is Practiced.
The following table describes each System Event.
|
System Event |
Optional / Required |
Description |
|
Account Information |
Optional |
We use the term "Account information" to describe the basic information that appears throughout the system to describe an account. The data that appears in "account information" is constructed using this algorithm. Plug an algorithm into this spot to override the system default "Account information". Click here to see the algorithm types available for this system event. |
|
Address Information |
Optional |
This algorithm allows your implementation to define a common format for displaying an address. It receives address constituents and returns a formatted address string. This plug-in spot may be invoked by other algorithms using the business service C1-FormatAddressInfo. Click here to see the algorithm types available for this system event. |
|
Adjustment Information |
Optional |
We use the term "Adjustment information" to describe the basic information that appears throughout the system to describe an adjustment. The data that appears in "Adjustment information" is constructed using this algorithm. Plug an algorithm into this spot to override the system default "Adjustment information". Note: This algorithm may be further overridden by an "Adjustment information" plug-in on the Adjustment Type. Refer to Adjustment Type for how algorithms of this type are used. Click here to see the algorithm types available for this system event. |
|
Automatic Payment Creation |
Required if you allow taxpayers to pay automatically |
This algorithm is executed to create automatic payments whenever the system creates automatic payments. Refer to How And When Are Automatic Payments Created for the details. Click here to see the algorithm types available for this system event. |
|
Bill Information |
Required |
We use the term "Bill information" to describe the basic information that appears throughout the system to describe a bill. The data that appears in "bill information" is constructed using this algorithm. Click here to see the algorithm types available for this system event. |
|
Case Information |
Optional |
We use the term "Case information" to describe the basic information that appears throughout the system to describe a case. The data that appears in "case information" is constructed using this algorithm. Plug an algorithm into this spot to override the system default "Case information". Note: This algorithm may be further overridden by a "Case information" plug-in on the Case Type. Refer to Case Type for how algorithms of this type are used. Click here to see the algorithm types available for this system event. |
|
Collection Agency Referral Information |
Optional |
We use the term "Collection Agency Referral information" to describe the basic information that appears throughout the system to describe a collection agency referral. Plug an algorithm into this spot to override the system default "collection agency referral information". Click here to see the algorithm types available for this system event. |
|
Compliance Rating "Created By" Information |
Required |
The data that appears in the compliance rating "created by" information is constructed using this algorithm. Refer to Account - Collections for more information about the compliance rating. Click here to see the algorithm types available for this system event. |
|
Compliance Rating History Information |
Optional |
We use the term Compliance Rating History information to describe the basic information that appears throughout the system to describe a compliance rating history entry. Plug an algorithm into this spot to override the system default "compliance rating history information". Click here to see the algorithm types available for this system event. |
|
Control Central Alert |
Optional |
There are two types of alerts that appear in the Alert Zone and on Payment Event – Main: 1) hard-coded system alerts and 2) alerts constructed by plug-in algorithms. You cannot change the hard-coded alerts (see the Alert Zone for the complete list). However, by plugging in this type of algorithm you can introduce additional alerts. An error displays if more than 60 alerts are generated for an account by plug-in algorithms. Click here to see the algorithm types available for this system event. |
|
Determine Open Item Bill Amounts |
Required if you use overdue functionality to collect on bills |
This algorithm is responsible for determining the unpaid amount of an open-item bill. It can also be used to return the unpaid amount for a specific Obligation on a bill. Click here to see the algorithm types available for this system event. |
|
Financial Transaction Info |
Optional |
We use the term "financial transaction information" to describe the basic information that appears throughout the system to describe a financial transaction. The data that appears in "financial transaction info" is constructed using this algorithm. Click here to see the algorithm types available for this system event. |
|
Location Information |
Required |
We use the term "location info" to describe the basic information that appears throughout the system to describe a location. The data that appears in "location info" is constructed using this algorithm. 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 system default "obligation information". Note: This algorithm may be further overridden by an "obligation information" plug-in on the obligation type. Refer to Obligation Type – Algorithms for how algorithms of this type are used. Click here to see the algorithm types available for this system event. |
|
Online Bill Display |
Optional |
This algorithm constructs a PDF that contains the image of a bill. This algorithm is executed when the Display Bill button is clicked on the Bill page. Refer to Technical Implementation of Online Bill Image for more information. Click here to see the algorithm types available for this system event. |
|
Online Letter Image |
Optional |
This algorithm constructs a PDF that contains the image of a letter. This algorithm is executed when the Display Letter button is pressed on Customer Contact - Main. Refer to Technical Implementation of Online Letter Image for more information. Click here to see the algorithm types available for this system event. |
|
Override Proration Factors |
Optional |
This algorithm is only used if your organization has unusual rate proration requirements that necessitate the overriding of the base package proration logic. For example, you may have certain rate components whose charges should never be prorated. Refer to Overriding Proration Factors for more information. Click here to see the algorithm types available for this system event. |
|
Override Seasonal Proration |
Optional |
This algorithm is only used if your organization has unusual method of determining the seasons for your rate components. For example, you may determine the seasonal boundaries for a rate component based on the scheduled meter read date associated with the bill cycle. Refer to the description of the seasonal attributes for a rate component for more information. Click here to see the algorithm types available for this system event. |
|
Payment Amount Calculation |
Required |
This algorithm is executed to calculate the amount of an automatic payment for a bill for an account with an active auto pay option. Refer to How And When Are Automatic Payments Created for more information on automatic payments. This algorithm is also executed to default the amount of a manually added payment. Refer to How To Add A New Payment Event for more information on adding a payment manually. Click here to see the algorithm types available for this system event. |
|
Payment Information |
Required |
We use the term "payment information" to describe the basic information that appears throughout the system to describe a payment. The data that appears in "payment information" is constructed using this algorithm. Click here to see the algorithm types available for this system event. |
|
Person Information |
Required |
In most parts of the system, a person’s Main name is displayed to describe a person. However, several transactions do not use this method. Rather, these transactions call the algorithm that’s plugged into this spot to construct the person’s name. Refer to the description of the Alternate Representation flag on the Main tab for a list of these transactions and for the rationale behind this algorithm. Click here to see the algorithm types available for this system event. |
|
Person Name Validation |
Required |
The format of names entered on Person - Main is validated using this algorithm. Click here to see the algorithm types available for this system event. |
As described under Defining Languages, you define the language in which each user sees the system. In addition to defining each user's language, the system allows you to define each taxpayer's preferred language. For example, one taxpayer can receive bills in English whereas another taxpayer could receive their bills in Chinese.
Each taxpayer's language is defined by the language code on their person record. Bills, adjustments and other system-generated records will then be done in the language of the main taxpayer of the account. In addition, the language code is passed on to all taxpayer-facing interfaces, such as letter requests and bill print.
Note. You can define Rates in multiple languages – when a bill is generated, the line-item descriptions are generated and stored in the account’s main taxpayer’s language of choice. Any one who subsequently views these bills can only see the descriptions in that language.
Note. To support bills and other correspondence, you must also provide translations of standard bill stock and letters. This must be handled by your printing software vendor.
The accounting calendar determines the accounting period to which a financial transaction will be booked. The following points describe how the system determines a financial transaction’s account period:
· Every financial transaction references an accounting date and its obligation
· Every obligation references an obligation type
· Every obligation type references a GL division
· Every GL division references an accounting calendar
· The accounting calendar contains the cross reference between the accounting date specified on the financial transaction and related accounting period in your general ledger
Warning! This information must be the same as the information in your financial database.
To add or review an accounting calendar, choose Admin Menu, Accounting Calendar.
Description of Page
Enter a unique Calendar ID and Description for the calendar.
Enter the Number Of Periods for the calendar. Don’t count the adjustment period, if you use one, or any special "system" periods.
Specify the Fiscal Year, each Accounting Period in that year, a Period Description, the Begin Date and the End Date.
When you enter begin and end dates, you can define monthly calendar periods or any fiscal period that matches your accounting calendar (weekly, bimonthly) as long as the begin and end dates of successive periods do not overlap.
For each fiscal period, enter the Open From Date and Open To Date. These dates define when that particular business dates are open for posting financial transactions to that fiscal period. For example, you might calculate a bill on Sept 1 for taxes reported on August 31. To post this financial transaction in the August period, you must keep it open through Sept 1.
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_CAL_GL
There are two types of divisions referenced in the system: a division and a GL division. This is a rather powerful structure, but it can be confusing.
· General Ledger divisions typically comprise individual entities (e.g., companies) in your general ledger. You must set up a GL division for each such entity. The GL division’s sole purpose in the system is to define the accounting period associated with financial transactions linked to obligations associated with the GL division (obligations are associated with GL divisions via their obligation type). The system cares about accounting periods in order to prevent a user from booking moneys to closed periods. It also uses accounting periods when it produces the flat file that contains the consolidated journal entry that is interfaced to your general ledger (refer to The GL Interface for more information).
Note. When determining how many GL Divisions you need, be sure to consider your general ledger and how your chart-of-accounts is structured. You will typically have one GL division for each "company" in your general ledger.
· A division is typically associated with a jurisdiction. The definition of a jurisdiction is a geographic-oriented entity with unique business rules. You must set up a division for each jurisdiction in which you conduct business.
Refer to Setting Up Divisions for information about divisions.
To define a general ledger division, select choose Admin Menu, General Ledger Division.
Description of Page
Enter a unique GL Division for the general ledger division.
Enter a Description of this general ledger division.
Define the accounting Calendar ID that controls how to convert an FT’s accounting date into an accounting period. Refer to Defining Accounting Calendars for more information.
You may define a Currency Code for the GL division. Note that the system does not use this currency code.
Follow this link to open the data dictionary where you can view the tables that reference CI_GL_DIVISION.
The topics in this section describe how to maintain your implementation's bank accounts.
To add or review Banks choose Admin Menu, Bank.
Description of Page
Enter a unique Bank Code and Description for the bank.
The Bank Accounts collection displays the bank accounts currently linked to this bank code. Use the drill down button to view more details or to modify the bank account details. Alternatively, you may navigate to the Bank Account tab and scroll to the desired bank account.
To add or review Bank Accounts for a Bank, choose Admin Menu, Bank and then navigate to the Bank Account tab.
Description of Page
Use the Bank Accounts tab to define the attributes of each bank account. For each account, enter the following information:
· Enter a Bank Account Key to identify an Account at a Bank. You may have more than one account at a given bank, and you may have accounts at more than one bank. This code will allow the system to easily identify a specific account.
· Enter a Description to appear on prompt lists, inquiries, and reports.
· Enter the Account Number, Check Digit and if needed, the Branch ID of the bank where the account is held.
· Enter the Currency Code for the currency in which the account is denominated.
· Use DFI ID to define the Depository Financial Institution ID that is interfaced to the automatic payment-processing agent as part of the automatic payment interface.
· Enter the Distribution Code to be used for cash GL distributions when a payment is frozen or canceled.
Where Used
Follow this link to open the data dictionary where you can view the tables that reference CI_BANK_ACCOUNT.
This section is an addendum to the general To Do Lists chapter. This addendum describes the To Do functionality that is specific to Oracle Enterprise Taxation Management.
Contents
As described in To Do Entries Reference A Role, each To Do entry requires a role. To Do entries created in Oracle Enterprise Taxation Management may attempt to assign a role based on an account management group or division if it is applicable to the type of data related to the To Do entry.
As described in The Big Picture of To Do Lists, users are informed that something requires their attention by entries that appear in a To Do List. For example, consider what happens when billing can’t find appraisal information for a property:
· The billing process creates a bill segment that is in error (appraisal information cannot be found).
· This bill segment that’s in error, in turn, triggers the creation of a To Do entry.
· The To Do entry is assigned a role. A role is one or more users who can look at / work on the entry.
· When users view a To Do List, they only see entries addressed to roles to which they belong.
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 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 Setting Up Account Management Groups for more information.
By assigning an AMG to an account, you are telling the system to address this account’s To Do list entries to the roles defined on the AMG (note, each To Do type can have a different role defined for it on an AMG).
You can optionally use division to define the respective role to be assigned to To Do entries that are associated with an account and To Do type. Refer to Setting Up Divisions for more information.
A To Do Pre-Creation installation options plug-in is provided to determine the appropriate To Do Role for an account based on AMG and division setup. If plugged in, the logic to determine To Do role for an account is performed whenever a To Do entry is created. Refer to C1-TDCR-DFRL for further details on how this plug-in works.
Refer to To Do Entries Reference A Role for the details of how an initial role is assigned to To Do entries.
List of available To Do types. The To Do types available with the product may be viewed in the application viewer's To Do type viewer. In addition if your implementation adds To Do types, you may regenerate the application viewer to see your additions reflected there.