To implement the system, you must set up your organization's business rules in "control tables". Setting up these tables is time-consuming because we allow you to tailor many aspects of the system to meet your organization's requirements. We strongly recommend that you take the time to document how you plan to set up all of these tables before you use the following roadmap to enter the control data. Time spent understanding the interrelationships between this data will reap the rewards of a clean system that meets your current and long term needs.
While we describe the transactions and options in more detail in other sections of this manual, use the following chart (and the remaining sections of this chapter) as your roadmap. Here we list the order in which you perform tasks and the pages you'll use to set up your system. The order is important because some information must exist before other information can be defined (i.e., many dependencies exist).
Function |
Menu |
Auto Setup |
---|---|---|
Global Context |
||
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that populates global context values. The global context is used by various zones in the system to display relevant data. This algorithm is plugged-in on the installation record. |
|
Accounting Related Tables |
||
Country & State |
Admin, Country |
|
Currency Codes |
Admin, Currency Code |
USD is automatically populated |
Accounting Calendar |
Admin, Accounting Calendar |
|
GL Division |
Admin, General Ledger Division |
|
Security Related Tables |
||
Application Service |
Admin, Application Service |
All base package transactions are automatically populated |
Security Type |
Admin, Security Type |
|
User Group |
Admin, User Group Note, you won't be able to set up users at this point |
One user group, ALL-SERVICES, is automatically set up. It references all other application services and a single user called SYSUSER. |
Language |
Admin, Language |
ENG is automatically populated |
Display Profile |
Admin, Display Profile |
Two display profiles are automatically set up: NORTHAM displays currencies and dates in a classic American format; EURO displays information in a classic European format |
Data Access Role |
Admin, Data Access Role |
CI_DFLT is automatically populated. It references a single user called SYSUSER and a single access group called CI_ACCGRP |
Access Group |
Admin, Access Group |
CI_ACCGRP is automatically populated. It references the data access role CI_DFLT |
User |
Admin, User |
SYSUSER is automatically set up. |
Return to User Group |
You must return to your user groups and define all of their users |
|
Account Type Related Tables |
||
Account Type |
Admin, Account Type. At this point, you'll only be able to set up your account type codes. You will return to these account types throughout the setup process to populate additional information. |
|
Financial Transaction Related Tables |
||
Work Calendar |
Admin, Work Calendar |
|
Division |
Admin, Division |
|
Revenue Class |
Admin, Revenue Class |
|
Algorithm |
Admin, Algorithm. You will need to set up the algorithm that constructs a distribution code's corresponding GL account when it is interfaced to the general ledger |
|
Distribution Code |
Admin, Distribution Code |
|
Bank & Bank Accounts |
Admin, Bank |
|
Algorithm |
Admin, Algorithm. You will need to set up the algorithm that constructs a payment segment's financial transaction |
|
Payment Segment Type |
Admin, Payment Segment Type |
|
Algorithm |
Admin, Algorithm. You will need to set up the algorithm that constructs an adjustment's financial transaction |
|
Payment event distribution related control tables need to be set up if your organization uses the distribution rules method to create payment events. Refer to Setting Up The System To Use Distribution Rules for a description of the tables that must be set up to enable this functionality. |
||
Algorithm |
Admin, Algorithm. Several plug-in spots are available to perform additional logic when processing adjustments. For example, if you have the system calculate adjustments, you must set up an adjustment generation algorithm. Refer to Adjustment Type for other available plug-in spots that may be used by your implementation. |
|
Algorithm |
Admin, Algorithm. You may want to set up an algorithm that formats the Adjustment information that is displayed throughout the system for a specific Adjustment Type. This algorithm is plugged-in on the Adjustment Type. |
|
Algorithm |
Admin, Algorithm. You may want to set up an algorithm that formats the Adjustment information that is displayed throughout the system. This algorithm is plugged-in on the installation record. |
|
Debt Category |
Admin, Debt Category |
|
Debt Category Priority |
Admin, Debt Category Priority |
|
Adjustment Type |
Admin, Adjustment Type |
|
Adjustment Type Profile |
Admin, Adjustment Type Profile |
|
Approval Profile |
Admin, Approval Profile. Note, an approval profile references a To Do type and one or more To Do Roles; these must be set up before you can set up the approval profile. After the approval profile(s) are set up, they must be referenced on the adjustment types that they govern. |
|
Cancel Reason - Payment |
Admin, Payment Cancel Reason |
|
Cancel Reason - Adjustment |
Admin, Adjustment Cancel Reason |
|
Tender Type |
Admin, Tender Type |
|
Tender Source |
Admin, Tender Source |
|
A/P Request Type |
Admin, A/P Request Type |
|
Installation |
Admin, Installation Options - Framework and Admin, Installation Options. Many fields on the installation record impact the financial transaction environment. Refer to the description of the Financial Transaction tab for more information. |
|
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that distributes payments. |
|
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that handles overpayment situations. |
|
Algorithm |
Admin, Algorithm. You may need to set up an algorithm if you want the system to levy a non-sufficient funds charge if a payment is canceled due to non-sufficient funds. |
|
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that formats the payment information that is displayed throughout the system. This algorithm is plugged-in on the installation record. |
|
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that defaults the amount when a payment is manually added. This algorithm also calculates the amount of an automatic payment for a bill for an account with an active auto pay option. This algorithm is plugged-in on the installation record. |
|
Algorithm |
Admin, Algorithm. Refer to Account Type for other available plug-in spots that may be used by your implementation to perform additional logic when processing payments. |
|
Return to Account Type |
Admin, Account Type. You will need to plug-in the algorithms defined above on your account types. |
|
Address Environment |
||
Address Type |
Admin, Extendable Lookup, search for the Address Type lookup. Define valid address types for person addresses and tax role addresses. |
|
Address Inactive Reasons |
Admin, Extendable Lookup, search for the Address Inactive Reason lookup. Define valid address inactive reasons to use when changing the status of an address to inactive. |
|
Algorithm |
Admin, Algorithm. You will need an algorithm that finds an address if your implementation receives requests from external sources to define or update a taxpayer’s address. This plug-in determines if the address already exists in the centralized address repository. This algorithm is plugged-in on the installation record. |
|
Taxpayer Environment |
||
Account Management Group |
Admin, Account Management Group. Note: You will probably have to set up To Do Type and To Do Roles before you can set up account management groups. Refer to Assigning A To Do Role for more information on how account management groups may be used to define an entry's role. |
|
Account Relationship |
Admin, Account Relationship Type |
|
Alert Type |
Admin, Alert Type |
|
Algorithm |
Admin, Algorithm. If you have software capable of reconstructing an image of a letter in a PDF (for the purpose of online display), you will need to create an algorithm that formats the extract records that are sent to your letter image software. |
|
Letter Template |
Admin, Letter Template |
|
Customer Contact Class |
Admin, Customer Contact Class |
|
Customer Contact Type |
Admin, Customer Contact Type |
|
Algorithm |
Admin, Algorithm. You may need to set up the algorithms that determine if person ID's are in a predefined format. |
|
Identifier Type |
Admin, Identifier Type |
|
Industry Codes |
Admin, Industry Code |
|
Algorithm |
Admin, Algorithm. You may need to set up the algorithms that determine if phone numbers are in a predefined format. |
|
Phone Type |
Admin, Phone Type |
|
Person Relationship Type |
Admin, Person Relationship Type. |
|
Person Type |
Admin, Person Type |
|
Algorithm |
Admin, Algorithm. You will need to set up an algorithm that formats the person information that is displayed throughout the system. This algorithm is plugged-in on the installation record. |
|
Algorithm |
Admin, Algorithm. You can override the system's standard account information string by setting up an algorithm that produces this string of information. This algorithm is plugged-in on the installation record. |
|
Installation |
Admin, Installation Options. Many fields on the installation record impact the Customer Environment. Refer to the description of the Main, Person, and Account tabs for more information. |
|
Automatic Payment (EFT) Environment |
||
Algorithm |
Admin, Algorithm. You will need to set up an algorithm to create automatic payments. This algorithm is plugged-in on the installation record. |
|
Tender Source |
Admin, Tender Source Note: Earlier, you created tender sources for the remittance processor and your cash drawers. At this point, you'll need to add at least one tender source for automatic payments. Why? Because automatic payments get linked to a tender control (which, in turn, gets linked to a tender source) when they are interfaced out of the system. |
|
Algorithm |
Admin, Algorithm. You will need to set up the appropriate automatic payment date calculation algorithm to populate the extract, GL interface and payment dates on automatic payments. |
|
Auto Pay Route Type |
Admin, Auto Pay Route Type |
|
Tender Type |
Admin, Tender Type Note: Earlier, you created tender types for things like cash, checks, etc. At this point, you'll need to add a tender type for each type of automatic payments (e.g., direct debt, credit card, etc.). |
|
Work Calendar |
Admin, Work Calendar. You need only set up additional work calendars if the auto pay sources (i.e., the financial institutions) have different working days than does your organization |
|
Algorithm |
Admin, Algorithm. If you need to validate the taxpayer's bank account or credit card number, you will need to set up the appropriate validation algorithms. |
|
Auto Pay Source Type |
Admin, Auto Pay Source Type |
|
Algorithm |
Admin, Algorithm. You may need to set up an algorithm if your taxpayers can define a maximum withdrawal limit on their autopay options. |
|
Return to Account Type |
Admin, Account Type. You should plug-in the Autopay Over Limit Algorithm in each appropriate Account Type. |
|
Characteristics |
||
Algorithm |
Admin, Algorithm. If you have ad hoc characteristic types, you may need to set up the algorithms that control how they are validated |
|
Foreign Key Reference |
Admin, FK Reference. If you have foreign key characteristic types, you may need to set up foreign key references to control how the user selects the characteristic values (and how the foreign key values are validated). |
All base package FK references are automatically populated |
Characteristic Type & Values |
Admin, Characteristic Type |
|
Tax Type and Obligation Configuration |
||
Revenue Calendar |
Admin, Revenue Calendar |
|
Tax Type |
Admin, Tax Type |
|
Algorithm |
Admin, Algorithm. You will need to set up the algorithms that determine:
|
|
Algorithm |
Admin, Algorithm. You may want to set up an algorithm that formats the obligation information that is displayed throughout the system. This algorithm is plugged-in on the installation record. |
|
Algorithm |
Admin, Algorithm. You may want to set up an algorithm that formats the obligation information that is displayed throughout the system for a specific obligation type. This algorithm is plugged-in on the Obligation Type. |
|
Tax Role Relationship Type |
Admin, Tax Role Relationship Type. |
|
Obligation Type |
Admin, Obligation Type |
|
Overpayment Configuration |
||
Algorithm |
Admin, Algorithm. You will need to define an extract algorithm that formats the data to be sent to a bank for direct deposit requests. These are plugged in on the bank event type. |
|
Bank Event Type |
Admin, Bank Event Type Note, if your implementation supports receiving rejections from the bank that should cause another attempt to refund, you will need a “retry” overpayment process type. |
|
Algorithm |
Admin, Algorithm. You will need to define overpayment validation and refund validation algorithms. These are plugged in on the overpayment process type. |
|
Overpayment Process Type |
Prior to defining your overpayment process types, refer to Enabling the System to Use Standard Overpayment Process for information about data that needs to be defined for a typical overpayment process type. Admin, Overpayment Process Type. If you have defined a “retry” overpayment process type, return to bank event to configure this value. |
|
Refund Control Type |
Admin, Refund Control Type |
|
Wrap Up |
||
Algorithm |
Admin, Algorithm. You will need to set up the algorithms that determine:
|
|
Installation Options |
Admin, Installation Options - Framework and Admin, Installation Options. At this point, it's a good idea to double-check everything on the installation record. |
|
Postal Default |
Admin, Postal Code Default |
If you have cash drawers you will also need to set up the following information:
Create a person / account to which you will link your over / under obligation. Refer How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under) for more information.
Create an obligation to which your over/under payments will be linked. This obligation will reference your over / under obligation type. Refer to Over / Under Cash Drawer Obligations for more information.
Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved. Documentation build: 2.5.2016 10:21:45 [T1_1454696505000]