Oracle Public Sector Revenue Management

Business User Guide

Release 2.5.0.0.0

E71301-01

March 2016

Documentation build: 2.13.2016 4:41:49 [T1_1455367309000]

Copyright © 2007, 2016, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

Oracle Public Sector Revenue Management Business Process

The topics in this section describe the business processes for the Public Sector Revenue Management application.

Next in This Section

- User Interface Standard Features

- Taxpayer Information

- Forms Processing

- Asset

- Penalty and Interest

- Billing

- Payments

- Adjustments

- Financial Transactions

- Overpayment Processing

- Bank Event

- Rates

- Bankruptcy

- Audit Case

- Appeal

- Review

- Pay Plans

- Suppression

- Work Management

- Overdue Financial Obligations

- Classic Billing

- To Do Processing

- Reports

User Interface Standard Features

This section describes basic system concepts, features, and standards of the user interface.

Next in This Section

- System-Wide Standards

- Portal and Zone Features

System-Wide Standards

This document is the central reference to basic system concepts, features, and standards.

Next in This Section

- Page Components

- Maintenance Pages

- Query Pages

- Portals

- User Preferences

- Initiating Scripts

- Accelerator Key Summary

Page Components

This section serves as a central reference to the basic building blocks of all pages used in the system.

Next in This Section

- Characteristics Common to All Pages

Characteristics Common to All Pages

Oracle Utilities Application Framework screens comprise the following main areas:

1. The Application Toolbar

2. The Page Title Area

3. The Object Display Area

4. The Dashboard Area

Note: The look and feel of the application may be modified after the product is installed. See Custom Look and Feel Options for customization information, including how to change colors, fonts, and other system features. The information provided in this document represents features and functionality available only in the delivered product.

Next in This Section

- The Application Toolbar

- Page Title Area

- Object Display Area

- Dashboard Area

- Script Area

The Application Toolbar

This section describes the features available on the application toolbar.

Next in This Section

- Home Button

- Menu

- Admin Menu

- Back Button

- History Button

- Forward Button

- About Button

- User Menu

- Help Button

Home Button

Click the Home button, , on the Application Toolbar to open your home page. Your home page is defined in User Preferences.

Keyboard shortcut: Alt+O

Menu

Menu is available in the application toolbar to help you navigate to the different pages of the system

The keyboard shortcut to open the Menu: Ctrl+Alt+M

The menu list is organized by functional area. Clicking the Menu button displays each functional area. Clicking a functional area, in turn, displays a submenu that contains pages within that area.

The pages within each functional area typically have two options: Add and Search. If the menu item does not have an Add or Search option, select the menu item itself.

How the Add and Search option behaves depends upon whether the maintenance page is fixed or portal-based.

Fixed:

- Add: Displays the maintenance page with empty fields so that the user can complete the information and save the entity.

- Search: Displays a pop-up search window for the user to enter the search criteria and select the entity to display. Once the entity is selected, the user is taken to the maintenance map with the data populated in the fields.

Portal-Based:

- Add: Either navigates to a page where the user can select the entity type or business object, or directly to the input map where the user can enter and save the entity.

- Search: Displays a search portal where the user can enter the search criteria and select the desired entity. Once the entity is selected, the user is typically taken to a maintenance portal or the information is broadcast to other zones within the same portal.

Admin Menu

The Admin dropdown is available in the application toolbar to help you navigate to the different pages of the system.

The keyboard shortcut to open Admin: Ctrl+Alt+A

Depending on how your implementation has configured the Admin menu list, it may be organized either by functional area or alphabetically.

Clicking the Admin button displays each functional area or alphabetical list. Clicking one of the options, in turn, displays a submenu that contains pages within that area. The following is an example of the Admin menu organized alphabetically.

Note: Refer to Installation Options for information about the admin menu configuration options.

The menu lines displayed for each functional area typically have two options: Add and Search. If the menu item does not have an Add or Search option, select the menu item itself. See Menu for more information about these options.

Back Button

Click the Back button on the application toolbar to open the previously visited page.

Keyboard shortcut: Alt+B.

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Note: Under certain circumstances, such as revisiting a page that was left unsaved after being loaded with default data, a page may not appear as it did when you left it.

History Button

Click the History button to display a list of previously visited pages. When you click on an entry in the list to return to an earlier page, all items above the selected page are removed from the list.

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Keyboard shortcut: Ctrl+Alt+H

Forward Button

Click the Forward button to return to the page that was most recently dismissed.

Keyboard shortcut: Alt+G.

The back and forward navigation buttons, as well as the History list, appear in the application toolbar only when page use warrants their appearance.

Note: Under certain circumstances, such as revisiting a page that was left unsaved after being loaded with default data, a page may not appear as it did when you left it.

About Button

Click the about button to display a window that describes the current and release information for your version of your product.

The about window shows a variety of information including:

- Who the system is licensed to

- The user ID that is logged in

- The release ID of the product

- The release ID of the framework used to construct the product

- The release ID of any customer specific modifications (this comes from the installation record)

User Menu

The User menu is available in the application toolbar to provide access to user-specific options.

Through this dropdown, the user can access their User Preferences or Logout of their current session.

Note: Configurable Menu. Additional menu entries may be visible in your implementation as this menu configuration allows for additional options to be defined.

Next in This Section

- Preferences

- Logout

Preferences

Click the Preferences menu item in the User Menu to view or modify your settings in a form that appears in the Main tab in the object display area.

Logout

Click the Logout menu item in the User Menu to complete your current session of the application. Clicking this item logs the current user out and displays the Welcome page so that another user can login.

Help Button

Click the Help button in the Application Toolbar to open context-sensitive Help in a new browser window.

Keyboard shortcut: Alt+F1

Page Title Area

The Page Title Area displays the page title and the page actions toolbar.

For certain pages in the system, the page title may be followed by an information string. It is only applicable to portal-based pages that display a single record. This information is only visible if the portal has been configured to display the primary key’s information string. Typically only “stand alone” maintenance portals are configured to show the information string, whereas “all-in-one” portals are not configured this way.

Fastpath: Refer to Common Base Portals and Zones for more information about standard base product portals.

Note: If an information string is long and would interfere with a page actions button, the information string will automatically be truncated and suffixed by an ellipsis, “…”, indicating that more information is available. In this situation, the missing text can be viewed if the user hovers their mouse over the string.

The Page Actions Toolbar displays standard control options, such as Save and Duplicate. More detail about the actions that may appear are described in the following section.

Next in This Section

- Page Actions Toolbar

Page Actions Toolbar

In the Page Title Area, control functions appear in the Page Actions Toolbar; such as, Clear, Save, Duplicate, Delete and Refresh buttons.

Note:

Buttons in the Page Title Area appear as the function is available to the user; for example, the Delete button will not appear if the user has made any changes to the page’s content, or does not have the necessary security rights for this action.

In addition, other functions that are specific to a portal-based page may appear in the toolbar, if configured. For example, the ability to navigate to the Search zone for a specific maintenance object may be visible on the maintenance portal.

This section describes the standard features that are available in the Page Actions Toolbar.

Next in This Section

- Bookmark Button

- Next/Previous Item Buttons

- Duplicate Button

- Delete Button

- Clear Button

- Save Button

- Refresh Button

Bookmark Button

Click the Bookmark button on the Page Actions Toolbar to save the current page and context to the bookmarks list.

Note: Secured. This button is secured using the application service F1–BOOKMARKS. Users that do not have security for the application service will not see the Bookmark button (or the corresponding dashboard zone).

After clicking the Bookmark button, you are prompted to provide a name for the bookmark. After saving, it is visible in the Bookmarks Zone, allowing you to return to this page with this context loaded with one click.

Note: Unsaved data will not be included in the bookmark. If you view a record and make changes to data without saving the changes and then bookmark the page, the unsaved changes are not included in the bookmark information.

You may change the name of the bookmark or change the sequence of the bookmarks by navigating to the User — Bookmarks in the user preferences.

Next/Previous Item Buttons

The (Previous Item and Next Item buttons appear in the Page Actions Toolbar under these conditions:

- You access a fixed page, meaning that it is not portal-based.

- You use a search page to display an item.

- There are multiple items in the search results list below or above the selected item.

If, for example, you enter search criteria of "Smith" on the User Search page, you might see the following results:

- Smith, Albert

- Smith, Peter

- Smith, Zane

If you select Smith, Peter, Peter's user information is displayed on the User page. If you then click the Next Item button, Smith, Zane will be displayed. In addition, because Smith, Zane is the last entry in the search results, the Next Item button is no longer needed and will not appear in the Page Actions Toolbar.

If you then click the Previous Item button, Smith, Peter will be displayed; click again and the Smith, Albert record will appear, and, because Smith, Albert is the first entry in the search results, the Next Item button is no longer needed and will not appear in the Page Actions Toolbar.

Keyboard shortcuts: Alt+P, Alt+N.

Duplicate Button

Click the Duplicate button in the Page Actions Toolbar to create a duplicate of the currently selected object.

Before the new object is added to the database, a dialog appears in which you must enter the unique identifier for the duplicate object. When you click OK, the system creates the record by copying the original record. It may be helpful to think of the duplication function as the equivalent of a "save as" action.

Keyboard shortcut: Ctrl+Alt+D.

Note: Copying ancillary information for a record sometimes requires confirmation during a duplication request. If so, you may also be asked if you also want to duplicate ancillary information. If, for example, you duplicate a user group, besides supplying the ID of the new user group, you are asked if all users in the original user group should be linked to the new user group.

This button does not appear in the Page Actions Toolbar when:

- Duplication is not supported for the current object.

- You are on a portal based page. (For these types of pages, if duplication is supported, the actions are defined in a zone on the portal.)

- You have made changes to the object without committing the changes to the database by clicking Save. (After making changes, you must either discard them using the Refresh button, or save them.)

Delete Button

Not all transactions have the capability to be deleted. Deletion is related to the business impact of the action. In some transactions, Delete is present for some scenarios and unavailable for others; for example, you may not be able to delete a record at a certain status level.

Note:

If you make a change to an object and do not save the changes to the database, you cannot delete the object until you either save the changes or refresh the object with the contents on the database.

Before you delete an object, the system verifies that the object is not referenced anywhere in the system. If it is, you cannot delete it. If, for example, you attempt to delete a user, the system ensures this user has not been referenced in a user group or on a To Do.

Depending on the type of page that you are using, the option to delete may vary.

- Fixed pages display a Delete button in the page actions toolbar when the option is available.

- Portal-based pages display the Delete button in the object-related map.

- List zones on All in One portals commonly display the Delete button (garbage can icon) next to the entity in the search results.

In all cases, before the object is deleted, a confirmation dialog is displayed.

CAUTION:

A timeout situation could occur as the system attempts to verify the use of the deleted object if the object is referenced in many places and involves large volumes of production data. If this timeout situation occurs, you must with your database administration group to delete the offending object.

Clear Button

Click the Clear button to remove the values from the currently displayed object’s fields. This action is typically used to clear input fields when adding a new object.

Keyboard shortcut: Ctrl+Alt+C.

Save Button

Clicking the Save button saves any changes you have made in the data on the current object.

Keyboard shortcut: Alt+S.

The button does not appear unless:

- You enter a page in add mode and default values are loaded.

- You make changes to an object after it is displayed (note that you must tab or click out of the field before the Save button appears).

Refresh Button

Click the Refresh button to reload the values on the page with those from the database.

CAUTION:

All unsaved changes are discarded.

Keyboard shortcut: Alt+R.

Object Display Area

The Object Display Area contains the details of the object(s) currently being viewed or maintained. For example, if you display a portal, its zones are displayed in this area.

Because many of the page components follow Internet standards of operation, it seems redundant to describe their function. Instead, this section describes special features, or enhancements, that appear within the framework.

Next in This Section

- Text Box

- Date Only Field

- Date and Time Field

- Search Button

- Context Menu Button

- Go To Button

- Broadcast Button

- Work Lists

- Scroll Bars with Dynamic Height

- Sorting Functionality

- Get More Functionality

- Adding and Removing Rows Using Arrows

- Reorganizing Items Using the Up and Down Arrows

- Trees

- Required Field Indicator

- Accordion Windows

Text Box

The following is an example of a basic text box:

If the text box is a large field, the text box may be configured to enable scrolling. In this situation, an Expanded Edit icon, pencil, will appear adjacent to it.

Additional capabilities are provided to display and edit data in these text boxes:

- If the field contains more text than is visible, a pop-up that displays the full text appears when you hover your mouse over the text box. The text in the pop-up can be selected and copied.

- If you click the Expanded Edit icon, an editable pop-up window appears. If the field is not protected as a result of business rules for the page, you may modify the text in this window.

Note:

Special characters are converted to equivalent standard characters when entered in a text box:

Entered Character Description

Unicode

Converted Character Description

Curly left double quote.

U+201D

Straight double quote.

Curly right double quote.

U+201C

Straight double quote.

Curly left single quote.

U+2019

Straight single quote.

Curly right single quote.

U+2018

Straight single quote.

En dash.

U+2013

Simple hyphen.

Em dash.

U+2014

Simple hyphen.

Ellipse

U+2026

Three dots.

Middle dot (bullet / centered dot)

U+00B7

Asterisk.

Fraction 1/4 (using 1 character).

U+00BC

1/4 (using three separate characters).

Fraction 1/2 (using 1 character).

U+00BD

1/2 (using three separate characters).

Fraction 3/4 (using 1 character).

U+00BE

3/4 (using three separate characters).

Date Only Field

When only the date is required, the Date field looks as follows:

If you click the calendar icon next to the date field, or you double-click inside the date field, the following window appears:

If the date field was blank, the current date is highlighted when the window first appears. If the date field contained a date, it is displayed.

You can double-click the desired date, or you can select a date and click Accept to close the date window and populate the date field.

Date and Time Field

When both the date and time are required, the Date and Time fields typically look as follows:

If you double-click or press the Enter key while the cursor is in a Date and Time field, the following window appears:

Select the date and use the toggle buttons (or enter) the time and then click Accept to populate the original fields.

Note: The user cannot select and move the hands on the clock to set the time.

Search Button

The search button appears primarily as a magnifying glass.

When using a pop-up search window, the search button can appear as a button with its function labeled.

You can have the system search for an item that matches the data you entered using any of the following methods:

- Enter a value in the search field and press Enter while the cursor is in the search field. The system assumes you want to search for the value entered and pre-populates it in the search window's search criteria. If a unique match can be found, the system automatically populates the field with details corresponding to the record found. If a unique match cannot be found (either no matches or multiple matches), a search page opens containing selectable items.

- Click the Search button without entering a criteria. This will typically cause a pop-up search window to appear so that you can further refine your search.

- Enter a value and tab out of the search field. The system looks for a value that exactly matches what you entered. If it cannot find such a value, the search dialog will not be presented.

When an item is selected in the search page, the search page closes and the input field is populated with the value selected.

Note: Sorting columns within the search grid. You may click on the column heading of columns in a search grid to cause the contents of the grid to be sorted. Refer to Sorting Functionality for more information.

Context Menu Button

The Context Menu button is a small version of the Menu button from the Application Toolbar. An example is shown below:

Context menus exist to help you navigate to other pages and populating the page with the current context (by passing the ID of the related object). In addition, the menu items offered in a Context Menu differ depending on the entity that the menu is related to; for example, when you click the Algorithm Type context menu, a pop-up menu similar to this appears:

Different context menus exist for each of the major objects in the system; for example, in Customer Care and Billing, the context menu for Premise contains premise-oriented menu items, whereas the context menu for Account contains account-oriented menu items.

Go To Button

Clicking a Go To button, , opens the page for the related object - it functions like a hyperlink.

Broadcast Button

Some zones have been configured to "broadcast" unique identifiers to other zones within the portal; if so, you'll see a broadcast tower icon, , in the first column. Clicking the icon causes specific zones to reload — these zones that have been configured to rebuild when the unique identifier is received. For example, you might have configured a zone to display the image of a bill when a bill ID is broadcast from an info zone.

Work Lists

The work list buttons can appear in a zone’s column heading, .

Clicking the icon results in populating the dashboard Work List Zone with the entire column. The user may use the Work List zone to easily process entries one at a time without returning back to the source query zone. The work list stays populated until the user overlays the work list by clicking a different column's icon.

When a user clicks on a work list entry in the dashboard, the system behaves as if the user clicked on the hyperlink in the zone. In addition, the system adds a check mark next to the item showing that the user has “worked on” or visited the entry.

Note: The Work List zone is populated only upon user request.

Scroll Bars with Dynamic Height

Sometimes the height of a grid isn't sufficient to display a grid's rows. When this occurs, a vertical scroll bar appears and an "expand button" appears above this bar, . For example, the following grid is not high enough to show all of a the available dashboard zones:

If you want to view all of the person's phone numbers without using the vertical scroll bar, you can you click the expand button. When clicked, the height of the grid expands to show all rows in the grid:

Notice, after the grid is expanded, the grid's vertical scroll bar disappears and the button in the upper corner becomes a Collapse Button, . If you click the collapse button, the grid will return to its original height.

Note: Search grids. Expand all functionality is not available in search grids.

Sorting Functionality

Grids have a heading row that contains labels for the columns. By clicking a column heading, you cause the rows to be sorted in the order of the selected column. By clicking on a column more than once, you cause the rows to be sorted in reverse order. Clicking the heading a third time removes the sorting function and returns the grid to its default display organization.

The following shows how information look after organizing the grid, clicking the column heading, by algorithm type (notice the icon in the column name).

Note: Sorting on dropdown values. If you attempt to sort a column that contains a dropdown value, the information is sorted in the order of the unique identifier associated with the dropdown value, not the description you see on the screen; for example, if you sort on a column containing unit of measure, the information will be sorted in the order of the unit of measure code, not the description that appears in the drop down. This means that the resultant sort will appear incorrect and therefore we discourage you from doing this.

Get More Functionality

Grids that can potentially contain a large number of rows have special processing that we refer to as Get More functionality. We'll use an example from Oracle Utilities Customer Care and Billing to explain - consider the grid that contains all payments that have been added to a cash drawer. By the end of the day, this grid could contain hundreds of rows (one for each payment remitted during the day). Rather than show every payment in the grid, the system retrieves the first X payments (where X varies from grid to grid, and from release to release) and appends a Get More button to the bottom of the grid as illustrated below:

When you click the Get More button, the system appends the next X rows to the bottom of the grid.

Note: The absence of a "get more" button. If no button appears at the bottom of the grid, this means you are seeing all of the rows.

Note: Search grids. The Get More function is not available in search grids.

Adding and Removing Rows Using Arrows

In some editable grids, a new row can be added to another editable grid (the grid on the left) by clicking the Add item button, , of the desired row in the grid on the right:

When the Remove item button is clicked, , the row is transferred from the grid on the right to the grid on the left. This change will not be committed to the database until you save the object being maintained

Reorganizing Items Using the Up and Down Arrows

Occasionally, rows can be repositioned in an editable grid by clicking up and down arrows. The following is an example of such a grid:

Notice the following about such a grid:

- The up arrow is dim in the first row. This is because it can't be moved further to the top.

- The down arrow is dim in the last row. This is because it can't be moved further down.

- The up and down arrows are usable in all other rows. Each time you click one of these arrows, the respective row is moved up or down one row.

Note: Reminder. When you move rows into a grid, the system does not apply the change to the database until you click the Save button (which commits the entire object to the database).

Trees

Trees are used to illustrate complex relationships between objects. The following is an example from Oracle Utilities Customer Care and Billing of a page with a tree that is expanded:

The following points describe how to use trees:

You can expand and contract the nodes in a tree by clicking on the icon that prefixes the node (you can also click the + and - button to expand and contract a node).

Note: Expand all. If you press Ctrl while clicking on an icon that prefixes a node, all child nodes (and their children) expand.

You can click the context menu button to cause a context menu to appear. You can navigate to any of the pages that are presented on this menu. Refer to Context Menu Button for more information.

You can click on the information that appears in an underlined node to drill into the page in which the object is maintained. For example, if you click on the account information, you will be transferred to the Account - Main page.

Note: Important! If you make changes after expanding a tree's nodes (e.g., by drilling down on a Premise and changing the premise's address), the tree will contract to the first node if you return to the page.

Nodes in trees fit into two broad categories:

- Information nodes. Information nodes highlight the existence of other data. For example, on the Control Central - Bill Payment Tree, a node exists to highlight the existence of new financial transactions that were created since the last bill was completed.

- Data nodes. Data nodes show information about objects in the system. For example, data nodes exist on the Control Central - Bill Payment Tree that show bills and payments.

Required Field Indicator

An asterisk (*) is used to indicate that a field is required. The system determines this based on the field’s configuration. When a field becomes required because of an algorithm and not the field’s configuration, however, the system will not add an asterisk.

Note: The field indicator only appears on portal-based pages. Older, fixed pages will not include this designation.

Note:

If a page includes a grid, fields within a row may be marked as required.

In this situation, the field(s) within the grid are only required if the row is being populated.

Accordion Windows

Accordion windows are used when the data held in an object's rows does not comfortably fit into a grid.

Each row in an accordion has a header that summarizes a row's details. When you click a header, the row expands to show the details. The following is an example of an accordion where all headers are collapsed (meaning that only summaries of the rows' details are shown):

When you expand a header, its details are exposed. For example, the following shows the same accordion after the third row is expanded:

Note: You must expand to update. In order to update a row in an accordion, you must expand it.

Next in This Section

- Row Summary and Chunk Management

Row Summary and Chunk Management

At the top of an accordion you'll find a summary of its rows. The format of this information differs depending on the number of rows and the size of the accordion:

- If the accordion contains every row, a summary of the total number of rows is displayed.

- If the accordion contains a subset of rows, you are presented with a summary of the rows AND you are provided with options to display different "chunks" of rows.

- Click First to display the first "chunk" of rows (the size of a chunk differs depending on the accordion). This option is dimmed if the first chunk is in the accordion.

- Click Previous to display the previous chunk of rows. This option is dimmed if the first chunk is in the accordion.

- Click Next to display the next chunk of rows. This option is dimmed if the last chunk is in the accordion.

- Click Last to display the last chunk of rows. This option is dimmed if the last chunk is in the accordion.

Dashboard Area

The dashboard is a portal that contains zones. These zones appear regardless of the object being displayed in the Object Display Area. Refer to Dashboard Portal for a description of these zones.

Note: User configurable. Every user has control over the zones that appear in their dashboard. Refer to Portal Preferences for more information about how a user can customize the contents of the dashboard.

Script Area

When a script is initiated, the object display area shifts down to make room for the script area.

The information in the script area takes you through the steps in the selected business process (provided by your implementation team).

Maintenance Pages

Maintenance pages are used to maintain (add, change, etc.) the information in the system using a fixed page metaphor. All user interfaces implemented in this way function in a similar manner. This section focuses on functionality common to all maintenance pages using this metaphor.

Note: Not all maintenance pages in the application use this style of maintenance page. The preferred metaphor for maintenance pages, however, is to use portal-based pages. For more information see Common Base Portals and Zones.

Next in This Section

- The Unique Identifier Area

- Confirmation & Error Messages

- Warning If Unsaved Changes Exist

The Unique Identifier Area

Every object in the system must have a unique identifier. For some objects, typically administrative or control table data, the unique identifier is defined by the user creating the record. Other objects, typically master or transaction entities, the unique identifier is assigned by the system after the record is saved.

Where the identifier is displayed depends upon whether the ID is user-defined or system generated.

Pages displaying objects with a user defined identifier (such as To Do Type) typically display the identifier on the left along with a search button. For master and transaction tables, (such as To Do Entry) the unique identifier is typically found in the upper right corner of the screen along with a search button and is labeled as the entity’s ID. In this case, if there is an information string associated with the object, it is displayed on the left.

If the object being maintained has an associated context menu, a Context Menu Button is displayed appear.

Confirmation & Error Messages

Whenever a database modification action is requested, the system first validates the data to be put on the database.

First, the system validates the information. If there are errors, the first error encountered is displayed in a window. In addition to the error message, the error window also contains the error number and the identities of the programs that detected the error. If you don't understand an error and you have to call product support, please supply them with this information.

If there are no errors, the system is modified.

Warning If Unsaved Changes Exist

If you make any changes to an object and you don't commit these changes to the database, the following warning appears: "You have unsaved changes that will be lost if you continue. Press OK to continue anyway."

If you want to commit the changes, click Cancel. You will then return to the page and can make further changes or press Save. If you want to discard your changes and transfer to the new page, click OK.

CAUTION:

This warning is not displayed if you are working on a new object on a fixed page and you navigate to a different page. Information about new objects is preserved in memory in anticipation of your return to the page. For example, if you are in the middle of adding a new user and you want to quickly reference information on a different page, you will not receive the above warning because your information will be saved. If you use the back button to return to the user page, all of the information you were adding will be present and you can enter the rest of the new user's data.

Query Pages

Query pages are used to display record sets in the system. Most query pages function in a similar manner. This section focuses on functionality common to all of the system's query pages.

Next in This Section

- The Search Area

The Search Area

The upper right corner of the screen is almost always the identifier of the object associated with the search. In Oracle Utilities Customer Care and Billing for example, the unique identifier on the Account Financial History page is the Account ID.

To the right of the unique identifier is a Search button. This button is used to search for a different object than the one whose data is being displayed in the page.

If the object being displayed has an associated context menu, a Context Menu Button is displayed.

Portals

This section describes certain types of portals provided in the system where a user may control the content, for example the dashboard.

Portals used for base product query and maintenance pages are typically configured to not allow user customization. Refer to Common Base Portals and Zones.

In most base products, there are several pages whose content can be customized by individual users. These portals exist because different users have different data requirements. For example, in Oracle Utilities Customer Care and Billing a billing clerk might prefer the customer information portal to show a customer's bills and payments. However, a credit and collection supervisor might prefer the same page to show an account's collection activity. Portals allow each user to define what they want to see.

The contents of this section provide background information about portals.

Next in This Section

- Portals Are Made Up Of Zones

- Each User Can Customize Which Zones Appear

- Users Must Be Granted Security Access To Each Zone

- Zones May Appear Collapsed When A Page Opens

- Dashboard Portal

Portals Are Made Up Of Zones

The term "zone" is used to describe a section on a portal. For example, the following is a portal with seven zones:

- Switch Language

- Bookmarks

- Checked Out

- Current Context

- Current To Do

- Favorite Links

- Favorite Scripts

Note: This example may not be available in your application; it is used for illustration purposes only.

Each User Can Customize Which Zones Appear

For any portal that is configured to show on portal preferences, each user has control over the following:

- Which zones appear on their portal

- The order in which the zones appear

- Whether the zones should be "collapsed" (i.e., minimized) when the portal opens.

Users define their preferences by clicking the User Preferences button. Pressing this button transfers the user to the User Preferences page on which their Portal Preferences can be defined.

CAUTION:

Recommendation. We strongly recommend that you set your preferences to collapse zones that you don't use often. Why? Because we don't perform the processing necessary to build collapsed zones until you ask to expand a zone. Opening a page with zones collapsed accelerates the response times of portal.

Users Must Be Granted Security Access To Each Zone

A user must be security granted access rights in order to see a zone on a portal.

Fastpath: Refer to Granting Access to Zones for information .

Zones May Appear Collapsed When A Page Opens

Portal Preferences allows the user to collapse a zone (or minimized) when a portal appears to reduce space for the zone while keeping the data easily available. To view the information in a collapsed zone, the user can press the zone's expansion button, , to either expand or collapse the zone:

CAUTION:

Recommendation. We strongly recommend that preferences be set up to collapse zones that may contain data that is only needed upon a user's request. The system doesn't perform the processing necessary to build collapsed zones until a user asks to expand a zone. As a result, indicating a zone is collapsed improves response times.

Dashboard Portal

The dashboard is a portal that always appears on the desktop. Its zones contain tools and data that are useful regardless of the object being displayed.

Note: Minimize the dashboard. You can minimize the dashboard by clicking on the vertical bar on the left side of the dashboard. This causes the dashboard portal to disappear allowing more of the page area to display. The vertical dashboard bar is then displayed on the right side of the page. Clicking the dashboard bar restores the display of the dashboard portal. Rather than clicking, you may press Alt+J to toggle the display of the dashboard.

The contents of this section describe the zones that are provided by the framework product for this portal. Please note the following additional information about the dashboard portal that may impact how it appears.

- Additional zones may be available in other products. The zones described below are available in every base product. Please refer to the product-specific documentation for additional dashboard zones available in your product (open the help and navigate to the index entry labeled Dashboard).

- Context Sensitive Zones may appear. Some pages may define additional zones that should appear in the dashboard only if that page is displayed. These are referred to as Context Sensitive Zones.

- Dashboard zones are configurable. The dashboard portal is configured to allow a user to define preferences for it. Refer to Portal Preferences for more information.

Note: Security. As a general rule, dashboard zones each refer to a unique application service so that a security administrator may configure which users are allowed to have access to which zones. Note that the user portal preferences indicates which zones a user has security access to.

Next in This Section

- Bookmarks Zone

- Current To Do Zone

- Favorite Links Zone

- Favorite Scripts Zone

- Favorite Searches Zone

- Switch Language Zone

- To Do Summary Zone

- Work List Zone

Bookmarks Zone

After clicking the Bookmark button and saving a bookmark, it is visible in the Bookmarks zone. Clicking one of the links in the zone navigates to the page where the bookmark was saved and loads the information related to the record that was displayed when the bookmark was saved.

Click the trash can icon to delete the bookmark.

Note that a user may change the name of the bookmark or change the sequence of the bookmarks by navigating to the User — Bookmarks in the user preferences.

Current To Do Zone

The Current To Do zone is designed to streamline the process of working on To Do entries from assignment to completion. It displays key information about the user's current To Do entry and provides functions that help minimize the number of steps it takes to resolve the entry and potentially other entries related to it.

The following sections provide more detail about the zone.

Next To Do Assignment

Users may have the option to click the To Do icon to request the next To Do entry they should work on. This functionality is optional and can be configured to follow your organization's business rules in determining the next task for a user. For example, if your organization practices work distribution "on demand", this feature can be configured to find the highest priority entry a user can work on and assign it to the user. Refer to work distribution for more information on this business practice.

Note: Next Assignment Rules Are In A Plug-in. Refer to Next Assignment Algorithm for more information on how to configure the system to take advantage of this function.

If the system is successful in determining the next entry the user should work on, this entry becomes the user's current To Do and its information is displayed on the zone.

User’s Current To Do

The user’s current To Do may be set using the Next Assignment algorithm, or by drilling in on a To Do from the To Do List or To Do Search page as described in A User's Current To Do. Once a current To Do has been set, the zone displays details related to the To Do.

The Message describes why the entry exists. The message description allows the user to drill into the page on which the entry's respective object is displayed. For example, if the entry is associated with an asset that needs review, the user is brought to the asset page to view the information and potentially take action. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched.

Info displays the standard To Do information. An Info icon appears if there are comments on the To Do and a Description icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do. The description drills into the To Do entry page allowing the user to view more information about the entry or make changes to it as needed.

The user may use the Complete button in the zone to complete the current entry.

Next / Previous To Do Buttons

The Previous To Do and Next To Do buttons are enabled on this zone under the following conditions:

- The user selected an entry either on the To Do List page or the To Do Search page.

- At least one other entry exists below (for Next) or above the entry selected (for Previous).

Clicking Next To Do or Previous To Do will bring the user to the transaction indicated on the To Do Entry’s message, where its respective object is displayed. It also makes that To Do the Current To Do displayed in the zone.

The keyboard shortcut to simulate Previous To Do: Alt+Y

The keyboard shortcut to simulate Next To Do: Alt+Z

Note: When a user drills down on a To Do entry from the To Do List page, the system automatically changes the status of the entry to Being Worked. If Next To Do or Previous To Do is subsequently used to scroll through this list, the system does not change the To Do entry's status. To change the status of these entries, the user must navigate to the To Do List. On this page, multiple entries may be selected and their status changed with a single user-interface action.

Related To Do Entries

If the To Do entry has non-complete related entries a summary Related To Do description appears. The description states the total number of related entries, how many are still in Open, how many are assigned to current user and how many assigned to others. This hyperlink navigates to the To Do Search query allowing the user to review the related entries. At this point the user may decide to assign entries that can be positively identified as being caused by the same problem as the current To Do also to himself.

If the user determines that all related To Do entries have been resolved with the appropriate action taken, the Complete All button may be used to complete in one step the current entry and all its truly related entries assigned to the current user.

If the related entries are not resolved with one action, the user may opt to use the Complete button to complete the current entry alone and work on related entries one at a time. Using the related To Do information hyperlink the user may navigate to the To Do search page and drill into the first related To Do to work on using the message hyperlink. This entry now becomes the user's current To Do and the Next To Do and Previous To Do action buttons are set to scroll through the related entries list.

Favorite Links Zone

Each line in the Favorite Links Zone corresponds with one of the user's favorite links (e.g., transactions). Clicking on a line invokes the transaction. A number appears adjacent to the first nine entries to highlight that these links can be invoked by pressing an accelerator key (Ctrl + a number). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Users define their favorite links by clicking the User Preferences button. Clicking this button transfers the user to the User Preferences page on which their Favorite Links can be defined.

Favorite Scripts Zone

The Favorite Scripts zone lists the business process assistant (BPA) scripts that you have defined on your user preferences. You can click on a script to execute it. You can click the Search button in the zone to search for other scripts.

Note: If you do not see the Favorite Scripts zone in your dashboard, navigate to User Menu and click the Preferences menu item to display the User - Portal Preferences page. Under the Dashboard Portal row, select the Display option for the Favorite Scripts zone.

Favorite Searches Zone

If you marked a saved search as a favorite using Saved Searches functionality, the search is visible in the Favorite Searches zone. Clicking one of the links in the zone navigates to the page where the search was saved and populates the filter values and executes the search.

Switch Language Zone

The Switch Language zone is used to switch the application's language. Only languages that are supported by your implementation will appear.

To switch the application's language, choose the desired language and press the Refresh button.

Note: If your implementation uses a single language. If your implementation uses a single language, you should suppress this zone by not granting security rights to the zone's application service.

To Do Summary Zone

The To Do Summary Zone has several purposes:

- It presents a summary of the To Do entries that have been assigned to you and are Being Worked On.

- The colored "age bars" highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable. Note, you can hover the cursor over an "age bar" to see the number of To Do entries.

- If you click on the To Do Type description or on an "age bar", you'll be transferred to the To Do List transaction where these To Do entries will be displayed. From this page, you can drill down to the specific entries.

Note: Time saver! After you drill down on entry from the To Do List page, if you have the Current To Do zone configured in the dashboard, you can use the Previous To Do and Next To Do buttons in the zone to scroll through additional To Do list entries without returning to the To Do List page.

Work List Zone

The Work List zone provides quick access to an entire column of an info or query zone. When a user clicks on a work list entry, the system will do whatever it would have done if they'd clicked on the hyperlink in the zone. In addition, the system ticks off that they've worked on the entry (this feature is mostly so users know that they've at least looked at something). Refer to Work Lists to better understand how to configure query columns to support work lists.

User Preferences

The Preferences (or My Preferences) transaction and the User Maintenance transactions are the same except that with My Preferences, only the following items can be modified:

- Main Tab

- Language

- Display Profile

- Time Zone

- Email Address

- Dashboard Width

- Home Page

- To Do Summary Age Bar Parameters

- Bookmarks

- All information can be modified

- Portal Preferences

- All information can be modified

- Favorite Links

- All information can be modified

- Favorite Scripts

- All information can be modified

Next in This Section

- User - Main

- User - To Do Roles

- User - Access Security

- User - Bookmarks

- User - Portal Preferences

- User - Favorite Links

- User - Favorite Scripts

- User - Characteristics

- User - Miscellaneous

User - Main

This page lets you view or define user information and access settings.

To open the page, either:

- Choose the Admin > Users > Search menu item.

- Choose the Menu > My Preferences menu item; or,

- Choose the User Menu > Preferences menu item in the application toolbar;

Note that some fields are only modifiable when the page is opened from the from the Admin menu.

Description of Page

Basic user identification information is viewed or set in the First Name, Last Name, User ID, and Login ID fields, all of which are modifiable only when the page is opened from the Admin menu. User and logon IDs must be unique. The Login ID is the id that the user uses to log in to the system. The User ID is the ID that is used throughout the application when users are assigned to tasks or when the user ID is stamped on records when logging add or update actions.

Language Code defines the language in which the user's screen prompts and messages appear.

Set User Enabled to allow the user to access the system.

Note: This field, available only when the page is accessed through the Admin menu, provides special field-level security. A user can change the field only if the Enable/Disable access mode is set.

Display Profile ID defines the display options for the user.

The next group of fields is used to view or set user preferences. For example, you can set up portal preferences on a "template user" and indicate that specified users will inherit their portal preferences from the template. Doing so provides consistency in the application of account information and dashboard zones. This fields are modifiable only when the page is accessed through the Admin menu.

- Set User Type to Template User if the user's preferences are to match those of other users.

- If a user's portal preferences are to be inherited from a "template user", use the Portals Profile User ID to define the user ID of the template user. If applied, the specified user will inherit portal preferences from the Portals Profile User ID and will be unable to customize those preferences.

- If a user's favorite links are to be inherited from a "template user", use the Favorites Profile User ID to define the user ID of the template user. If applied, the specified user will inherit favorites preferences from the Favorites Profile User ID and will be unable to customize those preferences.

The Time Zone associated with the user may be defined. Implementations may use this information for features and functions where the user’s time zone impacts display of data.

Email ID captures the user's email address.

Dashboard Width defines the number of pixels to use for the user's dashboard area. A setting of 200 is recommended as a minimum. Depending on the width of a user’s monitor, a higher setting (such as 250) will display more information without compromising the space on the main area of the application.

Home Page defines the page that appears when the user starts a session or clicks the Home link.

The To Do entry fields control how To Do entries are aged in respect of the “age bars” that appear on To Do Summary, To Do Supervisor Summary and the To Do Summary Dashboard Zone. Specifically:

- Use To Do Entries Less Than ___ Days Old Should be Green to define the number of days old a To Do entry must be less than to be considered “green” in the age bar.

- Use To Do Entries More Than ___ Days Old Should be Red to define the cutoff days after which a To Do entry is considered “red” in the age bar.

- Any To Do entry whose age isn’t “red” or “green” is considered “yellow” in the age bar.

The User Group collection defines the group(s) with which the user is associated and the date (if any) when the user's association expires. This feature is modifiable only when the page is accessed through the Admin menu. For more information, see The Big Picture Of Application Security. Assignments of users in a user group can also be established or maintained through the User Group - Users page.

Note: The ability to maintain the user groups on this page requires special field-level security. A user can change the field only if the System Administration access mode is set.

User - To Do Roles

Open the User page and then navigate to the To Do Roles tab to define the To Do roles assigned to the user.

The information on this page cannot be modified if accessed through My Preferences.

Fastpath: A user's To Do roles control the types of To Do entries the user can access. For additional information on To Do roles, see To Do Entries Reference A Role.

Description of Page

The grid contains the user's To Do roles. To modify a To Do role linked to the user, simply move to a field and change its value. To remove a To Do role, click the - (minus) button. To add a new To Do role, click the + (plus) button and enter the role.

Where Used

Every To Do entry references a role. A To Do role has one or more users (and a user may belong to many To Do roles). Users who are part of the To Do role assigned to a To Do entry may work on the To Do entry. For more information on this feature, see The Big Picture Of To Do Lists.

User - Access Security

Open the User page and then navigate to the Access Security tab to define a user's security rights. You cannot modify this page if you accessed it through My Preferences.

Fastpath: Refer to The Big Picture of Application Security for more information about data access roles and access groups.

Description of Page

Use the Default Access Group to define the access group that is defaulted on new records added by this user that are subject to row security.

The scroll area contains the Data Access Roles to which this user belongs. A user's data access roles play a part in determining the accounts whose data they can access. Refer to Access Groups, Data Access Roles and Users for more information.

To add additional data access roles to this user, click the + button and specify the following:

Enter the Data Access Role. Keep in mind that when you add a Data Access Role to a User, you are granting this user access to all of the accounts linked to the data access role's access groups.

Use Expiration Date to define when the user's membership in this data access role expires.

Note: You can also use Data Access Role - Main to maintain a data access role's users.

The tree highlights the Access Groups to which the above Data Access Roles provide access.

User - Bookmarks

This page is used to manage a user’s bookmarks that are created when a user clicks the Bookmark button and saves a bookmark. From this page the user can delete a bookmark, change the name of the bookmark or change the sort sequence.

Open the User page and then navigate to the Bookmarks tab to modify or delete a bookmark.

Description of Page

Sequence is the sort sequence associated with the bookmark. Bookmarks with the same sequence are then sorted alphabetically.

Name is the user-defined name assigned to the bookmark. This is the text that is visible in the Bookmarks dashboard zone.

Note: Favorite Links vs. Bookmarks. Favorite links are configured through the user page and define pages that a user can navigate to. They do not define context (although some pages may use information currently in global context when navigating). Some users may not be allowed to configure their own favorite links and would see the favorite links associated with a profile user. Bookmarks are created using a bookmark button available on each page. The bookmark saves navigation information, context information and also captures some information about the state of a page. Bookmarks are not governed by any user profile configuration.

User - Portal Preferences

The base product contains several portals that allow users to customize them via portal preferences. Portal preferences allow users to control:

- Which zones appear on the portal

- The order in which the zones appear

- Whether the zones should be "collapsed" (i.e., minimized) when the portal opens.

Note: You may not be able to change your portal preferences. If a note appears immediately before the list of portals, a system administrator has configured your user ID to reference a Portals Profile User ID (this is defined on the Main tab). Preferences set in this way cannot be modified. System administrators do this in order to enforce a common look-and-feel throughout the user community.

Open the User page and then navigate to the Portal Preferences tab to modify a user’s preferences.

Description of Page

The accordion contains a row for every portal configured to show on user preferences and to which you have access. To change how a portal's zones appear, expand the respective row and change the elements accordingly. The remainder of this section describes how you can configure how a portal's zones appear.

Zone lists all of the zones in the portal.

Place a check under Display if the zone should be displayed on the portal.

Place a check under Initially Collapsed if the zone should be minimized when the portal is initially opened. Setting zones as initially collapsed is a good idea to save space and to help pages to load more quickly. Refer to Zones May Appear Collapsed When A Page Opens for more information.

Use Sequence to control the position of the zone in respect of the other zones. This field is disabled if Display is not checked. Duplicate Sequence numbers are allowed.

For zones displaying data that is changing often, use Refresh Seconds to define in seconds how often the zone is refreshed. The minimum valid value is 15. The maximum valid value is 3600 (1 hour). A value of 0 indicates no automatic refresh.

Security Access indicates whether the user has access rights to a zone. Refer to Granting Access To Zones for more information.

User - Favorite Links

This page is used to define a user's favorite transactions and URLs. Each such link appears as an entry in the Favorite Links Zone in the Dashboard area.

Note: Ctrl + a number can be used to execute a favorite link. Rather than clicking a button in the favorite links zone, you can invoke your first nine favorite links by pressing Ctrl + a number (where the number corresponds with the relative position of the transaction in your list of favorites). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Open the User page and then navigate to the Favorite Links tab to modify a user’s favorite links.

Description of Page

Note: You may not be able to change your favorite links. If a Note appears beneath your User ID, your user id has been setup to reference a specific Favorites Profile User ID as defined on the Main tab. If a system administrator has setup your user ID in this way, your preferences may not be changed. System administrators may apply this feature in order to enforce a common look-and-feel throughout the user community.

Each row references a Navigation Option. The navigation options supplied with the base package correspond with the system's menu items. This means you can setup a favorite link to open any transaction in the system (in either add or update mode).

Note: Favorite links can point to other places. The navigation options supplied with the base package always open a transaction's Main tab. If you find yourself continually accessing a different tab page, you can have your implementation team create a new navigation option that references the desired tab page. Once this navigation option is set up, you can reference it as one of your favorite links. In addition, it's also possible for your implementation team to setup navigation options that open a URL outside of the system. For example, your implementation team could setup a navigation option to a credit rating company's website. Once this navigation option is set up, you can reference it as one of your favorite links.

Use a Sequence to control the order in which the navigation option appears in the Favorite Links Zone.

Security Access indicates if you have been given security rights to the respective transaction. Refer to The Big Picture Of Application Security for more information.

Note: Favorite Links vs. Bookmarks. Favorite links are configured through the user page and define pages that a user can navigate to. They do not define context (although some pages may use information currently in global context when navigating). Some users may not be allowed to configure their own favorite links and would see the favorite links associated with a profile user. Bookmarks are created using a bookmark button available on each page. The bookmark saves navigation information, context information and also captures some information about the state of a page. Bookmarks are not governed by any user profile configuration.

User - Favorite Scripts

This page is used to define a user's favorite scripts. Each script is displayed in the Favorite Scripts zone on the Dashboard portal where it can be used to initiate a script.

Note: Ctrl + Shift + a number can be used to execute a favorite script. Rather than selecting a script from the business process assistant, you can invoke your first nine favorite scripts by pressing Ctrl + Shift + a number (where the number corresponds with the relative position of the script in your list of favorites). Note that the numeric keypad on your keyboard cannot be used to implement this function.

Open the User page and then navigate to the Favorite Scripts tab to modify a user’s Favorite Scripts.

Description of Page

Note: You may not be able to change your favorite scripts. If a Note is displayed on top of the grid, your user id has been setup to reference a specific Favorites Profile User ID as defined on the Main tab. If a system administrator has setup your user ID in this way, your preferences may not be changed. System administrators may apply this feature in order to enforce a common look-and-feel throughout the user community.

Each row in the grid contains one of your favorite Scripts.

Use the Sort Sequence to control the order in which the scripts appear in the business process assistant menu.

Security Access indicates whether you have access to the script's application service. Refer to The Big Picture Of Application Security for more information.

User - Characteristics

Select Admin > User > Search and navigate to the Characteristics tab to define characteristic values for the user. You cannot modify this page if you accessed it through My Preferences.

Description of Page

Use the characteristics grid to capture additional information about the user.

You can only choose Characteristic Types defined as permissible for the user record. Refer to Setting Up Characteristic Types & Their Values for more information.

Enter a valid Characteristic Value for the selected characteristic type. You may enter more than one characteristic row for the same characteristic type, each associated with a unique Sequence number. If not specified, the system defaults it to the next sequence number for the characteristic type.

User - Miscellaneous

Select Admin > User > Search and navigate to the Miscellaneous tab to view additional information associated with a user.

User Id, First Name and Last Name are displayed. Depending on your implementation, additional zones may appear on the User Portal

If additional zones appear, use the inline help for information about the fields managed on the zone.

Initiating Scripts

Your implementation team can set up business process assistant (BPA) scripts to walk you through business processes. Once scripts have been set up, you can initiate a script using any of the following methods:

- You can define a list of your "favorite scripts" on your user preferences. You can then invoke any of the scripts from the Favorite Scripts zone on the dashboard portal. You can also invoke any of your first 9 favorites by pressing Ctrl + Shift + a number (where the number corresponds with the relative position of the script in your list of favorites). For example, if you press Ctrl+Shift+2 and you've setup your "favorite scripts" to be Start Autopay and Stop sending marketing information; the Stop receiving marketing information script is invoked. Note that the numeric keypad on your keyboard cannot be used to implement this function.

- You can configure a menu item to launch a script by referencing a navigation option that is a script navigation option type.

- The system creates To Do entries to highlight tasks that require attention (e.g., bills in errors, accounts without bill cycles, etc.). Users can complete many of these tasks without assistance. However, you can set up the system to automatically launch a script when a user selects a To Do entry. For example, consider a To Do entry that highlights a bill that's in error due to an invalid mailing address. You can set up the system to execute a script when this To Do entry is selected. This script might prompt the user to first correct the customer's default mailing address and then re-complete the bill. Refer to Executing A Script When A To Do Is Launched for more information.

- You can indicate that a script should be launched upon entering the system. This functionality enables an external system to launch the system and immediately launch a script.

- If you press Ctrl+Shift+S, an interactive menu is displayed:

The menu allows you to search for a script using any word in its description. Note, if you've turned on Search only Eligible Scripts, your search is limited to eligible scripts. Note, the system displays an indication if each script in the grid is Eligible or Ineligible in this section.

You can initiate a script from this area by clicking on it.

When a script is initiated, this menu closes and the object display area shifts down to make room for the script area.

Note: Securing scripts. Only scripts the user is allowed to execute are displayed. Refer to Securing Script Execution for more information.

Note: Customize the script area. Using the Height step type, an individual script may be configured to use more or less of the script area than the standard script area. It is also possible to configure a script to hide the script area altogether.

The information in the script area takes you through the steps in the selected business process (note, your implementation team controls the information that appears in the script area).

The following points highlight useful information common to all scripts:

- Return focus to script area. Often during a script the focus moves from the script area to another section of the page. For example, you might be required to fill in data for a new record being added. When you are ready to return to the script area, rather than using the mouse to return to the area, you can press Ctrl+Shift+F. The focus returns you to either the first available input field or to a "default" button if no input field is available.

- The Continue button. Many steps in a script ask you to click the Continue button when you're ready to restart a script. For example, a step may ask you to confirm a customer's automatic payment information and then click Continue when you're ready for the script to restart. Rather than using the mouse to click this button, you can press Ctrl+Shift+C.

- Selected button changes color. When you click a button in the script area, the button selected changes color so that you can easily see which option you selected.

Fastpath: Refer to The Big Picture Of Scripts for more information about scripts.

Note: You can abort a script at any time by clicking the red X button in the upper right corner of the script area (or by pressing Ctrl+Shift+X).

Accelerator Key Summary

The following table summarizes the keyboard shortcuts (hot keys) available in the system:

Note: It is possible that some of the following system accelerator keys may duplicate shortcuts, or hot keys, that are predefined within your browser. If this is the case, the browser’s functionality commonly takes precedence.

Accelerator Key

Function

Alt+B

Returns to the previous page on which you were working. This is the equivalent of clicking the Back button.

Ctrl+Alt+C

Clears the currently displayed object from the page. This is the equivalent of clicking the Clear button.

Ctrl+Alt+D

Creates a duplicate of the object being displayed. Equivalent to clicking the Duplicate button.

Alt+G

Returns to the most recent page that was displayed when the Back button was clicked. Equivalent to clicking the Forward button.

Ctrl+Alt+H

Opens a dropdown list of recently-visited pages, the equivalent of clicking the History button.

Alt+J

Minimizes the dashboard. It also expands the dashboard, if it was minimized.

Alt+K

Transfers you to To Do Entry - Main for the current item in the To Do list. Pressing Alt+K while on this page takes you to the first To Do entry on the list.

Alt+N

Displays the next entry in the search results. Equivalent to clicking Next Item .

Ctrl+Alt+P

Opens your User Preferences page. Equivalent to clicking the Preferences menu item.

Alt+P

Displays the previous entry in the search results. Equivalent to clicking Previous Item .

Ctrl+Alt+Q

Opens the business process assistant, where you can select a script that walks you through a business process.

Alt+R

Refreshes the page with the last saved version of the object being displayed in the page. Equivalent to clicking the Refresh button.

Alt+S

Saves any changes that you've made on the database. Equivalent to clicking the Save button.

Alt+X

Opens the To Do Summary.

Alt+Y

Displays the previous item in the To Do list. Equivalent to clicking the Previous To Do button in the Current To Do zone.

Alt+Z

Displays the next item in the To Do list. Equivalent to clicking the Next To Do button in the Current To Do zone.

Alt+Insert

Inserts a new row into an Editable Grid if the insertion point is in the grid. Equivalent to clicking the Insert button.

Alt+Delete

Removes a row from an Editable Grid if the insertion point is in the grid. Equivalent to clicking the Delete button.

Alt+F1

Invokes online Help for the application. Equivalent to clicking the Help button.

Alt+1 through Alt+9

These keys are only applicable when a Notebook is open. The shortcuts open the tab page whose relative position corresponds with the shortcut number. For example, if you press Alt+3 on a page with multiple tabs, the third tab is displayed. If there are more than nine tabs on a page, you must use the mouse or F2/Shift+F2 to display a tab. Note that you cannot use the numeric keypad for these shortcuts.

Ctrl+1 through Ctrl+9

Invokes the favorite link whose relative position corresponds with the shortcut number. For example, if you press Ctrl+3, the transaction for your third "favorite link" is invoked. Note that you cannot use the numeric keypad for these shortcuts.

Ctrl+Shift+C

If the current step in the Script area has a Continue button, this shortcut is equivalent to clicking Continue.

Ctrl+Shift+F

If the Script area is open and you are working on a different area of the page, this key returns focus to the script area. Focus returns to either the first available input field or to a "default" button if no input field is available.

Ctrl+Shift+S

Opens the business process assistant, where you can select a script that walks you through a business process.

Ctrl+Shift+X

If the Script area is open, equivalent to clicking the Close button in the script area.

Ctrl+Shift+1 through Ctrl+Shift+9

Invokes the favorite script whose relative position corresponds with the shortcut number. For example, pressing Ctrl+Shift+2 selects the second of your "favorite scripts". The numeric keypad cannot be used for these shortcuts.

Alt+left arrow

Populates an scroll area with the previous entry. Equivalent to clicking the scroll control .

Alt+right arrow

Populates an scroll area with the next entry. Equivalent to clicking the scroll control .

Enter when in a field with an adjacent Go Look button

Invokes the search. Equivalent to clicking the Search button.

Enter when in a field with an adjacent Search button

Invokes the search. Equivalent to clicking the Search button.

Enter when a row in a search result grid is highlighted

Selects the item and closes the search. Note that after selecting an item from the search results, you can press Alt+N or Alt+P to scroll up or down through other items in the result grid without returning to the search results.

Enter when a menu item is highlighted

Selects the menu item.

Enter when the insertion point is within a tree node

Equivalent to clicking on the item in the tree:

- If the insertion point is on a node image, the node is either expanded or collapsed, dependant on its current state.

- If the insertion point is on a context menu, the context menu is opened and normal menu processing applies.

- If the insertion point is on a "link" element, normal navigation processing occurs.

Tab when a row in a search result is highlighted

Highlights the next row.

Space when the insertion point is on a button

Equivalent to pressing the button.

Space when the insertion point is in a date/time field

opens the date/time selection window.

Space when the insertion point is in a check box

Toggles the check box between checked and unchecked.

Page Up while in a list grid

Scrolls the contents of the list grid up approximately one page.

Page Down while in a list grid

Scrolls the contents of the list grid down approximately one page.

up/down Arrow when in a dropdown list

Moves to the next or previous value in the list. You can also press a letter key to locate the next value starting with that letter.

up/down Arrow keys when in search results

Highlights the next/previous row in search results.

up/down/left/right Arrow when using a menu

Highlights other menu items.

F2

Opens the next tab page when a Notebook is open.

Shift+F2

Opens the previous tab page when a Notebook is open.

Portal and Zone Features

This section describes using portals and zones to find and display information. This is the preferred technique used by the base product for query and maintenance dialog.

Additionally, portals and zones may be configured by your implementation to supplement the base package provided functionality.

Next in This Section

- Zone Types and Characteristics

- Common Base Portals and Zones

Zone Types and Characteristics

The topics in this section describe common zone types, function, and common characteristics.

Fastpath: Refer to The Big Picture of Portals and Zones for a description of general portal and zone functionality.

Next in This Section

- Explorer Zones

- Map Zones

- Common Characteristics of Zones

Explorer Zones

The product provide several zone types that are used to find or display a set of information. These are called explorer zones. There are two types of explorer zones:

- Info zones. An info zone displays a list of information about an object. These types of zones often display information without requiring any input from the user.

- Query zones. A query zone allows users to find objects matching a given search criteria.

Virtually every aspect of an info or query zone is controlled by its zone configuration. However, most share basic common components described in the subsequent sections.

Next in This Section

- Search Criteria / Filter Area

- Description Bar

- Results Area

- Title Bar

- Configurable Columns

- Multi-Query Zones

Search Criteria / Filter Area

For query zones, the Search Criteria Area (also called Filter Area) contains the criteria used to find objects. The design of the zone controls the number and type of filters that appear in this area. After search criteria is entered, clicking the Search button causes the system to look for records that match the criteria. The results are shown in the Results Area.

For info zones, the zone’s configuration indicates whether or not a Filter area is applicable and if so, whether or not it is open or closed by default. If the filter area is configured, the Show Filter icon is visible in the zone header. Click this icon to expose the Filter Area, if it is not visible and click the icon to hide the Filter Area if desired. Use this area to filter the information that appears in the zone by different values. Click the Search button to rebuild the Results Area using the specified filters.

For example, the following shows an info zone listing user groups that do not have access to a given Application Service where a filter area has been configured to allow users to show user groups specific to a given user by ID or name.

The info zone includes configuration to indicate whether the filter area, when exposed, should be shown at the top of the zone (above the results) or at the bottom of the zone (below the results). For query zones, the search criteria is always displayed at the top.

Note: Press Enter. Rather than clicking the Search button, you can press Enter to trigger the search / info zone refresh.

Description Bar

The Description Bar describes the search criteria that were used to build the Search Results Area.

Results Area

The Results Area displays the appropriate list of objects. For an info zone, this is the list of appropriate objects with any input filter criteria considered. The following is an example of the results for an info zone. For a query zone, this is the list that matches the search criteria defined in the Filter Area. The following is an example of the results set of an Info Zone.

For a query zone, the columns that appear may differ depending on the search criteria. For example, if you search for a customer by their driver's license number, the resulting columns may be different than the ones displayed when you search by customer name.

The following points highlight details related to viewing and working with the result set:

- Broadcast. If the results set is configured to display a broadcast icon, , it means that at least one other zone on the portal is configured to display data related to the record selected in the results list. Clicking this icon will cause the other zone or zones to be built or refreshed to display related data.

- Hypertext. One or more columns in the zone may be configured as hypertext. Clicking the hypertext will result in navigating to another page to display data related to that column based on the configuration for that column.

- Maximum height. The maximum height of the report area is controlled by the zone's configuration. A vertical scroll will appear when more rows exist than fit into the height.

- Maximum rows. The maximum number of rows that can appear is controlled by the zone's configuration. Excess rows are truncated before display. Please note, you can configure the zone to download more rows to Excel than appear in the Results Area.

- Control column sorting. By default zones are designed to allow a user to sort the results list by clicking any column heading. Clicking once sorts ascending. Clicking again sorts descending. However, a zone may be configured to not allow this type of sorting.

- Rearranging columns. A zone may be configured to allow a user to rearrange columns and add or remove columns visible in the Result Area. Refer to Column Configuration for the details.

The type and variety of columns that appear in the Results Area is controlled by the zone's configuration. You can even set up an info zone to display information in hierarchical trees. For example, the following info zone from Oracle Utilities Customer Care and Billing has been configured to show a person’s related persons.

Title Bar

The Title Bar contains the zone's description along with other icons and functions described in this section.

In the corner of the Title Bar, you'll see an indicator that tells you whether the zone is collapsed (e.g., minimized) or expanded. Each time you click the indicator, the zone toggles between expanded and collapsed. The following image shows a collapsed zone.

Note: Recommendation: For zones that are configured to show on portal preferences, set up Portal Preferences to collapse zones that aren't needed every time a portal is displayed. Rationale: The system doesn't build collapsed zones when a portal is displayed. Instead, collapsed zones are only built when a user expands them. Thus, indicating a zone is collapsed improves response times.

If the zone is configured with help text, a help icon appears to the right of the zone title. Click this icon to view the help text.

If a saved search is open for a zone, the name of the saved search is displayed after the zone title.

The following sections describe additional icons and tools visible on the title bar. Note that in addition to the information described in this section, additional actions that are specific to a zone may appear based on configuration. The actions may appear in the form of hypertext, an icon or a button.

Next in This Section

- Explorer Zone Menu

- Show Filters

- Show Column Configuration Area

- The Open Zone Maintenance Icon

Explorer Zone Menu

Click the Explorer Zone Menu icon to list available tools. The following topics describe each tool.

Next in This Section

- Clear Filters

- Export to Excel

- Print

- Reset Zone

- Save Search Options

Clear Filters

Click the Clear Filters link in the Explorer Zone menu to clear the filter values and zone data.

Export to Excel

Click the Export to Excel link in the Explorer Zone menu to download the zone's data to Excel. This link is hidden if the zone has been configured to not download rows to Excel.

Print

Click the Print Zone link in the Explorer Zone menu to print the zone.

Reset Zone

Click the Reset Zone link in the Explorer Zone menu to reload previously saved zone preferences from the database.

Save Search Options

Query zones and info zones that include filter areas, allow a user to capture and save filter criteria so that the same search can be more quickly executed in the future. Users may save many different search options for the same zone. Users also have the option to nominate one search as the default so that this search is automatically loaded upon entering the zone. In addition, users may choose to set one or more searches as a Favorite, which causes the search to appear in the Favorite Searches zone in the dashboard. This allows a user to navigate to the portal for that zone and load the saved search in one click.

The Explorer Menu includes various options for supporting Saved Searches that are described below.

Note the following additional points about this functionality:

- Click Search before Saving. When a user wants to save a search, the search criteria should be entered and the Search button should be clicked prior to saving the search.

- Criteria is saved, not results. Although a user must click Search prior to saving the search, the system saves the criteria, but not the results. When returning to the query or info zone in the future and opening a given saved search, the results displayed will be the current records in the system that match the saved search criteria.

- Multi-Query Zones. When a user is on a multi-query zone, the searches are saved at the multi-query zone level so that all saved searches for the various search dropdowns for a given multi-query zone are visible in the Open Saved Searches menu option.

- Functionality is Secured. If for any reason an implementation wishes to restrict which users are allowed to save searches, the functionality is securable. Only users with Inquire access to the F1_USRFAVSCH application service will see these options in the explorer menu. This is the same application service that is used to provide access to the Favorite Searches dashboard zone.

Next in This Section

- Save As

- Open Saved Search

- Save

- Set As Default

- Remove As Default

- Add To Favorites

- Remove From Favorites

- Delete

Save As

The Save As... option in the Explorer Zone menu allows a user to save the current entered search criteria. This should be clicked after executing the search.

The user is prompted to provide a name for the search. This search is now available from the Open Saved Searches option. If desired, a user can also choose to make this search the Default or may choose to Add to Favorites.

This option is visible whether or not an existing saved search is loaded. When a saved search is loaded, this option allows a user to make changes to the search criteria and save a new search with that criteria.

Open Saved Search

The Open Saved Search... option in the Explorer Zone menu is visible if there are any saved searches for the zone that is currently visible. Select this menu entry to view the current list of saved searches for the zone. For multi-query zones, any saved search for any of the query zones that are part of the multi-query zone are visible. Choose the desired saved search. The criteria is updated with this information and the search is performed.

Save

The Save option in the Explorer Zone menu is visible if a Saved Search is already loaded. This option allows a user to save changes to the criteria of an existing saved search (overwriting the previously saved criteria).

Set As Default

The Set As Default option in the Explorer Zone menu is only visible if a saved search is loaded and it is not currently the default. Click this option to nominate this search to be the one that is loaded when navigating to this zone from the menu.

Remove As Default

The Remove As Default option in the Explorer Zone menu is only visible if a saved search is loaded and it is currently the default. Click this option to no longer load this search automatically when navigating to this zone from the menu.

Add To Favorites

The Add To Favorites option in the Explorer Zone menu is only visible if a saved search is loaded and it is not currently included in the favorite searches zone. Click this option to include this search in the Favorite Searches zone. Once a search is in the Favorite Searches zone, you can use the link to the search in the dashboard to navigate to the portal for this zone and load the saved search in one click.

Note: Not available for dependent zones There are some portals that include a zone that is not the main query or info zone on the portal, but is rather a zone providing additional information for a record that is displayed. If a zone like this has filter options or configurable columns, a user is able to save searches and mark one as a default, but will not be able to add the saved search to favorites because the zone is dependent on other data on the page that is not captured for the individual zone.

Note: Dashboard Zone Preferences. Be sure that your portal preferences are configured to include the Favorite Searches dashboard zone.

Remove From Favorites

The Remove From Favorites option in the Explorer Zone menu is only visible if a saved search is loaded and it is currently included in the Favorite Searches zone. Click this option when you want to keep the saved search but you no longer want it visible in your Favorite Searches zone. (Deleting a saved search that is also marked as a favorite will automatically remove the search from the favorite searches zone.)

Delete

The Delete option in the Explorer Zone menu is only visible if a saved search is loaded. Click this option to remove the currently opened saved search from the list of saved searches.

Note that if the saved search had been configured as favorite, deleting the saved search remove it from the favorite searches zone.

Show Filters

Click the Show Filters icon to show the Filter Area. This button only appears if the zone has been configured to have filters.

Note: If the zone is configured to have filters and the drag and drop (column configuration) area, only one or the other is shown at any given time. It means that a user can either change the filter criteria and refresh the search results or change the column configuration and refresh the results.

Show Column Configuration Area

Click the Column Configuration icon to show the Column Configuration Area. This button only appears if the zone has been configured to allow columns to be dragged and dropped into the Results Area.

Note: If the zone is configured to have filters and the drag and drop (column configuration) area, only one or the other is shown at any given time. It means that a user can either change the filter criteria and refresh the search results or change the column configuration and refresh the results.

The Open Zone Maintenance Icon

Click the "wrench" icon to switch to the zone's zone maintenance page. On this page, you can change the parameters that control the zone's behavior.

Note: Debug mode only.  This icon only appears when the system operates in Debug mode.

Configurable Columns

Info zones and query zones may be configured to allow users to rearrange columns and to remove or add columns to the output. This is also referred to as “drag and drop” of columns.

When a zones is configured to support this functionality, the Show Column Configuration Area icon is visible in the zone title area. Click this icon to expose the Column Configuration Area, if it is not visible and click the icon to hide the Column Configuration Area if desired.

If configurable columns are allowed, a user may rearrange the order of columns currently displayed in the Results Area by clicking the column heading and “dragging” it to the desired location.

In addition, the column configuration area may display columns that are not currently in the Results Area. These are indicated by a cream background. A user can drag one of these columns to the results area and then click Refresh to rebuild the zone. To remove a column that is currently in the results area, click the trash can icon next to the column name in the column configuration area and then click Refresh to rebuild the zone.

The following is an example of how the Column Configuration Area looks:

Multi-Query Zones

This type of zone combines individual Query Zones into a single query zone. A Search By dropdown, built from the zone descriptions of the individual Query Zones, allows you to select the desired query to execute. Selecting a specific Query Zone display the filters of that query in the filter area. At this point the zone simply executes the selected Query Zone, as if it was executed on a standalone zone. By default, the first query zone option is selected.

Map Zones

A map zone displays information related to one or more objects. For objects that are maintained using portal-based pages, the standard display of the object is using a map zone. Map zones may be configured to display an explicit map or may dynamically display the map based on the configuration of the record being displayed.

Because the information displayed in a map zone is configured using HTML, virtually any format supported by HTML is possible. The following is an example of a typical map zone used to display information about an object.

A tool tip can be used to display additional help information for the details shown in a map zone. The tool tip may appear adjacent to the section header or adjacent to individual elements on a map.

Note: You can customize the help icon or disable map help using the Custom Look and Feel feature configuration.

Next in This Section

- Open Map Maintenance Icon

Open Map Maintenance Icon

Click the "hammer" icon to switch to the UI map maintenance page. On this page, you can view the HTML configuration for the zone. Note that for map zones that display a business object configured without a map, the elements displayed are automatically rendered. In this case, no “hammer” icon is visible.

Note: Debug mode only.  This icon only appears when the system operates in Debug mode.

Common Characteristics of Zones

The following topics describe common characteristics of all zone types supported by the base package.

Next in This Section

- Zone Visibility

- Control Zone Headers

Zone Visibility

A zone may be configured to dynamically be visible or completely hidden depending on the information being displayed. When hidden not event the header is displayed. Refer to the common Zone Visibility Service Script parameter for further details.

Control Zone Headers

A zone may reference a UI Map to define and control its header. This feature provides the means to achieve a uniform look and feel for the application as well as add functionality to the zone header beyond being just a title bar to open and close the zone. Refer to UI Map and to its context sensitive tips zone for more information on Fragment UI Maps and how they are used to construct zone headers.

Common Base Portals and Zones

The following sections describe common standards followed by the product for base query and maintenance dialogue.

Next in This Section

- All-In-One Portal

- Separate Query and Maintenance Portals

All-In-One Portal

The all-in-one portal is used for low volume objects, where a small number of records are expected.

For example, many control tables use this style of portal. In this portal, rather than separate query and maintenance portals, a single portal allows a user to find a record and maintain the record. A zone listing all existing records is displayed when first entering the portal. A user can perform actions on existing records or add new records from there. More details about the list zone are provided below.

Refer to Maintenance Portal for information about zones commonly found on maintenance portals.

The all-in-one portal will typically provide the ability to add a new record. This may be a button in the Page Action area or a hyperlink defined directly on the list zone’s header area.

Next in This Section

- List Zone

List Zone

This info zone appears when first entering the portal and displays a row for each record.

The following functions are commonly available in a list zone:

- A broadcast icon is included in each row. Clicking this icon opens other zones that contain more information about the adjacent record.

- An Edit icon may be included in each row. Clicking this icon launches the maintenance BPA script to modify the adjacent record.

- A Duplicate icon may be included in each row allowing the user to duplicate the adjacent record without having to first display the record.

- A Delete icon may be included in each row allowing the user to delete the adjacent record without having to first display the record.

- If the record has a simple BO lifecycle of Active and Inactive, the list zone may include a button to Activate or Deactivate the adjacent record.

Separate Query and Maintenance Portals

For high volume objects where more sophisticated search criteria is needed to find a particular record, separate portals are provided to search for the record and to maintain it.

The query portal contains a zone to search of the object that you wish to maintain. Additional information about the query portal's search zone is provided below. Clicking an appropriate record in the search results navigates to the object's stand-alone maintenance portal.

The query portal will typically provide the ability to add a new record. This may be a button in the Page Action area or a hyperlink defined directly on the list zone’s header area.

Next in This Section

- Query Portal Search Zone

- Maintenance Portal

Query Portal Search Zone

The query portal contains one zone used to search for the object.

The zone may be a standard query zone or may be a multi-query zone providing one or more ways to search for your record.

Once the search results are displayed, click on the hypertext for the desired record's information string to navigate to the stand-alone maintenance portal.

Maintenance Portal

A maintenance portal refers to a page that is used to view and maintain a specific record. These types of records are governed by a business object, which defines the user interface layout for both the display of the record and the add or update of the record.

An all-in-one portal is a type of maintenance portal, once a record has been broadcast from the list zone. For the separate query and maintenance portal dialogue, the maintenance portal includes only zones relevant for the specific record selected.

Maintenance portals may have multiple tabs to display information relevant for the object. Often, if the object has a Log, the log is on a separate tab. (Although there may be some maintenance portals that include the log zone on the Main tab.)

The stand-alone maintenance portal is typically configured with the ability to navigate back to the query portal using either a Search button in the Page Actions area or using a Go To Search hyperlink in the main zone’s header area. The stand-alone maintenance portal may also include the ability to add a new record using an Add button in the Page Actions area. (If not, a new record can be added by navigating through the menu or by navigating to the query portal where an Add hyperlink may be found.

The following zones are common to portals used to maintain a record.

Note that additional zones may exist for specific all-in-one portals or stand-alone maintenance portals based on the particular functionality. Refer to the documentation for each portal to understand the specific zones that are provided.

Next in This Section

- Object Display Zone

- Log Zone

Object Display Zone

This is a zone that displays the object being maintained.

An object being displayed may or may not allow for actions or updates to be made. Typically there is a Record Actions section in the display area that presents the valid actions. Depending on the functionality, the actions may prompt the users to input values required for that action.

Log Zone

If the maintenance object for the record includes a status, it typically has a log that records important events in its lifecycle.

This log is shown in an info zone on the portal, either on the Main tab or on a separate Log tab. A link appears in the zone's title bar to allow the user to add a new manual log entry.

Taxpayer Information

We use the term taxpayer information to reference the demographic, geographic, and financial objects that form the core of your system. In this section, we describe how to maintain these objects.

Next in This Section

- Understanding the Account Model

- 360 Degree Search and View

- Dashboard Portal

- Maintaining The Account Model

- The Big Picture Of Customer Contacts

- Appendix A - Legacy Functionality

Understanding the Account Model

The "Account Model" consists of four objects that form the core of the system: Person, Account, Tax Role and Obligation. These objects hold demographic and financial information about your taxpayers. In addition, the Address object provides a means of storing a centralized repository of addresses that may be linked to various objects.

In this section, we provide an overview of these objects. In later sections, we describe how you maintain this information.

Next in This Section

- Persons

- Accounts

- Tax Roles

- Obligations

- Assets

- Addresses

Persons

A person exists for every individual or business with which your company has contact. Besides taxpayers, persons exist for contractors, accountants at corporate taxpayers, third party guarantors, collection agencies, etc.

On a person is maintained demographic information like Name, Mailing Address, Phone Numbers, Email Address, etc.

Most persons are linked to at least one account because, without an account, the person cannot have financial interactions with the tax authority.

Fastpath:

Refer to Maintaining Persons for more information about persons.

Accounts

Accounts are the entities for which financial interactions happen. These can include, returns, bills, and payments. You must create at least one account for every taxpayer. The account contains information that controls how returns, bills, and payments are created and handled.

Every account must reference at least one person because the person contains the taxpayer's demographic information (e.g., names, phone numbers, forms of ID). We refer to this individual as the "main" person linked to the account. In addition to the "main" person, an account may reference other types of persons, e.g., the billing contact, power of attorney, accountant, etc.

Most accounts are linked to at least one tax role because the tax role captures information related to a specific tax type that is applicable to the account.

Most accounts are linked to at least one obligation because, without an obligation, there is no ability to assess a taxpayer. An account without an obligation may exist; you just won't be able to do much in the system with such an account.

Fastpath:

Refer to Maintaining Accounts for more information about accounts.

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.

The tax role often governs the filing calendar that dictates the filing periods for which the taxpayer is obliged to file. For every filing period that the taxpayer is expected to file a return for this tax type, an appropriate obligation must be defined for this account and tax role.

Fastpath:

Refer to Maintaining Tax Roles for more information.

Obligations

Think of an obligation as a contract between the tax authority and the taxpayer. For example, a corporate entity has certain contractual responsibilities between themselves and the tax authority. These responsibilities are tracked through the obligation. Some tax authorities refer to an obligation as a filing period or tax period. Every account should have at least one obligation (otherwise, the account has no financial obligations with your tax authority). There is no limit to the number of obligations that may be linked to an account.

Every tax role should have at least one obligation. Note that obligations are not required to have a tax role. Configuration on the obligation type's tax type controls whether a tax role is required.

Refer to Maintaining Obligations for more information.

Assets

An asset is used to track tangible assets for business or an individual.

Fastpath: Refer to Asset for more information.

Addresses

Addresses are captured in a centralized address repository. Other objects in the system can then reference a record in the address object to indicate an association with that address. The following points highlight base product functionality that includes support for address links.

A person may reference one or more addresses of different types. The link to address is effective dated. In addition, the person can identify seasonal addresses.

A tax role may define one or more addresses of different types. The link to address is effective dated. Configuration allows for the implementation to designate required address types for a given tax type and an indication of whether multiple addresses of the same type are allowed.

An Asset may require a billing address if calculations on the bill for the asset differ by a geographic based identifier.

Note: This functionality is not applicable for implementations that continue to use legacy addresses.

360 Degree Search and View

The topics in this section describe the 360 Degree Search and View portals.

Next in This Section

- 360 Degree Search

- 360 Degree View

360 Degree Search

The 360 Degree Search allows users to search for accounts using a variety of search criteria. Navigate using Menu > 360 Degree Search.

The following topics provide additional information about the searching capability provided in the product.

Search by Person

The person search allows a user to find an account via persons linked to the account using a combination of Name and ID Type / ID Number. Please note the following about the search criteria:

- A Search Type appears adjacent to the name if your implementation has enabled fuzzy searching. If this is visible, choose the desired name searching technique. Standard search uses the type of searching available throughout the product with wildcard search capability. Fuzzy searching that relies on special indexes configured in the database to attempt to resolve alternate spellings or simple keying errors.

- The user may optionally enter a Tax Type in addition to the name or ID search values. This is useful when the user knows the tax type whose details need to be viewed.

The search results show a row for every account that has a person matching the name / ID search criteria. Note the following about the search results:

- Account security is applied. Users will not see any results for persons that are linked to accounts they do not have access to.

- If Tax Type is provided in the search criteria, the results are limited to accounts that have persons matching the name / ID search criteria and have a tax role for this tax type. The information about the match Tax Roles are displayed in the search results.

- The person's name is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Person tab.

- The account's information is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Account tab.

- If a tax type is provided in the search criteria, the tax role information is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Tax Role tab.

Search by Account ID

The account search allows a user to find an account directly using its account id. The search results show a row for every person linked to the account and its name and ID number:

- Account security is applied. Users will not see any results if they do not have security for the account entered.

- The person's name is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Person tab.

- The account's information is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Account tab.

Search by External Tax Role ID

Many tax authorities provide taxpayers with external identifiers for each tax role. The external tax role search allows a user to find an account by providing the external id for one of its tax roles. The search results show a row for every person linked to an account that has a tax role with that external id.

Note: More than one tax role may exist for the same external tax role ID, depending on the business requirements. The base product provides validation when creating a tax role that the external id is unique within a given tax type for a given effective period.

- Account security is applied. Users will not see any results if they do not have security for the account entered.

- The person's name is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Person tab.

- The account's information is displayed as hypertext. If clicked, the user is brought to the 360 Degree View - Account tab.

Search by Address

The address search provides the ability to search for an address by main address constituent fields. For any matching address found, the results display any related persons, tax roles or assets. Users may drill into the address to view more detail or may drill into any of the related objects.

By default only active addresses are displayed. A user may opt to include inactive addresses in the search.

Search by Asset

The asset search provides the ability to search for an asset by its ID or external identifier. The search results display a row for each asset that matches the search criteria.

360 Degree View

The 360 Degree View allows users to view data for persons, accounts, tax roles and obligations from a single set of portals. The following topics provide additional detail for each portal tab provided.

Next in This Section

- 360 Degree View - Main

- 360 Degree View - Account

- 360 Degree View - Tax Role

- 360 Degree View - Financial

360 Degree View - Main

This main tab of 360 Degree View displays information about the Person in context. You can navigate to this zone in one of the following ways:

- After searching for a person or account in the 360 Degree Search, clicking on the Name column in the results brings you to this tab.

- If a person is in context, you may use the Go To 360 Degree View in the person's context menu to navigate here.

The tab contains the following base zones:

- Person Overview: displays the person's name, their primary id, any alias names, phone numbers and email address.

- Person Tree: displays various information related to the person in tree format. For example, it displays the person's accounts, the account's tax types, and the tax roles for each tax type. It also shows any related persons and addresses related to the person or tax role.

- Accounts: displays a list of all the accounts to which this person is linked. Only accounts that the current user has security access to are shown.

- Click the broadcast button to broadcast this account to other zones.

- Click the 360 button to navigate to the Account tab to view data for this account. If this account is not the one displayed in the dashboard, the dashboard is refreshed with this account.

- Related Assets Tree: displays assets where this person is a current owner or where this person is linked as a related person.

360 Degree View - Account

Use the Account tab to view account related information. You can navigate to this zone in one of the following ways:

- After searching for a person or account in the 360 Degree Search, clicking on the Account column in the results brings you to this tab.

- If an account is in context, you may use the Go To 360 Degree View in the account's context menu to navigate here.

- From the main tab of this portal, there is a zone that lists accounts for the displayed person with a 360 button adjacent to each. Clicking that button broadcasts that account and brings the user to this tab.

The tab contains the following base zones:

- Account Overview: displays the person information for the account's main person, the account's information string and its current overall balance.

- Addresses: displays all the possible addresses currently linked to the account or its main person. Note that this functionality is only applicable for implementations that support legacy addresses. If addresses are defined on the Person record using the mailing address or miscellaneous address collection, each address is shown along with an indication of the type. If the account defines a mailing location, that address is shown. If an address is defined in the Account / Person definition, that address is shown.

- Account Tree: displays various information related to the account in tree format. It displays the persons linked to the account. It displays tax roles for the account grouped by tax type. for each tax role, any non-closed, non-canceled obligations are displayed.

- Tax Roles: displays a list of the tax roles linked to this account.

- Click the broadcast button to refresh other zones for this tax role.

- Click the 360 button to navigate to the Tax Role tab to view data for this tax role. If this tax role is not the one displayed in the dashboard, the dashboard is refreshed with this tax role.

Note that only the first 50 tax roles are displayed. If an account has more than 50 tax roles, a user may open the filter to search for specific tax roles using various criteria.

- Active Collections: displays active collections for the account. It lists the following active events: Overdue Processes, Collection Case, Pay Plan, Agency Referrals and Suppressions.

- Form History: displays a list of the most recent 24 tax forms for the account. If an account has more than 24 tax forms, a user may open the filter to search for specific tax forms using various criteria.

Your configuration may also configure one or more timeline zones that allow you to view various events that occur in the same time period. Various base timeline algorithms are provided to display account related information such as Payment Events, Audit Cases, Suppression, Appeals, Collection Cases and Tax Forms. Refer to Configuring Timeline Zones for more information. See below for functionality available in timeline zones.

Next in This Section

- Timeline Zone

Timeline Zone

Timeline zones show when significant events have occurred in the past and when significant events will occur in the future. For example, a timeline can show when payments and forms have been received for a taxpayer.

The topics in this section describe the rich functionality available in timeline zones.

Timelines Zones Are Configured By Your Implementation Team

Your implementation team controls the number and type of timeline zones you see on this page. Refer to Configuring Timeline Zones for how to add and change timeline zones.

The Anatomy Of A Timeline Zone

The following illustration highlights the various elements in a timeline zone. These elements are described in the remaining topics.

You Can Move Through Time

You can click the controls at the top of a timeline zone to change the date-range of the zone's information:

The following points describe how to use these controls:

- To reposition the timeline to a specific date, selected the desired month and year and click the search button.

- To go back one year, click the double-left arrow.

- To go back one month, click the single-left arrow.

- To go to today, click the red line (between the arrows).

- To go forward one month, click the single-right arrow.

- To go forward one year, click the double-right arrow.

Timelines Can Have Many Lines

A timeline zone has one or more "lines" that show when significant events have occurred. For example, you can set up a timeline zone that has two lines: one that shows when payments have been received from a taxpayer, and another that shows when forms have been received from he taxpayer. Your implementation team controls the number and type of lines by configuring the timeline zone accordingly.

Each Line Shows Events

Each line on a timeline may contain zero or more events where each event shows the date when the event occurs. For example, the tax form line in a timeline has a separate event for every tax form received for the taxpayer. Each line's description contains the number of events on the line.

CAUTION:

If a line has more events than can fit onto a timeline, the line will show the first "chunk" of events and a message will appear in the "more info area" explaining that some events have been truncated. If this happens and the truncated events are in a latter period, you can reposition the timeline's base period to show the truncated events. Refer to the You Can Move Through Time section above for more information

An Event's Color And Icon Can Convey Information About The Event

Your implementation team can configure the timeline so different types of events have different visual representations. For example, a timeline that shows when audit cases have occurred can use different colors and/or icons to visually differentiate between fraud related audit cases vs. other types of audit cases.

An Event's Hover-Text Can Contain Additional Information

If you hover the mouse over an event, hover text appears. Each type of event can have different hover text. For example, the hover text for an audit case shows significant dates in the audit case's lifecycle (e.g., when it was created, and when it was closed).

Clicking On An Event Shows More Information In The Detail Area

When you click on an event, additional information appears in the zone's detail area (at the bottom of the zone). The following information may appear:

- The event's common "information string" appears. For example, if you click on a tax form event, the tax form's information string appears. This information is hyperlinked to allow for easy access to the transaction on which the object is maintained.

- Additional information may appear. This is dependent on the particular timeline algorithm. Refer to each timeline algorithm's description to find out if additional information appears in the detail area under any conditions.

- If the algorithm has configured BPA scripts that can be executed to perform business processes on the object, the BPA script description appears prefixed with a "wizard's hat" icon.

360 Degree View - Tax Role

Use the Tax Role tab to view tax role and obligation related information. You can navigate to this zone in one of the following ways:

- When using 360 Degree Search and searching by external tax role or by person information and including tax type in the search criteria, clicking on the Tax Role column in the results brings you to this tab.

- If a tax role is in context, you may use the Go To 360 Degree View in the tax role's context menu to navigate here.

- From the account tab of this portal, there is a zone that lists tax roles for the displayed account with a 360 button adjacent to each. Clicking that button broadcasts that tax role and brings the user to this tab.

The tab contains the following base zones:

- Tax Roles: displays a list of the tax roles linked to this account. This zone is the same one visible on the Account tab and is included here to provide an easy way to choose a different tax role to view for the account. In this tab, the broadcast button and the 360 button provide the same functionality: the data for this tax role becomes visible in the subsequent zones. In addition, the dashboard context is refreshed with this tax role. Note that only the first 50 tax roles are displayed. If an account has more than 50 tax roles, a user may open the filter to search for specific tax roles using various criteria.

- Tax Role Overview: displays the person information for the account's main person, the account's information string, the tax role's information string and its current overall balance.

- Related Persons: displays a list of the persons with effective relationships for the tax role. The relationship type, financial relationship type and start date and end date are displayed.

- Form History: displays a list of the most recent 24 tax forms for the tax role. If a tax role has more than 24 tax forms, a user may open the filter to search for specific tax forms using various criteria.

- Obligations: displays a list of non-canceled obligations linked to this tax role. Note that only the first 50 obligations are displayed. If the tax role has more than 50 obligations, a user may open the filter to search for specific obligations using various criteria. Click the broadcast button to broadcast data about a specific obligation to other zones for the portal.

- Obligation Overview appears if a specific obligation has been broadcast from the Obligations zone. It displays the obligation information string, the current overall balance, the filing period due date (if applicable) and override due dates, if populated.

Your configuration may also configure one or more timeline zones that allow you to view various events that occur in the same time period. Various base timeline algorithms are provided to display tax role related information such as Payment Events, Audit Cases, Suppression, Appeals and Tax Forms. Refer to Configuring Timeline Zones for more information.

Next in This Section

- Timeline Zone

360 Degree View - Financial

Use the Financial tab to view financial information about the person, account and tax role. You can navigate to this zone by clicking on the tab from any other tab in the portal

The tab contains the following base zones:

- Credit Allocation. See below for more detail.

- Financial History: displays financial transaction details for the account in context.

Next in This Section

- Credit Allocation Detail Zone

Credit Allocation Detail Zone

The Credit Allocation Detail zone shows the results of dynamic credit allocation of a person or one of its accounts, tax roles, obligations or assessments. It also allows a user to bring P&I up to date and to forecast P&I to the current date or in the future.

Note:

An obligation that supports dynamic credit allocation must reference a Determine Detailed Balance algorithm.

- Check Include Closed Obligations to include the detail of the closed obligations in the Display Allocation mode. This switch is not applicable when forecasting or updating P&I.

- Use the Account dropdown and click Display Allocation to restrict the information for a specific account for the taxpayer.

- Use the Tax Role dropdown and click Display Allocation to restrict the information for a specific tax role for the account. An option of No Tax Role Grouping is shown in the tax role dropdown if there are any obligations that support dynamic credit allocation but do not reference a tax role.

- Use the Obligation dropdown and click Display Allocation to restrict the information for a specific obligation. The list of obligations is based on the selection in the tax role dropdown. It includes closed obligations only if Include Closed Obligations has been checked.

- Use the Assessment dropdown and click Display Allocation to restrict the information for a specific assessment for the obligation. An option of No Assessment Grouping is shown in the assessment dropdown if there are any debit financial transactions that are not related to a specific assessment.

Click Forecast P&I to forecast P&I up to the Forecast Date for the display level selected. The date must be on or after the current date and is only applicable for the Forecast P&I button. The date is ignored and reset if the Display Allocation or Update P&I buttons are clicked.

Click Update P&I to bring P&I up to date to the current date for the selected level. The button is not available if the user has drilled down to an assessment because P&I is calculated for the whole obligation.

A message above the grid provides information about the data displayed in the grid. It indicates the Id of the level selected for display (person, account, tax role, obligation or assessment).

- If the data displayed is the allocation details or the result after updating P&I, the message indicates the "Calculated through" date; the last date that penalty and interest was calculated. If the display is for the person, account or tax role and the obligations have different Calculate Through dates, the message indicates this.

- If the data displayed is forecasted P&I, the message indicates the date to which the data was forecasted.

The grid displays the following rows:

- A row for each debt category for which the person / account / tax role / obligation has financial transactions posted.

Note: If the zone is being viewed on the 360 Degree View - Financial tab and the data is being viewed at the obligation level, the calculation through date of each debt category is shown beneath the debt category description.

- A row for Unapplied Credits displays if the overall balance is a credit

- A row for the Total displays with the total of each column

The grid displays the following columns:

- Amount Assessed indicates the original amount of each debt category. This is a sum of the amount of each financial transaction that qualifies for the row.

Note: If the debt category is the one with the Tax debt type, then any credits that reference the same debt category are grouped together within the Amount Assessed column rather than being separated into a credit column.

- Amount Collected indicates the total amount payments that have been allocated to one of the debt category rows.

- Amount Waived indicates the total amount of any waivers that have been applied to one of the debt category rows. This should only appear for a "penalty" or "interest" type of debt category.

- Amount Written Off indicates the total amount of any amount written off. Written off amounts are identified by looking at credit adjustments where the adjustment category indicates that it is a write off.

- Other Credit indicates the amount of any other type of credit that has been "applied" to this debt category.

- Total is a total for the amounts in the row.

All the amount fields are hypertext. Clicking on the amount fields will cause a list of all financial transactions that contribute to that amount to appear.

Dashboard Portal

The Dashboard is a portal that always appears on the Oracle Public Sector Revenue Management desktop. Its zones contain tools and data that are useful regardless of the object being displayed.

Note: User configurable. Refer to Each User Can Customize Which Zones Appear for information about a user can configure which zones appear.

Note: Global context. The system automatically refreshes the values saved in global context with information about the object that appears in Object Display Area. Various zones available in the dashboard portal have been designed to display data related to a person id, account id or tax role id, which are populated by the base global context algorithm C1-GLBL-CTXT.

The contents of this section describe the zones that are available on this portal.

Note: Other zones exist. The zones described below are unique to Oracle Public Sector Revenue Management. Please see Core Dashboard Zones for a description of other zones that can appear on the dashboard.

Next in This Section

- Current Context Zone

- Customer Contact Zone

- Financial Information Zone

- Alert Zone

Current Context Zone

The Current Context Zone contains basic information about the taxpayer on which you are working.

A maximum of four rows may appear:

- The first row contains the person's name. You can click on the person's name to transfer to the Person - Main page. Note, the person's name is formatted by a plug-in algorithm on the installation record.

- The second row contains account related information including the account' ID and check digit, the primary name of the main taxpayer and account type.

- The next row contains tax role related information.

- For implementations that continue to use legacy addresses, the last row contains a location context menu and the location's address and location type. Note, the address information is formatted by a plug-in algorithm on the installation record.

Customer Contact Zone

The Customer Contact Zone has three purposes:

- It shows the age of the Last customer contact associated with the person displayed in the Current Context zone. The word Today is shown if the last contact was on the current date. The word Yesterday is shown if the last contact was on the current date - 1 day. If neither is applicable, the number of days old is shown.

- It shows the name of the person who added this contact.

- It greatly simplifies the addition of a new customer contact. To add a new contact, simply select the Type of customer contact, enter a brief Comment, and press the Add Contact button.

After the contact is added, the date / time of the new contact will be displayed in the Last area. You can use the Go To button to drill into the newly added contact where you can setup reminders or other comments.

Financial Information Zone

The Financial Information Zone is a grid that contains financial information related to the account. Clicking the hyperlink transfers you to the appropriate page. The following table lists the type of information that appears in this zone and the page to which you are transferred if you click the adjacent icon.

Note: Rows are suppressed if the related data is blank for the person / account.

Label

What Is Displayed

Drill Down Transfers You To

Current Balance

The account's current balance.

Not applicable

Payoff Balance

The account's payoff balance. It will only be displayed if the amount differs from the current balance.

Not applicable

Last Bill

The date and amount of the account's last bill along with its due date.

Bill - Main

Last Payment

The date and amount of the account's last payment.

Payment Event - Main

Previous Bill

The date and amount of the bill prior to the last bill for the account.

Bill - Main

Next Bill Date

The next date on which a bill is scheduled to be produced for the account (based on the account's bill cycle's schedule)

Not applicable

Pending Bill Exists

The date of the pending bill. This row only appears if there is a pending bill associated with the account

Bill - Main

Freezable Bill Segments

If freezable bill segments exist, this row contains the number of segments and their total amount.

Bill Segment - Main

Incomplete Adjustments

If incomplete adjustments exist, this row contains the number of adjustments and their total amount.

Adjustment - Main

Freezable Adjustments

If freezable adjustments exist, this row contains the number of adjustments and their total amount.

Adjustment - Main

Payment(s) Pending Upload

Appears when the account has a pending payment staging record (i.e., the account has an external payment that has not been uploaded into the system). To prevent payments from being created and frozen before the actual payment is received, external payments are not uploaded into the system until their accounting date is reached.

Note that the amount displayed represents the amount tendered for the account, but does not reflect how the payment may be distributed (i.e., the payment may be distributed to other accounts).

For information about payment staging records, refer to Interfacing Payments from External Sources.

Payment Upload Staging

Incomplete Payment(s)

Appears when the account has payments that are incomplete. This row contains the number of payments and their total amount. Note, incomplete automatic payments that are pending distribution are not included in this alert as they are highlighted on the Auto Pay will be distributed on described below.

Payment - Main

Payment(s) with Errors

Appears when the account has payments that are in error. This row contains the number of payments and their total amount.

Payment - Main

Freezable Payments)

If freezable payments, this row contains the number of payments and their total amount.

Payment Event - Main

Auto Pay will be created on

This row shows the date that the next auto pay will be created. This alert will appear after a bill is completed for an account on auto pay. Refer to How And When Are Automatic Payments Created? for more information.

Bill - Main

Auto Pay will be distributed on

This row shows the date that the next auto pay will be distributed. This alert will appear after a bill is completed for an account on auto pay and the automatic payment has been created/extracted. Refer to How And When Are Automatic Payments Created? for more information.

Payment Event - Main

Alert Zone

The Alert Zone is a grid that contains messages highlighting a variety of situations. Clicking on the hyperlink transfers you to an appropriate page. The following table lists the various alerts that may appear and the page to which you will be transferred if click on the hyperlink. The table lists the alerts in alphabetical order, but it includes a column indicating the order in which the alert will appear.

Note: You can create additional alert conditions. The following table contains those alerts supported in the base package. It is possible to highlight additional conditions by plugging-in the appropriate algorithm(s) on the installation record.

Note: Account alerts are implementation-specific. On Account - Alerts, a user can define account-specific alerts that should be displayed whenever the account is selected. The Alert Types control table contains the possible alert messages.

Alert Text

Order

Description

Drill Down Transfers You To

Account alerts

4

Appears for each user-defined alert associated with an account.

Account - Alert

Auto-Pay Active: auto pay method description

11

Appears when the account has an automatic payment option effective on the current date. The auto pay method description (i.e. Direct Debit or Payment Advice) appears only if payment advice functionality is enabled. Refer to Payment Advices for more information on payment advice functionality.

Account - Auto Pay

Collection Referral Active

5

Appears when the account has active collection agency referrals.

Collection Agency Referral

Comment Exists On Account

3

Appears when a free form comment has been entered for the account (on Account - Main)

Account

Compliance rating: NNNN

6

Appears when the account's compliance rating falls below the compliance rating threshold on the installation table. Refer to How are compliance rating transactions created for information describing how a taxpayer's compliance rating is affected by various system and user events.

Account - Collections

Installation dynamic alerts

12

You can install plug-in algorithms on the installation record that will create alerts (if given situations exist).

Varies by plug-in

Last Contact: days old - user name who added the contact

1

Appears when the person has a customer contact. The "days old" presents how old the contact is (based on the contact's date). The word Today is shown if the last contact was on the current date. The word Yesterday is shown if the last contact was on the current date - 1 day. If neither is applicable, the number of days old is shown.

Customer Contact

Multiple Financially Resp

10a

Appears when the account has more than one financially responsible person linked to it

Account - Person

Obligation type alert message

7

Appears when the taxpayer has an obligation with an obligation type that has been marked with an alert message (refer to Obligation Type - Details)

Note that if the account in the dashboard has more than one obligation, pressing the drill down button will also launch the obligation search dialog.

Obligation

Obligation type description and status of a pay plan

8

Appears for every pending start, pending stop, and active pay plan that is linked to the account.

Pay Plan

n Open Contact(s) for Person

2

Appears if there are open customer contacts associated with the person.

Customer Contact

n Persons on Account

10c

Appears when the account has multiple persons linked to it. An account's persons are maintained on the Account - Person page.

Account - Person

Reactivated Obligations Exist

9

Appears when any of the account's obligations exist in the state of reactivated (i.e., a financial transaction has been generated after the obligation was closed).

Obligation

Third Party Guarantor

10b

Appears when the account has a third party guarantor. An account's third party guarantors are maintained on the Account - Person page.

Account - Person

The following table highlights alerts related to legacy addresses or classic billing.

Alert Text

Order

Description

Drill Down Transfers You To

Location has n Child Location (s)

15

Appears when the location is defined as the parent location for one or more locations. Refer to Define Location Hierarchy for more information.

Location Management

Location is linked to Parent Location

14

Appears when the location defines a parent location. Refer to Define Location Hierarchy for more information.

Location

Seasonal Address Exists

13b

Appears if the account has a seasonal address and there is no seasonal address active on the current date.

Person - Correspondence Info

Seasonal Address Currently Effective (MM/DD - MM/DD)

13a

Appears if the account has an active seasonal address that is effective on the current date. The date range that the seasonal address is effective is included in the alert.

Person - Correspondence Info

Maintaining The Account Model

As described in Understanding The "Account Model", the "Account Model" objects are those that form the core of your business processes. In this section, we describe the pages that maintain these objects.

Next in This Section

- Maintaining Persons

- Maintaining Accounts

- Using The Account / Person Replicator

- Maintaining Tax Roles

- Maintaining Obligations

- Maintaining Addresses

Maintaining Persons

On the person page, you define demographic information about your taxpayers and every other individual or business with which your company has contact. The topics in this section describe the person page. Navigate using Menu > Registration > Person

Fastpath: For more information about how a person is required to set up a taxpayer, refer to Taxpayer Overview.

Note: This section describes the person maintenance pages using the portal / zone technology where the exact user interface behavior is dictated by an appropriate business object. If your implementation continues to use the original person user interface, refer to Maintaining Persons (Legacy).

Next in This Section

- Person Query

- Person Portal

Person Query

Use the query portal to search for a person. Once a person is selected, you are brought to the maintenance portal to view and maintain the selected record.

Person Portal

This page appears when viewing the detail of a specific person.

Next in This Section

- Person - Main Information

- Person - Relationships

Person - Main Information

The topics in this section describe the base-package zones that appear on this tab.

Person Zone

The Person zone contains display-only information about the Person.

The information displayed in the zone is dictated by the business object linked to the person's person type. However, the expectation is that standard information about the person such as names, IDs, phone numbers and addresses are maintained. The following points highlight some of the standard functionality provided in base product business objects. Your implementation's person information or user interface behavior may differ slightly.

Person Names are used as a primary way to identify a person and are used by most searches throughout the system to find information for an account or person.

- Each name designates a name type. The name type includes base values of Alias, Alternate Representation, Doing Business As, Legal, or Primary name.

Note: Alternate representations of a person's name. You would use an Alternate Representation for a person's name when you have an alternate ways to define the person's primary name. Alternate representations are typically used in countries that use multiple character sets (e.g., the Primary name is entered in Chinese, the Alternate Representation is entered in English). When a person has an alternate name, both the main and alternate names can be used to search for a person. The Alternate Representation Name Type only appears if you have enabled alternate names on the installation record. Refer to the description of the Alternate Representation field under Installation - Main for more information.

Note: The values for the name type field are customizable using the Lookup table. This field name is NAME_TYPE_FLG.

- Whether a single Person Name or separate name constituents are displayed, depends on the business object. Refer to Person Names for more information.

Person Phone numbers are used to capture phone numbers for the person categorized by a phone type. Phone extensions may also be defined.

Note: Formatting is performed by a plug-in. The format that is applied to a Phone Number is controlled by the algorithm that is plugged in on the respective Phone Type. If you prefer a different format, your system administrator should configure this algorithm appropriately.

The Person's ID collection allows for one or more identifiers to be associated with a person. Many person searches in the system support searching by the primary identifier. Note the following additional points about person IDs:

- Person ID may be required or optional. The person ID usage flag on the installation record indicates whether at least one id for a person is required or optional.

- If your ID type is configured with a formatting algorithm, the expected format is displayed. If this format includes separators like hyphens, you do not have to enter the hyphens. Enter the information as a contiguous value and the system will format this for you using the formatting algorithm.

Note: Refer to the ID Type for more information.

- Masking sensitive data. Certain types of person identifiers are sensitive information that should be protected for privacy reasons. The system provides a mechanism for masking this type of data. Refer to Encryption and Masking for more information.

Person Addresses may be defined if the person type has configured valid address types.

Please see the zone's help text for additional information about the data displayed in the person.

Address History Zone

This zone displays historical addresses for the person.

Map Zone

This zone displays a map of the addresses associated with the person.

Person - Relationships

This tab displays information about other objects that a person may be related to.

Accounts

This zone displays a list of all the accounts to which the person is linked, together with the relationship type description. It provides the ability to filter the list by account relationship type.

Tax Roles

This zone displays a list of all the tax roles to which the person is linked, together with the relationship type description, start and end date of the relationship and the account for the tax role If the person has a financial relationship type defined, that is also shown.

Assets

This zone displays a list of all the assets to which the person is linked as a miscellaneous person, together with the relationship type description and start and end date of the relationship.

Note: This is only visible if the user has security for the zone's application service.

Asset Ownership

This zone displays a list of all the assets to which the person is linked as an owner. For each asset it lists the ownership information and the start and end date of the ownership.

Note: This is only visible if the user has security for the zone's application service.

Maintaining Accounts

The account record contains information that controls billing and collections processing. You should only need to use this page if you need to fine-tune the information that the system has set up by default.

The topics in this section describe the pages on which account related information is maintained.

Next in This Section

- Account - Main Information

- Account - Auto Pay

- Account - Person Information

- Account - Bill Messages

- Account - Collections

- Account - Characteristics

- Account - Alerts

- Maintaining Direct Debit Mandates

Account - Main Information

The Main page contains core account information. Open this page using Menu > Registration > Account.

Description of Page

Basic information about the Account and the Account ID are displayed on every tab in this page. These values only appear after the account exists on the database. The Account ID is a system-assigned random number that stays with an account for life.

A "check digit" is displayed adjacent to the account ID. This is for information purposes only, and is not needed to operate the system. The following points describe how the check digit is calculated for an Account ID equal to 0011883422.

- Calculate the sum of the first and every alternate digit in the account id. A = 14 = 0+1+8+3+2

- Calculate the sum of the second and every alternate digit in the Account ID and multiply by 2. For example, B = 30 = (0 + 1 + 8 + 4 + 2) * 2

- Add A and B. For example, C = 44 = 14 + 30

- Count the number of digits used to calculate B that are greater than 4. For example, D = 1 since only 8 is greater than 4.

- Multiply D by 9. For example, E = 9 = 1 x 9

- Subtract E from C. For example, F = 35 = 44 - 9

- Subtract the units position of F from 10 to find the check digit. For example, check digit = 5 = 10 - 5 (5 is subtracted from 10 because F = 35 and there the units position is 5).

Note:

Technical note. The above is calculated in the common routine called CIPCACDN.

Set Up Date is the date the account was initially set up. This is purely informational.

Currency Code defines the currency in which the account's financial transactions are expressed. All rates and payments associated with this account must be denominated in this currency.

Note:

Default note. The currency defaults from the Installation Record and may be overridden here.

Account Type plays a part in:

- The account's default collection class and when the overdue monitor reviews an account. Refer to How Does The Overdue Monitor Work for more information about how and when an account's debt is reviewed.

- And several other functions. Refer to and Setting Up Account Types for more information.

Note:

Default note. The account type defaults from Installation Options - Account (Person Account Type) and may be overridden at will.

Division defines the jurisdiction that governs this account. You may only select Divisions associated with the account's account type. This field is updated behind the scenes every time an obligation is activated (the system uses the division associated with the obligation's obligation type). If you have assigned a division and do not want the system to change it when an obligation is activated, turn on Protect division.

Note:

Division governs many functions. An account's division impacts its collections review dates, the roles assigned to To Do entries, and the calendar of workdays. Refer Setting Up Account Types for more information.

Access Group controls which users are allowed to view and update this account's information (including obligations, payments, tax forms,…). The system defaults this value from the user's default access group. Refer to The Big Picture of Row Security for a complete description of how account security is implemented in the system.

The optional Account Management Group controls the roles assigned to To Do entries associated with an account. Refer to Setting Up Account Management Groups for more information.

Enter a Comment to define unusual information about the account. If this field is populated, an alert will highlight such in the Alert Zone.

Note: Optional information. The fields described below are only visible if your implementation uses the related functionality.

The Bill related fields are applicable only to Classic Billing and are shown only if your implementation has not turned off the BI — Billing (Classic) module.

Bill Cycle controls when a bill is produced for an account.

If you have assigned a bill cycle and do not want the system to change the bill cycle when an obligation is activated, turn on Protect Bill Cycle.

If you want to stall billing until after some future date, enter the date in Bill After.

If a user should review the account's printed bills before they are sent to the taxpayer, enter the user ID of the individual who reviews the bill in Bill Print Intercept.

Mailing Location ID defines an address associated with this account. This functionality is only applicable for implementations that continue to use legacy addresses. Refer to Account - Person Information for more information about how to define where a person has their correspondence sent.

If you do not want the mailing location changed by internal processes, turn on Protect Mailing Location. This functionality is only applicable for implementations that continue to use legacy addresses

Account - Auto Pay

The Auto Pay page is used when an account pays their bills automatically (e.g., by direct debit or credit card). The Auto Pay page can also be used when a taxpayer chooses to receive their refunds via a direct deposit.

Fastpath: Refer to How And When Are Automatic Payments Created for more information.

Open Menu > Registration > Account > Auto Pay to maintain this information.

Description of Page

The Account Auto Pay scroll defines the bank account / credit card from which the taxpayer's automatic payments are debited. Multiple auto pay options may exist if the taxpayer changes auto pay options over time. The following fields display:

- Start Date is the date on which the automatic payment information comes into affect. The system creates an automatic payment for any bill produced for this account with a due date on/after this date and on/before the End Date. If End Date is not specified, this means the automatic payment option applies indefinitely. You need only specify an End Date if the taxpayer wants to stop paying automatically.

- Auto Pay ID is the unique, system-assigned identifier of the auto pay record. This value is assigned after the information is saved on the database and may not be modified.

- Use Auto Pay Source Code to define the source of the funds used to satisfy the automatic payment request. For example, if a taxpayer indicates that they want to use their checking account to pay their bill, you would specify the Auto Pay Source Code associated with their bank. The source's description and external source ID (e.g., bank routing number) are displayed adjacent.

- Use Auto Pay Method to specify whether you want the system to process automatic payments as Direct Debit or Payment Advice. This field is visible only if feature configuration is set up to support payment advice functionality. Refer to Payment Advices for more information on the payment advice functionality.

- Use External Account ID to define the taxpayer's bank account / credit card number.

- You will be required to define an Expires On date if the Auto Pay Source Code references a tender type that requires an expiration date (e.g., if the Auto Pay Source is a credit card company).

- Enter the Name of the taxpayer as it appears in the financial institution's system. This name is routed to the financial institution.

Note: Default note. The Name will default to the primary name of the main taxpayer linked to the account after you enter a Start Date. This defaulting is only possible for accounts that exist on the database.

- In some locales, taxpayers can define a Maximum Withdrawal Amount to limit the amount of money that is automatically debited from their account. Refer to How To Implement Maximum Withdrawal Amounts for more information.

- Use Comments to describe anything interesting / unusual about the automatic payment request.

Account - Person Information

The Account Person page contains information about the person(s) linked to the account.

Note: Both taxpayers and non- taxpayers (e.g. the accounting service that handles the obligations of a commercial taxpayer) can be linked to an account.

If you need to link multiple persons to an account or change information about a person on an account, open Menu > Registration > Account > Persons

Description of Page

The Account Persons scroll contains one entry for every person linked to the account. The following fields display:

- Person ID is the unique identifier of the person linked to the account. The person's name is displayed adjacent.

- Primary Taxpayer is a switch that indicates if the person is the main taxpayer on the account. Only one person on an account may be designated as the main taxpayer.

The significance of the main taxpayer is that its name will appear adjacent to the account ID throughout the system.

- Financially Responsible is a switch that indicates if the person is financially responsible for the account's debt. This switch is on and gray if the person is the Primary Taxpayer because the primary taxpayer is always financially responsible. If multiple persons are linked to the account, you use this switch to indicate which ones are financially responsible versus those that are linked for other purposes.

- Third Party Guarantor is a switch that indicates if the person is a third party guarantor of the account's debt. This switch is off and gray if the person is the Primary Taxpayer.

- Relationship Type defines the relationship between the person and the account. Refer to Setting Up Account Relationship Codes for information about setting up relationship types.

- Web Access indicates whether or not a person linked to this account is Allowed or Not Allowed to view details of this account via your web self service application.

Note: This field is only visible if your implementation has not turned off the WSS (Legacy) module. This information was originally supplied for a sample web self service implementation that is no longer supported by the base product. It remains in the system for upgrade purposes. Implementations may opt to use this data to capture information for a custom self service integration.

- Prefix/Suffix and Pfx/Sfx Name are provide to allow additional information to be appended to a taxpayer's name when correspondence is sent to this person. For example, if the account has declared bankruptcy you might attach "Debtor In Possession" to the person's name. Use Prefix/Suffix to indicate if the Pfx/Sfx Name should be appended to the front or the back of the taxpayer's name.

- Receives Notification is a switch that indicates if the person receives letters (i.e., notifications) initiated by overdue events. These events will send letters to the main taxpayer and any other person linked to the account that Receives Notifications. This switch is on and gray if the person is the Main Taxpayer because the main taxpayer always receives notifications. Refer to Printing Letters for more information about how letters are produced by the system.

The Characteristics grid contains information that describes miscellaneous information about the account / person.

Note: You can only choose characteristic types defined as permissible on the account / person record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

- Effective Date indicate the date on which the characteristic value becomes effective. Note, the effective date defaults to the system date.

- Characteristic Type indicates the type of characteristic.

- Characteristic Value indicates the value of the characteristic.

Note: The following bill related fields are only visible if your implementation has not turned off the BI — Billing (Classic) module. This information is used only for classic billing functionality. If enabled, it appears above the characteristic grid.

- Receives Copy of Bill indicates if the person receives a copy of the account's bills. Turning off this switch grays the remaining fields. This switch is on and gray if the person is the Primary Taxpayer because the main taxpayer always receives a copy of the bill.

Refer to The Source Of Bill Routing Information for more information about how the remaining information is used to format the address of a bill.

- Bill Route Type indicates how the bill is sent to the taxpayer. This field's value defaults from the Installation Record . If the Bill Route Type you select indicates that bills are routed via Fax, the person's fax number is displayed adjacent (the system knows which of a person's phone numbers is a fax number by the phone type). If the Bill Route Type you select indicates that bills are routed via Email, the person's Email address is displayed adjacent. If the Bill Route Type you select indicates that bills are routed via the Postal service, you must choose an appropriate Address Source to define which address should be used. Refer to Setting Up Bill Route Types for more information about bill route types.

- Bill Format indicates if the taxpayer should receive a Detailed or a Summary bill.

Note: The values for this field are customizable using the Lookup table. The values need to match the formats supported by your bill print software. This field name is BILL_FORMAT_FLG.

- Number of Bill Copies indicates how many copies of the bill the person receives.

- Taxpayer PO ID indicates the purchase order ID the taxpayer wants printed on their copy of the bill.

- Address Source indicates where the system should retrieve the address for correspondence related to the account. This functionality is only applicable for implementations that continue to use legacy addresses.

Note: If your implementation uses Classic Billing functionality, the address source settings also apply to billing addresses.

- Choose Mailing Location on Account if correspondence should be sent to the address associated with the Mailing Location on the first page. This address is displayed adjacent.

- Choose Person if correspondence should be sent to the person's mailing address . This address is displayed adjacent.

- Choose Account Override if correspondence should be sent to an override address specified below. Typically, you would only choose this option if the person has multiple accounts and each account's correspondence should be sent to a different address. If you choose this option, the bottom of this page will become populated with fields that should be used to specify this override address.

- Override address constituents is enabled if an Address Source of Account Override is selected. The number and type of address constituents is based on the Country . These fields will be invisible for other Address Sources.

Note: The Country defaults from Installation Options - System . The City, County and State default based on the Country and Postal Code if a Postal Default exists for the postal code.

Account - Bill Messages

The Account Message page contains information about the message(s) to appear on an account's bills. Both one-time and permanent messages may be defined. This information is used when the system assembles messages to appear on an account's bill. Refer to The Source of Bill Messages for more information about bill messages.

Open Menu > Registration > Account > Bill Messages to access this page.

Note: Optional information. This tab is only visible if your implementation has not turned off the BI — Billing (Classic) module. The information is used only for classic billing functionality.

Description of Page

The following fields are displayed:

Bill Message

The message code and description of the message that appears on the taxpayer's bill.

Bill Message Type

Use Temporary to indicate the message should only be linked to the next bill produced for the account. Use Permanent if the message should appear on every bill. Note, a value of Temporary defaults.

Account - Collections

The collections page contains the compliance rating transactions that impact an account's compliance rating. To view or modify these transactions, open Menu > Registration > Account > Collections.

Description of Page

Collection Class controls how the account's debt is compared against collection criteria to determine if an overdue process should be started. Refer to How Does The Overdue Monitor Work for more information about how and when an account's debt is reviewed.

Note: Default note. The Collection Class defaults from the account's Account Type when the account is first added. It may be overridden at will.

If you need to prevent an account from being reviewed by the overdue monitor, use Postpone Compliance Review Until to define the future date when these processes can again review the account's debt.

Last Compliance Review Date is the date when the account's debt was last reviewed by the overdue monitor (C1-ADMOV).

The account's Current Compliance Rating is displayed. For an explanation of how this number is derived, see How is an account's compliance rating calculated?.

The Compliance Rating History scroll contains one entry for each compliance rating history record associated with the account. The following fields display:

Start Date

This is the first date the compliance rating transaction affects the account's compliance rating.

End Date

This is the last date the compliance rating transaction affects the account's compliance rating.

The Created On message is formatted using an algorithm on the Installation Options.

Affect Compliance Rating By

This is the effect of the compliance rating transaction on the account's compliance score. This should be a negative number because the lower the score the worse the compliance rating.

An account's compliance rating is equal to the start compliance rating amount defined on the installation record plus the sum of compliance rating demerits that are currently in effect. When an account's compliance rating is less than the compliance rating threshold defined on the installation record , the account's compliance rating is displayed as an alert in the Alert Zone .

Comments

Enter comments to clarify the reason(s) for the creation of the transaction.

Next in This Section

- How are compliance rating transactions created?

- How is compliance rating calculated?

- What impact does compliance rating have in the system?

How are compliance rating transactions created?

Compliance rating transactions may be created as follows:

- If a payment tender is canceled with a cancellation reason that indicates the cancellation was due to non-sufficient funds, a compliance rating transaction is created. The number of compliance rating is defined on the payment cancellation reason code.

- A user may create compliance rating transactions at their discretion.

- Algorithms may add compliance rating transactions. The system provides a sample overdue event algorithm that adds compliance rating transactions. Refer to C1-OE-CR-RT for more information.

Note: Created By Flag. The compliance rating transaction includes a Created By flag that is customizable using the Lookup table. This field name is CR_RAT_CRE_BY_FLG. If your implementation uses algorithms to create compliance rating history transactions, you may consider adding appropriate values to the Created By flag. Also note that the Created By flag includes the value Other, which may be used by your implementation specific algorithms if you do not want to add a new custom value.

How is compliance rating calculated?

An account's compliance rating is calculated by summing the Affect on Compliance Rating from compliance rating transactions effective on the current date. This value is added to the perfect compliance rating defined on the installation record. The result is the taxpayer's current compliance rating.

What impact does compliance rating have in the system?

The following points describe the impact of an account's compliance rating:

- An account's current compliance rating is displayed in the Alert area when it's less than the threshold compliance rating defined on the installation record.

- An account's compliance rating may affect how the account's debt is collected. We used the word "may" because an account's compliance rating will only affect collection criteria if you set up your overdue processes to do this.

Account - Characteristics

The characteristics page contains information that describes miscellaneous information about the account. Use Menu > Registration > Account > Characteristics to open this page.

Description of Page

Note: You can only choose characteristic types defined as permissible on the account record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

Effective Date

Indicate the date on which the characteristic value becomes effective. Note, the effective date defaults to the account's setup date (defined on the Main page).

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Account - Alerts

The alerts page contains information that describes various alerts assigned to the account. Use Menu > Registration > Account > Alerts to open this page.

Alerts assigned to an account appear in the Alert Zone. They are used to bring important information to the attention of any user who looks at the account. Up to 60 alerts can display in the Alert Zone.

Description of Page

The following fields display:

Alert Type

Indicate the type of alert to show in the Alert Zone.

Start Date

Indicate the date on which the alert starts showing in the alert zone. The current date defaults.

End Date

Indicate the date on which the alert stops showing in the alert zone. You can leave this field blank if the alert should be effective indefinitely. The date defaults to the Start Date plus the Alert Type's alert period.

Maintaining Direct Debit Mandates

Use the Direct Debit Mandate transaction to view and maintain active and historic direct debit mandates.

To maintain this information, navigate to the Account context menu and select Direct Debit Mandate.

Refer to SEPA Direct Debit for more information on mandates.

Next in This Section

- Account's Direct Debit Mandates Portal

- Direct Debit Mandate Portal

Account's Direct Debit Mandates Portal

This special 'go to' portal appears when navigating to Direct Debit Mandate from the Account context menu. Once a direct debit mandate is selected, you are brought to the maintenance portal to view and maintain the selected record.

Direct Debit Mandate Portal

This portal appears when viewing the detail of a specific direct debit mandate.

Next in This Section

- Direct Debit Mandate - Main

- Direct Debit Mandate - Log

Direct Debit Mandate - Main

This portal appears when a direct debit mandate has been selected from the Account's Direct Debit Mandates portal.

This portal contains the following base-package zone.

Direct Debit Mandate

The Direct Debit Mandate zone contains display-only information about the selected direct debit mandate.

Please see the zone's help text for information about this zone's fields.

Direct Debit Mandate - Log

Navigate to the Log tab to view the logs for a direct debit mandate.

Using The Account / Person Replicator

There are two different ways to use this transaction:

- You can make many copies of a given Person / Account combination. This may be required if your company works with third party agencies who enroll taxpayers on its behalf. In this situation, the third party agency may receive blocks of pre-allocated account numbers to be used when they enroll a taxpayer. When a taxpayer signs up, the person information can be updated with information about the newly enrolled taxpayer.

Perform the following steps if you need to create many copies of a given person and account:

- Add a new person and account if you don't already have a taxpayer to serve as your "template".

- Use the account / person replicator to create copies of the person and the account as described below (and make sure to use the Replicate Acct and Person option).

- You can create many Accounts for a single Person. This may be required if you have a taxpayer who wants many separate accounts rather than a single consolidated account.

Perform the following steps if you need to create many copies of a given account for a specific person:

- Select the account that serves as the template account for the person. Note, this account must be linked to the person who wants the many accounts.

- Use the account / person replicator to create copies of the account as described below (and make sure to use the Replicate Account Only option).

Use Menu > Registration > Account/Person Replicator.

Description of Page

Choose the Account that serves as the template account.

Note:

Recommendation. Carefully verify that the template account you have chosen is correct before you save the replicated accounts. After you save the replicated accounts, any corrections could prove time consuming.

At the top of the page, indicate the Number of accounts and persons to Replicate.

Indicate the Main Person Name Base, which will be used as the main person name for all the new persons to be created. This field will be protected if you choose a Replicate Type of Replicate Account Only (as no persons are created).

Use Replicate Type to define if you want to create multiple copies of an account for a given person or if you want to create many new person / account combinations. See the description that appears above for more information about this field.

After entering the above, click the Replicate button to generate your new accounts and persons. The grid displays informational messages describing what will happen when you click save. For example, it will verify how many accounts will be created, the person whose record will be copied, the name that will be used on all the new persons, etc..

If everything looks clean, click save.

Next in This Section

- Information Replicated for New Persons

- Information Replicated for New Accounts

Information Replicated for New Persons

Except for the main name, which you indicate in the Main Person Name field, all information for the main person linked to the account will be copied to the new persons.

CAUTION:

Warning! This copy includes the person's identification number. This will result in multiple persons with the same identification number. You should ensure that the identification number for your template person is a temporary number. When you sign up your actual taxpayer, be sure to update the identification number to a valid number for the person.

Information Replicated for New Accounts

Although most information for an account will be copied, not all information will be. The following points describe the information that is NOT copied on newly replicated accounts:

- Setup Date is set to the current date

- Compliance Review Date and Postpone Compliance Review Until Date will be set to blank

- Auto Pay information will not be copied

- Compliance Rating History will not be copied

- Mailing location will be set to blank
(only applicable to implementations continuing to use legacy addresses).

Note: All miscellaneous persons linked to the account (i.e., those who are not flagged as Main Taxpayers) will be linked to the new accounts. With this functionality, for example, you can create a person for a third party enroller and link this enroller to the template account. This enroller will then be linked to all the new accounts.

Maintaining Tax Roles

Use the Tax Role transaction to view and maintain tax roles. Navigate using Menu > Registration > Tax Role.

Next in This Section

- Tax Role Query

- Tax Role Portal

Tax Role Query

Use the query portal to search for an existing tax role. Once a tax role is selected, you are brought to the maintenance portal to view and maintain the selected record.

Tax Role Portal

This page appears when viewing the detail of a specific tax role.

Next in This Section

- Tax Role - Main

- Tax Role - Log

Tax Role - Main

This portal appears when a tax role has been selected from the Tax Role Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Tax Role

The Tax Role zone contains display-only information about the tax role.

Please see the zone's help text for information about this zone's fields.

Related Obligations

This zone lists non-cancelled obligations currently linked to the broadcast tax role. The zone will initially list only non-closed, non-cancelled obligations. Additional filters are provided to allow closed obligations to be displayed and to restrict the list of obligations shown by date range. This zone is only visible if non-cancelled obligations exist for the tax role.

Address History Zone

This zone displays historical addresses for the tax role.

Map Zone

This zone displays a map of the addresses associated with the tax role.

Tax Role - Log

Navigate to the Log tab to view the logs for a tax role.

Maintaining Obligations

The topics in this section describe the pages on which obligation related information is maintained.

CAUTION:

Take special care when adding a new obligation to specify the appropriate division and obligation type as it will affect how the taxpayer how overdue debt is collected, how penalty and interest is calculated and much more. After the obligation is activated, you may not change its obligation type.

Next in This Section

- Obligation - Main Information

- Obligation - Rate Info

- Obligation - Chars

- Obligation - Recurring Charges

- Obligation - Miscellaneous

Obligation - Main Information

The Main page contains basic obligation information. Open Menu > Registration > Obligation to maintain this information.

Description of Page

Obligation Info and Obligation ID are displayed on every page. These values only appear after the obligation exists on the database. The ID is a system assigned random number that stays with an obligation for life. The Obligation Info is a concatenation of important details about the obligation and its account.

Obligation Status defines the state of the obligation.

- Click the Activate button to activate a Pending Start obligation.

- Click the Cancel button to cancel a Pending Start, Active, Pending Stop or Stopped obligation.

- Click the Stop button to stop a Pending Stop obligation.

- Click the Close button to close a Stopped or Reactivated obligation.

Enter the Account ID that is financially responsible for the obligation. If you change an obligation's Account ID, you are effectively transferring this obligation (and its debt) to the new account.

Indicate the Division and Obligation type. These fields are very important as they control numerous aspects of the obligation's behavior. These fields are gray when the status is not Pending Start.

Fastpath: For more information about what the obligation type controls, refer to Setting Up Obligation Types.

If the account is populated and the obligation type's tax type indicates a tax role is required, enter the Tax Role for this obligation.

If the obligation type indicates that a filing period is required, define the Filing Period for the obligation.

The Start Date defines when the financial relationship begins. The End Date defines when the financial relationship terminates. If the end date is blank, the obligation has not yet been terminated.

Enter an Override Filing Due Date if the taxpayer has requested an extension to the filing due date for this obligation's filing period.

Enter an Override Payment Due Date if the taxpayer has requested an extension to the payment due date for this obligation's filing period.

The Current Amount is the current balance of the obligation.

The Char Location ID is a unique identifier for the location, or physical address. For some obligation types, certain characteristics of the location will be needed in order to properly assess the obligation amount. Other obligation types such as sales tax will require a valid location to which correspondence is sent.

Note: This is only visible if the implementation is configured for legacy addresses.

Your conversion process will fill in Old Account ID for obligations that were converted from your legacy system. The payment upload process uses this field to locate the accounts for payments that reference a legacy account number.

The Pay Plan Autopay flag determines if the pay plan scheduled payments are excluded from automatic payment or included by automatic payment. If the account is not set up for automatic payment for the period that covers the pay plan, this flag cannot be set. This field is only visible if the obligation has a special role of Pay Plan.

The Recommendation Rule displays the description of the pay plan recommendation rule used for this obligation. This field is only visible if the obligation has a special role of Pay Plan.

Expiration Date contains the date at which the obligation is set to expire.

Renewal Date contains the date at which the obligation is to be renewed. Renewal date is disabled if renewal is not allowed on the obligation type.

Note: The following bill related fields are only visible if your implementation has not turned off the BI — Billing (Classic) module. This information is used only for classic billing functionality.

Use Maximum 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, a user truly intends to send the bill out, they should regenerate the bill. The value of Maximum Bill Threshold defaults from the obligation's obligation type. Refer to How To Correct A Bill Segment That's In Error for more information.

If the obligation requires a total amount to bill, the amount is displayed. The label that appears for this field is defined on the obligation type (on the Billing tab). We recommend that the system be set up so that this label is very specific.

This bottom of this page contains a tree that shows the various objects linked to the obligation. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.

The topics that follow describe miscellaneous features on this page.

Obligation - Rate Info

The rate info page contains the obligation's rate and information needed by the rate to calculate the obligation's bill segments. This information is only displayed if the obligation's obligation type allows a rate. Generally speaking, rates are utilized by taxes calculated using Classic Billing.

Open Menu > Registration > Obligation > Rate Info to access this page.

Note: Optional information. This tab is only visible if your implementation has not turned off the BI — Billing (Classic) module.

Description of Page

The Rate grid controls the rate used to calculate the obligation's bill segments. Multiple rows will only exist if the obligation's Rate changes over time.

- An obligation's Rate is populated by the system. The obligation type's default rate is populated on the obligation.

Billing selects a single rate from the Rate grid when it calculates a bill segment for the obligation. If multiple rates are defined in this grid, the rate is selected based on the obligation's obligation type's Rate Selection Date. The following fields display:

- Effective Date is the date the rate becomes effective. The obligation's start date defaults.

- Rate Schedule defines the rate used to calculate the obligation's bill segments. Note, you can only choose rates defined as permissible on the obligation's obligation type; the permissible rates are shown in the adjacent tree.

Obligation - Chars

This page contains the Characteristics that are in effect for the obligation.

Use Menu > Registration > Obligation > Chars to open this page.

Description of Page

The Characteristics grid contains information that describes miscellaneous information about the obligation.

Note: You can only choose characteristic types defined as permissible on the obligation record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

Effective Date

Indicate the date on which the characteristic value becomes effective. The obligation's start date defaults.

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Obligation - Recurring Charges

This page contains the Recurring Charges that are in effect for the obligation.

Use Menu > Registration > Obligation > Rec. Charges to open this page.

Note: Optional information. This tab is only visible if your implementation has not turned off the BI — Billing (Classic) module. The information is used only for classic billing functionality.

Description of Page

The Recurring Charge section contains effective-dated information that defines the recurring charge amount. It may be used to calculate a charge that is recurring. This information is only displayed if the obligation's obligation type allows a recurring charge amount. The following fields display:

Effective Date

The date the charge becomes effective. The obligation's start date defaults.

Recurring Charge Amount

The recurring charge amount.

Obligation - Miscellaneous

The miscellaneous page contains information that describes miscellaneous information about the obligation. Use Menu > Registration > Obligation > Misc to open this page.

Description of Page

Select the Industry code associated with the obligation. Some examples of these codes are NAICS and SIC which are used to classify businesses in North America.

Enter a Business Activity associated with the taxpayer. This can be used to further define what types of activities are served by this contract.

Note: The following bill related fields are only visible if your implementation has not turned off the BI — Billing (Classic) module. This information is used only for classic billing functionality.

The bill message grid contains information about the message(s) to appear on an obligation's bill segments. Both one-time and permanent messages may be defined. This information is used when the system assembles messages to appear on an account's bill (as part of bill completion). Refer to The Source Of Bill Messages for more information. The following fields are displayed:

- For Bill Message Code, select a message code to appear on the taxpayer's bill.

- For Bill Message Type, use Temporary to indicate the message should only be linked to the next bill produced for the account. Use Permanent if the message should appear on every bill. Note, a value of Temporary defaults.

Maintaining Addresses

On the address page, you define the constituents of a given address. Navigate using Menu > Registration > Address

Next in This Section

- Address Query

- Address Portal

Address Query

Use the query portal to search for an address. Once an address is selected, you are brought to the maintenance portal to view and maintain the selected record.

Address Portal

This page appears when viewing the detail of a specific address.

Next in This Section

- Address - Main Information

- Address - Relationships

- Address - Log

Address - Main Information

The topics in this section describe the base-package zones that appear on this tab.

Address Zone

The Address zone contains display-only information about the Address. The information displayed in the zone is dictated by the business object. However, the expectation is that address constituents for the address driven by the country are displayed.

Please see the zone's help text for additional information about the data displayed in the address.

Map Zone

This zone displays a map of the address..

Address - Relationships

This tab displays information about other objects that an address may be related to.

Persons

This zone displays a list of all the persons to which the address is linked, together with the relationship type description and the start and end date of the relationship.

Tax Roles

This zone displays a list of all the tax roles to which the address is linked, together with the relationship type description, start and end date of the relationship.

Assets

This zone displays a list of all the assets to which the address is linked as a billable address along with the effective start and end date.

Note: This is only visible if the user has security for the zone's application service.

Address - Log

Navigate to the Log tab to view the logs for an address.

The Big Picture Of Customer Contacts

Customer contacts are used to record when and why a taxpayer contacted your company. This information is used for both audit and statistical purposes. The topics in this section provide details about how customer contacts are created and used in the system.

Next in This Section

- Customer Contacts Are Associated With Persons

- How Customer Contacts Are Created

- Customer Contacts Are Used To Trigger Letters

- A Customer Contact May Trigger Reminders

- Maintaining Customer Contacts

- Reprinting Letters

Customer Contacts Are Associated With Persons

Customer contacts are associated with a Person. To associate a customer contact record with an account, you must select a person related to that account. Unless you have specific reasons to do otherwise, the main taxpayer is usually your best choice.

How Customer Contacts Are Created

You can add a Customer Contact at any time using either of the following methods:

- Use the customer contact maintenance page.

- Use the Customer Contact Zone on the dashboard.

In addition to manually adding customer contacts, your implementation team can set up plug-in algorithms that create customer contacts when certain events transpire. For example, you can use a form rule to create a customer contact when a form enters a given state. Because the number and type of plug-ins can be customized for your implementation, we cannot provide a concise list of all such algorithms.

Customer Contacts Are Used To Trigger Letters

In order to send a letter to a taxpayer, a customer contact must be created for the taxpayer. These types of customer contacts reference a customer contact type that, in turn, references a letter template. The letter template controls the type of information that is merged into the "form letter" and how the letter is physically produced. Refer to Letter Printing for more information about letter templates and how letters are physically produced.

Customer contacts that trigger letters can be produced by any of the method described under How Customer Contacts Are Created. While a user can create this type of customer contact (e.g., if a taxpayer requests a form to sign-up for automatic payment), the primary sources of customer contacts that trigger letters are via system events and algorithms. Your implementation team can introduce plug-in algorithms to create a customer contact when certain events take place. If the created customer contact references a letter template, a letter will be triggered. Because the number and type of plug-ins can be customized for your implementation, we cannot provide a concise list of all such algorithms.

Some events that trigger the creation of letters may also get canceled and related algorithms may try to suppress the letter from being printed as a result. If the letter was already extracted prior to the attempt to suppress, there is no ability for the application to prevent printing. However, the customer contact page will still indicate for audit purposes that suppression of printing was attempted. The customer contact maintenance page will indicate in the letter information string whether or not the letter was suppressed or attempted to be suppressed. There is also a suppression reason captured as a characteristic.

Refer to Suppressing Letters for more information.

A Customer Contact May Trigger Reminders

If you want the system to remind you (via a To Do entry) about a taxpayer-related issue, you can set up a "reminder" on a customer contact. To do this, follow these steps:

- Determine if you need a new customer contact or if you can reuse one that already exists. If you need a new customer contact, use any of the "online methods" described under How Customer Contacts Are Created.

- Add an entry to the customer contact's log. This log entry should be set up as follows:

- If the To Do entry should be addressed to a specific user, choose a Reminder type of Send to User and enter the user's User ID.

- If the To Do entry should be addressed to a group of users, choose a Reminder type of Send to Role and enter the user group's To Do Role.

- Use Trigger Date to define the latest date on which the To Do entry should be created. The reason we indicated this should be the latest date is because the background process that's responsible for creating these To Do entries has a parameter called "lead time". This parameter is used to define the number of days before the Trigger Date that the To Do entry should be created. Note, the batch control ID of TD-CCCB is used to refer to this background process.

A To Do entry will then be created on a future date.

Maintaining Customer Contacts

Customer contacts are used to record when and why a customer contacted your company. This information is used for both audit and statistical purposes. The topics in this section describe how to maintain customer contacts. Refer to The Big Picture Of Customer Contacts for background information about customer contacts.

Next in This Section

- Customer Contact - Main

- Customer Contact - Log

- Customer Contact - Characteristics

Customer Contact - Main

Open Menu > Work Management > Customer Contact to maintain a customer contact.

Note: A zone exists in the dashboard that can be used to easily create new customer contacts.

Description of Page

Enter the Person ID of the person associated with the customer contact.

Turn on the Open switch if the event that necessitated the contact hasn't been resolved. For example, if a taxpayer calls asking for some information and you can't resolve it immediately, you would turn on the Open switch and enter an appropriate entry in the Log.

Enter the Contact Date and Contact Time.

Note: The current date and time are defaulted.

The User ID of the user who created the contact is displayed adjacent to Contact Date / Time.

Every customer contact has a Contact Type that classifies the record for reporting purposes. Every contact type, in turn, references a Contact Class. The class categorizes customer contacts into larger groupings for reporting purposes.

Note: Adding a customer contact may cause a letter to be generated. 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 Customer Contacts Are Used To Trigger Letters for more information.

Use Comments to describe the contact.

If a letter template is associated with the customer contact type / class:

- Letter Information describes the status of the letter (i.e., whether it has been printed or not). The letter information will also indicate if the letter has been suppressed from printing, or that the system attempted to suppress printing but that the letter was already extracted.

- If the letter has been printed and you want to reprint, please turn on the reprint switch (this will cause the letter to be reprinted the next time the respective letter print background process executes).

- If your implementation team has configured the system to support online letter image display, the Display Letter button appears. When clicked, the image of the letter is rendered in a PDF and displayed in an Adobe reader. Refer to Technical Implementation Of Online Letter Production for information about configuring the system to enable the capability.

The grid that follows contains a diary of past (and future) events related to the customer contact. Refer to A Customer Contact May Trigger Reminders for more information about when you would use this log.

There are two ways to add a row to the log:

- You can click the + button to add a new row.

- You can navigate to the Log tab and insert a new row into the scroll.

Regardless of the method used to add a log entry, the following information appears on a log entry:

- Create Date / Time is the date and time when the log entry was created.

- Created by identifies the user that created the log entry.

- Use Comments to describe the reason for the log entry. If you have lengthy comments, we recommend navigating to the Log tab (by clicking the adjacent Go To button) as there is a larger input field on this page.

- The remaining fields are only used if you want the system to remind you about this customer contact on a future date. If you enter these fields, the system will create a To Do entry to remind you about the customer contact.

- If the To Do entry should be addressed to a specific user, choose a Reminder type of Send to User and enter the user's User ID.

- If the To Do entry should be addressed to a group of users, choose a Reminder type of Send to Role and enter the user group's To Do Role.

- Use Trigger Date to define the latest date on which the To Do entry should be created. The reason we indicated this should be the latest date is because the background process that's responsible for creating these To Do entries has a parameter called "lead time". This parameter is used to define the number of days before the Trigger Date that the To Do entry should be created. Note, the batch control ID of TD-CCCB is used to refer to this background process.

Note: Multiple reminders. You can set up multiple reminders on a customer contact. For example, you can indicate that you want to be reminded every Monday for the next 4 weeks to check on the issue that caused a given customer contact to arise. You'd do this be entering 4 log entries where each as the desired Trigger Date.

Customer Contact - Log

The log contains a diary of past (and future) events related to the customer contact. Open Menu > Work Management > Customer Contact > Log to maintain a customer contact's log. Note, you can also maintain this information on the Main tab.

Fastpath:

Refer to A Customer Contact May Trigger Reminders for more information about when you would use this log.

Description of Page

Date / Time is a display-only field that contains the date and time when the log entry was created.

Log ID is the system-assigned, unique identifier of the log entry.

Created by is a display-only field that contains the ID and name of the user who created the log entry.

Use Comments to describe the reason for the log entry.

The remaining fields are only used if you want the system to remind you about this customer contact on a future date. If you enter these fields, the system will create a To Do entry to remind you about the customer contact.

- If the To Do entry should be addressed to a specific user, choose a Reminder type of Send to User and enter the user's ID in Send To.

- If the To Do entry should be addressed to a group of users, choose a Reminder type of Send to Role and enter the user group's To Do Role in Send To.

- Use Trigger Date to define the latest date on which the To Do entry should be created. The reason we indicated this should be the latest date is because the background process that's responsible for creating these To Do entries has a parameter called "lead time". This parameter is used to define the number of days before the Trigger Date that the To Do entry should be created. Note, the batch control ID of TD-CCCB is used to refer to this background process.

Customer Contact - Characteristics

Open Menu > Work Management > Customer Contact > Characteristics tab to maintain a customer contact's characteristics.

Note: Characteristics on this object is to allow a customer contact that triggers a letter to be able to extract information from any object in the system. For example, if you have an algorithm / background process that wants to generate a letter in respect of a given tax form, you could create a customer contact and reference the tax form as a characteristic value. Then, when the information is extracted for the letter, the extract algorithm could extract fields from the tax formto merge onto the letter.

Description of Page

Note: You can only choose characteristic types defined as permissible on a customer contact. Refer to Setting Up Characteristic Types & Their Values for more information about characteristic types. In addition, the characteristic type must also be defined as valid for the customer contact's type. Refer to Setting Up Customer Contact Types for more information about customer contact type.

The following fields display:

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Reprinting Letters

As described under Customer Contacts Are Used To Trigger Letters, a customer contact is required when sending a letter to a taxpayer. The contents of this section describe steps related to reprinting letters.

Fastpath:

Refer to Letter Printing for technical information related to printing letters.

How To Reprint A Specific Letter

If you need to reprint a specific letter, navigate to Customer Contact - Main and turn on the Reprint switch (and save the customer contact). Alternatively, if your implementation has enabled the online creation of letter images, you can also click the Display Letter button on this page and then print the resultant PDF on your local printer.

Reproducing The Letter Print Flat File

You can reproduce the flat file containing the information sent to your printing software at any time. Simply request the respective extract batch process and specify the run number associated with the historic run.

Appendix A - Legacy Functionality

This section includes documentation for legacy functionality. It is not recommended for use by new implementations but remains in the product for upgrade purposes.

Next in This Section

- Navigating The Account Model Using Control Central

- Maintaining Persons (Legacy)

- Maintaining Locations

- Additional Location Management Tools

- Setting Up Bill Print Groups

Navigating The Account Model Using Control Central

CAUTION:

The Control Central search and view portal is legacy functionality that has been replaced by 360 Degree Search and View. The functionality remains in the product for upgrade purposes. This functionality does not support centralized addresses.

Control Central is the name given to the functionality that helps you:

- Find a person.

- Find an account.

- Find a location.

- View information about a person / account / location.

- View alerts and messages about a person / account / location.

- Navigate to pages that contain information related to a person / account / location.

Next in This Section

- Control Central - Main

- Control Central - Account Information

- Control Central - Taxpayer Information

- Control Central - Account Tree

- Control Central - Location Tree

- Control Central - Bill/Payment Tree

- How To Add A New Taxpayer From Control Central

Control Central - Main

Open Menu > Control Central to find a taxpayer.

Note:

Automatic transfer to Account Information tab. You are automatically transferred to Control Central - Account Information when an account is selected on this page.

The contents of this section describe how to use this page.

Next in This Section

- Search Facilities

- Search Options

- Wild Cards

- Search Results

Search Facilities

The top of Control Central is where you enter the criteria used to find a person, account or location.

Note:

Multiple search criteria. You can search for a taxpayer using a combination of Name, Address, City, and Postal Code. When multiple fields are populated, the system searches for taxpayers that match all such criteria. For example, if you enter a Name of Smith, and a Postal code of 94114; only taxpayers named Smith with service in postal area 94114 will be displayed.

The following table describes each of the different search methods.

Search Method

Description

Name

Use this field to search for a person or account using a person's name. The person may be the main taxpayer on the account or a third party related to the account.

You can enter all or part of the person's name. The name search is not case sensitive.

If you need to add a new taxpayer, use either of the following options:

- Click the + button. Clicking this button opens the Person - Main page where you can add a new person. Refer to How To Add A New Taxpayer From Control Central for more information about how to add a new taxpayer (i.e., Person and Account) from this page.

Address

Use this field to search for a location or account using the first line of a service address.

You can enter all or part of the first line of the address. For example, if you're looking for 324 Hawthorne Lane, you can enter 324 Haw rather than the entire address.

The address search is not case sensitive.

City

Use this field to search for a location or account using a city name associated with a service address.

You can enter all or part of the city name. For example, if you're looking for someone in San Francisco; you can enter San Fra, San F, San Francisco, etc.

The city search is not case sensitive.

We strongly recommend qualifying a City search with some other information (e.g., Name) otherwise the resultant list can be too large to deal with.

Postal

Use this field to search for a location or account using a postal code associated with a service address.

You can enter all or part of the postal code. For example, if you're looking for someone in 94114; you can enter "94114", "9411", etc.

We strongly recommend qualifying a Postal search with some other information (e.g., Name) otherwise the resultant list will be too large to deal with.

Account ID

Use this field to search for an account using an account number. After entering this information, click the search button adjacent to the Account ID entry field (or press Enter) to search for an account. The Account ID cannot be combined with other search fields.

You can enter all or part of the account ID. For example, if you're looking for account 1929119291; you can enter "1929119291", "192911", etc.

If you need to add a new account for an existing person, click the + button. Clicking this button opens the Account - Main page on which a new account can be added.

Phone Format/Number

Use this field to search for an account using one of the telephone numbers linked to one of the persons linked to the account. The person may be the main taxpayer on the account or a third party related to the account.

You may enter the phone number in the format indicated or you can enter the information as a contiguous string of numbers and the system will format this for you.

Wild card searches are not supported. However, you can enter the first few digits of the phone number and the system will look for all accounts with these digits.

After entering this information, click the search button (or press Enter) to search for an account linked to a person with this telephone number. The system displays every account with the input telephone number in the search results.

Person ID Type/Value

Use these fields to search for a person or account using one of the ID's linked to one of the persons linked to the account. You must enter both an identifier type and number.

You may enter the person's ID in the format dictated by the identifier type (if any). Please note that if the ID Number should be formatted (e.g., dashes in an American social security number), you do not have to enter the dashes. Rather, you can enter the information as a contiguous value and the system will format this for you.

Wild card searches are not supported. However, you can enter the first few digits of the ID number and the system will look for all persons and accounts with these digits.

After entering this information, click the search button (or press Enter) to search for a person / account linked to a person with this ID. The system displays every person with the input ID in the search results.

Geo ID Type/ Value

Use these fields to search for a location using one of the geographic values linked to the location. You must enter both a geographic type and value.

Wild card searches are not supported. However, you can enter the first few digits of the geographic value and the system will look for all locations with these digits.

After entering this information, click the search button (or press Enter) to search for a location with this ID. The system displays every location with the input ID in the search results.

Note:

Automatic transfer to Account Information tab. If your search criteria result in a single taxpayer being retrieved, you are automatically transferred to Control Central - Account Information with that taxpayer's information displayed.

Search Options

The Show All Locations search option controls whether you see all of an account's locations in the search results. If turned on, every location linked to an account is shown in the search results. If turned off, only one location is shown per account (and this location is selected at random).

This switch pertains to the following search methods:

- Search by name (and all address constituents are left blank)

- Search account ID

- Search by person phone number

- Search by person identifier

This switch does not pertain to the following search methods as these are location-oriented, not account-oriented:

- Search by name when any address constituent is entered

- Search by address constituent (when name is blank)

- Search by geographic identifier

The benefit of turning this switch off is that an account will be immediately selected when you enter unique account-oriented search criteria. For example, if you specify an Account ID and press enter, the system automatically selects the account; you don't have to wait for the search results to be populated with the multitude of locations linked to the account (and then select one of the rows). Please note, an alert highlights if the selected account has other locations.

Note:

Default note. The first time you open this page, this switch defaults from your user preferences. When you return to this page, the last value of this switch is defaulted.

Wild Cards

The control central searches against Name, Address, and City support wild cards. The wild card character is % and represents any number or character. The system always appends a % for you when you use these search methods. Examples will help clarify this functionality:

- If you enter a B, the system searches for B% (and will find all objects that begin with B).

- If you enter B%N, the system searches for B%N%. It will find anything that

- Starts with a B, and

- has zero or more other characters followed by an N.

- If you enter %B the system searches for %B%. It will find anything with a B in it, no matter what it starts and ends with.

Note:

Certain wildcard searches can result in lengthy response times. If you use the wildcard character to prefix your search criteria (e.g., %San Fran), lengthy response times can result. Why? Because the system will have to look at EVERY taxpayer in the system before it can return the results.

Search Results

The search results at the bottom of the page contain persons, accounts, and locations that match your search criteria. The information displayed in this area differs depending on the type of search you perform.

Note:

The first X matches are returned. The number of taxpayers that are returned is limited by the system's memory buffers. If you do not find the account you are looking for in the set of results, refine your search criteria.

Note:

Automatic selection if only one match. You don't have to select the desired person / account / location if there is one and only one object that matches your search criteria; the system automatically selects it and transfers you to Control Central - Account Information.

Note:

Use Tab and Enter to select an account. You don't have to use the mouse to select an account when multiple matches are returned. Instead, the system highlights the first row in the search results. If this is the taxpayer you want, press enter to select it. If not, press tab until you've highlighted the desired taxpayer (and then press enter to select it).

Note:

Use next and previous buttons to step through a list of taxpayers. When you select an account from the search results, you are automatically transferred to Control Central - Account Information. If you want to look at a different account that appeared in the search results, you do NOT have to return to the Main tab. Rather, you can click the Next or Previous buttons and to scroll up and down through the search results (note that there are accelerator keys for each of these buttons so you don't have to use the mouse to take advantage of this feature).

Control Central - Account Information

Once Control Central - Main has populated an account, you are brought to this page to see an overview of the account.

Note:

Global context. Selecting an account on control central causes the global context information to be refreshed. Various zones available on this page use the value in the global context to display relevant data for the appropriate account, person and location.

Note:

User configurable. Refer to Each User Can Customize Which Zones Appear for information about how to configure which zones appear. The image of the page below contains a limited number of the possible zones.

Description of Page

Note:

Navigation hint. The Go To Control Central option on the account context menu navigates to this tab page.

The contents of this section describe the zones that are available on this portal page.

Next in This Section

- Account Financial History Zone

- Alert Zone

- Bill Graph Zone

- Context Zone

- Credit Allocation Detail Zone - Account

- Compliance Information Zone

- Taxpayer Information Zone

- Financial Information Zone

- Location Information Zone

- Timeline Zone

Account Financial History Zone

The Account Financial History Zone lists an account 's financial events in reverse chronological order. You can use this grid to both view high-level information about these events and to transfer to the respective page in which an object is maintained.

Note:

Approximately a year and half is shown. This zone shows all financial transactions within 20 months of the latest financial transaction. This limitation exists to prevent this zone from becoming unmanageably long.

The following columns are displayed in the grid:

Effective Date

This is the date the event starts aging. This column will be blank if the FT has not started aging yet.

Financial Transaction Type

This column indicates the type of financial event: Bill , Payment , Bill Cancellation , Pay Cancellation , Adjustment and Adjustment (Cancel) . If the event is related to an adjustment, the adjustment type's description is displayed instead of "Adjustment".

Current Amount

This column shows the financial event's effect on the account's current balance.

Current Balance

This column shows the account's current balance after the financial event.

Payoff Amount

This column shows the financial event's effect on the account's payoff balance. Payoff Amount will be dimmed if it is the same as its Current Amount .

Payoff Balance

This column shows the account's payoff balance after the financial event. Payoff Balance will be dimmed if it is the same as its Current Balance .

If you need to see more information about a specific financial transaction, press the go to button to transfer to the respective page in which the information is maintained.

Fastpath:

For information about current and payoff balance, refer to Current Amount versus Payoff Amount.

CAUTION:

The first 25 rows are displayed when this zone is initially built. If more rows exist, a Get All button appears. If you click this button, the system retrieves a maximum of 750 rows.

Bill Graph Zone

The Bill Graph Zone illustrates the ending balance and new charges on each of the taxpayer's historical bills.

Note:

Approximately a year and half is shown. This zone shows all bills within 20 months of the latest bill. This limitation exists to prevent this zone from becoming unmanageably wide.

For balance forward accounts, both ending balances and current charges are shown in the graph. For open-item accounts, only the current charges are shown in the graph.

The following points describe unique features of this zone:

- If you leave the mouse pointer stationary on a bar, summary information about the bill will be displayed.

- If you click on a bar, you will be transferred to the bill page with the respective bill displayed.

Context Zone

The Context Zone contains basic information about the Person / Account / Location on which you are working.

Person

This part of the context area contains the person's standard information. Note, this information is formatted by a plug-in algorithm on the installation record . Refer to the base package's person information algorithm for an example. If you prefer different formatting logic, your system administrator should configure the system appropriately

Account ID

This part of the context area contains the unique identifier of the account and the name of its main taxpayer.

Adjacent to the account ID appears a "check digit". This is for information purposes only and is not needed to operate the system. Refer to the Description of Page section under Account - Main for a description of how "check digit" is calculated.

Below Account ID , the account's Current Balance and Payoff Balance are displayed. Payoff Balance will be hidden when it's the same as the Current Balance . Refer to Current Amount versus Payoff Amount for more information.

Location

If the account has an obligation linked to a characteristic location, the location address is displayed. Note, the address information is formatted by a plug-in algorithm on the installation record . Refer to the base package's location format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately

Credit Allocation Detail Zone - Account

The Credit Allocation Detail zone shows the results of dynamic credit allocation of an account. A user may also choose to see the detail for one of the account's tax roles, obligations or assessments. It also allows a user to bring P&I up to date and to forecast P&I to the current date or in the future.

Refer to Credit Allocation Detail Zone for information about the remainder of this zone.

Compliance Information Zone

The Compliance Information Zone is a grid that contains a variety of compliance-oriented events. Pushing the button adjacent to the information transfers you to an appropriate page. The following table lists the type of information that may appear in this zone and the page to which you will be transferred if you push the adjacent button.

Activity Label

What Is Displayed

Drill Down Transfers You To

Overdue Process. One row is displayed for every Active overdue process linked to the account.

The overdue process's standard information string (this is dynamic as it's constructed by an algorithm)

Overdue Process - Main

Pay Plan. One row is displayed for every Active pay plan linked to the account.

The pay plan standard information string (this is dynamic as it's constructed by an algorithm)

Pay Plan - Main

CAUTION:

The first 25 rows are displayed when this zone is initially built. If more rows exist, a Get All button appears. If you click this button, the system retrieves a maximum of 750 rows.

Taxpayer Information Zone

The Taxpayer Information Zone is a grid that contains information about the current person and account. Pushing the button adjacent to the information transfers you to an appropriate page. The following table lists the type of information that may appear in this zone and the page to which you will be transferred if you push the adjacent button.

Note:

Rows are suppressed if the related data is blank for the person / account.

Label

What Is Displayed

Drill Down Transfers You To

Account ID

The account's unique identifier (i.e., account ID) is displayed

An account context menu has been provided (allowing you to drill to a variety of account-oriented pages)

Primary Taxpayer

The main taxpayer's name. Note, the person's name is formatted by a plug-in algorithm on the installation record. Refer to the base package's name format algorithm for an example. If you prefer different formatting logic, your system administrator should configure the system appropriately

A person context menu has been provided (allowing you to drill to a variety of person-oriented pages)

Set Up Date

The account's setup date

Account - Main

Division

The account's division

Account - Main

Account Type

The account's account type

Account - Main

Bill Cycle

The account's bill cycle

Account - Main

Current Compliance Rating

The account's current compliance rating

Account - Collections

Next Compliance Review Date

The next date on which the account's debt will be reviewed by the account debt monitor.

Account - Collections

A separate row is displayed for each characteristic linked to the account. Each row's label is the characteristic type's description.

The characteristic's value

Account - Characteristic

Auto Pay Source Code

The account's auto pay source

Account - Auto Pay

A separate row is displayed for each miscellaneous person linked to the account. Each row's label is the person relationship type's description.

The main name of the miscellaneous person

A person context menu has been provided (allowing you to drill to a variety of person-oriented pages)

A separate row is displayed for each characteristic linked to the person. Each row's label is the characteristic type's description.

The characteristic's value

Person - Characteristic

A separate row is displayed for each telephone number linked to the person. Each row's label is the phone type's description.

The telephone number

Person - Main

A separate row is displayed for each identifier linked to the person. Each row's label is the ID type's description.

The person identifier value

Person - Main

Email Address

The person's email address

Person - Miscellaneous

CAUTION:

This zone does not support data masking. If your implementation masks any of the information that appears on this zone, you must disable it and implement a zone that will mask your data appropriately. The demonstration system provides a sample zone that your implementation can import and then customize if necessary; this zone's code is CI_CIMAP. To disable the base package zone simply deny access to its associated application service. You should only grant access to your new Taxpayer Information zone.

Location Information Zone

The Location Information Zone is a grid that contains information about the current location. Pushing the button adjacent to the information transfers you to an appropriate page. The following table lists the type of information that may appear in this zone and the page to which you will be transferred if you push the adjacent button.

Note:

Rows are suppressed if the related data is blank for the location.

Label

What Is Displayed

Drill Down Transfers You To

Location Information

The location's address. Note, the address information is formatted by a plug-in algorithm on the installation record. Refer to the base package's location format algorithm for an example. If you prefer a different format, your system administrator should configure the system appropriately

A location context menu has been provided (allowing you to drill to a variety of location-oriented pages)

Division

The location's division

Location - Main

A separate row is displayed for each characteristic linked to the location. The label in each row is the respective characteristic type's description.

The characteristic's value

Location - Characteristic

Control Central - Taxpayer Information

Once Control Central - Main has a person context, you can navigate to this page to view an overview of the related persons, customer contacts, accounts, locations, and obligations linked to the account.

Note:

User configurable. Refer to Each User Can Customize Which Zones Appear for information about how to configure which zones appear.

Description of Page

Note:

Navigation hint. The Go To Control Central option on the person context menu navigates to this tab page.

Note:

A mouse with a roller is useful. This page can extend vertically past the normal desktop boundary. You will find that a mouse with a "roller" will facilitate navigating through the page.

The contents of this section describe the zones that are available on this portal page.

Next in This Section

- Person Tree Zone

- Active Account Summary Zone

- Credit Allocation Detail Zone

- Timeline Zone

Person Tree Zone

The tree in this zone shows a great deal of information including:

- All accounts linked to the person in context.

- Customer contacts linked to this person.

- The hierarchy of parents and children linked this person.

- All aliases linked to this person.

You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.

Active Account Summary Zone

The Active Account Zone lists all accounts related to the person in context. In addition, accounts linked to this person's children also appear in this zone, and if a child has children, the grandchildren's accounts are included. In fact, the system will look for accounts up to five levels deep (meaning that the great, great grandchildren's accounts will be included in this zone).

Note: Only accounts linked to child persons with a financial relationship are shown. When you set up a taxpayer hierarchy, you can define both subsidiaries and "key contacts" (i.e., individuals that you contact at a company). As described above, this zone will include accounts related to these subsidiaries and key contacts. However, you might not want to include the personal accounts related to the key contacts in this zone. You can control which accounts appear in this zone when you set up a hierarchy. You do this by turning on the Financial Relationship switch for those persons whose accounts should be included.

The following columns are displayed in the grid:

Account Info

This column contains the standard account information.

Current Balance

This column contains the account's current balance.

Last Billed Info

This column contains information about the last completed bill sent to the account.

Last Contact Info

This column contains information about the last customer contact associated with the account's main taxpayer.

Control Central - Account Tree

Once Control Central - Main has an account context, you can navigate to the Account Tree to see an overview of the persons, locations, and obligations linked to the account.

Description of Page

This page is dedicated to a tree that shows the various objects linked to an account. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.

Control Central - Location Tree

Once Control Central - Main has a location context, you can navigate to the Location Tree to see an overview of the accounts and obligations linked to the location.

Description of Page

This page is dedicated to a tree that shows the various objects linked to a location. You can use this tree to both view high level information about these objects and to transfer to the respective page in which an object is maintained.

Control Central - Bill/Payment Tree

Once Control Central - Main has an account context, you can navigate to the Bill/Payment Tree to see an overview of the financial transactions linked to the account.

Description of Page

This page is dedicated to a tree that shows the account's bills and payments. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.

For balance-forward accounts, bill nodes contain the balance presented on the respective bill, and pay nodes contain the amount of the respective payment. However, for open-item accounts, the tree behaves differently:

- The amount on bill nodes is equal to the sum of the current charges, adjustments and corrections on the bill.

- Each bill or payment will contain an indication if all of its financial transactions are fully matched. If not, the node will become red to highlight that unmatched financial transactions exist.

- If a bill or payment node is expanded, a summary of the match status of its financial transactions is shown.

How To Add A New Taxpayer From Control Central

There are two ways to add a new taxpayer from control central:

- Invoking the Person page from the menu bar.

- Adding a person from Control Central. You navigate as follows:

- You start from Control Central - Main. On this page, you determine if the taxpayer already exists in the system. If so, select it and you're done. If not, proceed to step 2.

- Click the + button adjacent to the Person button to transfer to Person - Main Information page (with the name you entered already defaulted). Use the Person pages to record all relevant information about the new taxpayer. When finished, proceed to step 3.

When the person exists, you can add account(s) for it by invoking the Account page from the menu bar or from the Person context menu.

Maintaining Persons (Legacy)

This section describes the original person maintenance pages provided with the product. They are only applicable for implementations that continue to use these pages rather than the current person maintenance portal style pages.

Next in This Section

- Person - Main Information

- Person - Correspondence Information

- Person - Characteristics

- Person - Persons

- Person - Web Self Service

- Person - Miscellaneous

Person - Main Information

The Main page contains core person information like names, telephone numbers, and forms of identification. Open this page using Menu > Registration > Person.

Description of Page

Person Information contains basic information about the person. These values only appear after the person exists on the database. The ID is a system-assigned random number that stays with a person for the life of the system.

The following information may be recorded about a person:

Define the Person Type for this person. The person type controls some behavior for the person. It includes a "person/business" indicator that controls the primary name validation. Your implementation's person types may also be configured to define other behavior for persons of this type such as the default primary ID type.

Person Names are used as a primary way to identify a person and are used by most searches throughout the system to find information for an account or person. In addition, a person's primary name is the addressee on the person's correspondence unless overridden by the Override Mailing Name (maintained on the Misc tab). The following fields display:

- Use Name Type to indicate if the name is an Alias, Alternate Representation, Doing Business As, Legal, or Primary name. Note, for new persons, a value of Primary is defaulted.

Note:

The values for the name type field are customizable using the Lookup table. This field name is NAME_TYPE_FLG.

- Use Person Name to define the person's name. Note well, the name is case sensitive.

Note:

Alternate representations of a person's name. You would use an Alternate Representation for a person's name when you have an alternate ways to define the person's primary name. Alternate representations are typically used in countries that use multiple character sets (e.g., the Primary name is entered in Chinese, the Alternate Representation is entered in English). When a person has an alternate name, both the main and alternate names can be used to search for a person. The Alternate Representation Name Type only appears if you have enabled alternate names on the installation record. Refer to the description of the Alternate Representation field under Installation - Main for more information.

Note:

Validation is performed by a plug-in. The validation that is applied to Person Name (e.g., a comma separating the last and first name - Smith,Patricia) is controlled by a plug-in algorithm on the installation record. Refer to the base package's name validation algorithm for an example. If you prefer different validation logic, your system administrator should configure the system appropriately.

Person Phone numbers are used to capture phone numbers for the person. The following fields display:

- Phone Type indicates the type of phone number, e.g., Home, Mobile, Business, …

- Use Phone Number to define the telephone number. Enter the telephone number in the format described by the Phone Format.

Note:

Formatting is performed by a plug-in. The format that is applied to a Phone Number is controlled by the algorithm that is plugged in on the respective Phone Type. If you prefer a different format, your system administrator should configure this algorithm appropriately.

- Enter the Extension, if any, of the telephone number.

A Person's ID's have several uses:

- They are available in various searches throughout the system as search criteria when attempting to find a taxpayer or a record linked to that taxpayer.

- They are used to highlight potential duplicate persons.

- Many searches throughout the system display a person's primary identification in the search results area to help a user identify the taxpayer when multiple taxpayers match the search criteria.

Note:

Person ID may be required or optional. The person ID usage flag on the installation record indicates whether at least one id for a person is required or optional.

The following fields are used to define a person's ID(s).

- Turn on Primary ID for the piece of ID that is the primary means of identifying the taxpayer.

- Indicate the ID Type. The ID Type defaults from the Installation Record based on the Person Type's person/business indicator.

- Enter the identification number in the adjacent fields. Please note that if the ID Number should be formatted (e.g., dashes in an American social security number), you do not have to enter the dashes. Rather, you can enter the information as a contiguous value and the system will format this for you. The format is shown in the adjacent Identifier Format column.

Note:

Formatting is performed by a plug-in. The format that is applied to an ID Number (e.g., dashes in an American social security number) is controlled by the algorithm that is plugged in on the respective ID Type. If you prefer a different format, your system administrator should configure this algorithm appropriately.

Note:

Masking sensitive data. Certain types of person identifiers are sensitive information that should be protected for privacy reasons. The system provides a mechanism for masking this type of data. Refer to Encryption and Masking for more information.

Person - Correspondence Information

This page contains information that may be used to address bills and letters. Use Menu > Registration > Person > Correspondence Info to open this page.

Description of Page

If the person does not want their primary name (defined on the Main page) used on bills and letters, specify the desired name in Override Mailing Name 1, 2, and 3.

For implementations that are configured for legacy addresses, the Override Mailing Address is used if the person wants correspondence sent to an address specific for this person. If the person's account doesn't already indicate that the person's mailing address should be used, you must update this person's account(s). This information resides in the Address Source field on Account - Person.

If you enter an Override Mailing Address:

- The Country defaults from your installation options.

- The address constituents may differ depending on the Country. Refer to Defining Countries for more information on the address constituents.

- If you have set up postal defaults, the system will default the address constituents when you tab out of the postal code.

Specify the taxpayer's Email Address if you communicate with the taxpayer via Email. In addition to defining the person's Email Address, you're correspondence routing software must support sending the information via Email. Refer to the following links for more information: where are bills sent and where are letters sent.

Define the Language in which the person prefers their bills and correspondence printed.

Note:

Default note. The person's language defaults from Installation Options - Person.

Fastpath:

Refer to Taxpayer Language for more information on options for supporting multiple languages for your taxpayers.

For implementations that are configured for legacy addresses, the Miscellaneous Addresses may be used to define additional addresses for the person.

- Select the Address Type. The base product supports a value of Seasonal. See below for additional detail about seasonal addresses. Your implementation may introduce additional values for this field.

Note:

Define values for this field using the Lookup table. This field name is ADDR_TYPE_FLG.

- The Status of the address must be Active. You can set the status to Inactive if you want a seasonal address ignored (alternately, you can just remove the seasonal address).

- The Country defaults from your installation options. The address constituents may differ depending on the Country. Refer to Defining Countries for more information on the address constituents.

- If you have set up postal defaults, the system will default the address constituents when you tab out of the postal code.

The Seasonal address type allows your taxpayer to define one or more alternate addresses to use during predefined periods each year. For example, the taxpayer may want their correspondence sent to their vacation cottage during the summer. Please be aware of the following:

- Seasonal addresses will only be used if the taxpayer's correspondence is routed via the postal service. For example, if you route correspondence to the taxpayer via Email, the seasonal address will never be used to route correspondence to the taxpayer.

- You don't have to specify a seasonal address for every part of the year. For example, if the taxpayer wants correspondence sent to their main address except during the summer, you need only enter a seasonal address for the summer.

- You can enter a seasonal address with or without an Override Mailing Address. If an Override Mailing Address is not specified, the person's correspondence will be addressed as per the instructions on the person's account(s). These instructions reside in the Address Source field on Account - Person.

- You can enter multiple seasonal addresses if the taxpayer so desires.

- The Seasonal period is defined in the two Season fields. The first field contains the day and month when the season starts; the second field contains the day and month when the season ends. The day and month should be entered in the format defined in your display profile.

Person - Characteristics

The characteristics page contains information that describes miscellaneous information about the person. Use Menu > Registration > Person > Characteristics to open this page.

Description of Page

Note:

You can only choose characteristic types defined as permissible on the person record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

Effective Date

Define the date on which the characteristic becomes effective. The effective date defaults from the Installation Record .

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Person - Persons

This page is used to define this person's relationship with other persons. For example, if the person being maintained is a conglomerate, you can define its subsidiaries on this page.

Note: You're defining "child relationships". It's important to understand that the persons being defined on this page's grid should be thought of as "children" of the person on the top of the page.

Note: Children may have children. It's possible for one of the children to have children itself (for example, if you have a situation where a subsidiary of a conglomerate itself has subsidiaries). To define a child's children, simply display the child person on this page and then define its children.

Note: Equal relationships. It's possible to link persons where no hierarchy is implied by the relationship (e.g., spouses). There are two ways to do this: 1) you can nominate one spouse as the "parent" and the other as the "child" or 2) you can define the spousal relationship for both persons (i.e., you would define Robert Chopin as the husband of Jeanette Chopin, and Jeanette Chopin as the wife of Robert Chopin). If you choose the latter approach, a recursive relationship will exist.

CAUTION:

If your organization enters multiple levels of person, we want to point out that we do not prevent recursive relationships. This means that you could set up a nonsensical situation where person 2 is a child of person 1 and person 1 is a child of person 2.

Use Menu > Registration > Person > Persons to open this page.

Description of Page

The grid contains the "children" associated with the "parent" person who is defined at the top of the page. The following fields display:

Child Person

This is the unique identifier of the "child" person. This person's main name appears adjacent.

Child Information

An informational message appears to highlight if the child person itself has children. You can click the corresponding go to button to view the child's children.

Relationship Type

Indicate the type of relationship between the parent and the child person.

Start Date

Indicate the date on which this relationship began. This field defaults from the Installation Record .

End Date

If the relationship expires, indicate the date the relationship stops.

Financial Relationship

Turn on this switch if the child person has account(s) and information about these account(s) should be displayed when the parent person's hierarchy is displayed in the Active Account Summary Zone .

Person - Web Self Service

This page is used to define information for this person to access account information via your web self-service application.

Note: Optional information. This functionality was originally supplied for a sample web self service implementation that is no longer supported by the base product. It remains in the system for upgrade purposes. Implementations may opt to use this data to capture information for a custom WSS integration. If your implementation does not take advantage of the data captured on this tab, it may be suppressed by turning off the WSS (Legacy) module.

Use Menu > Registration > Person > Web Self Service to open this page.

Description of Page

The information on this page is entered by the taxpayer when registering for the web self service application.

Note: Web User ID. The legacy web self service functionality provided by the system defines the taxpayer's web user ID using an entry in the person ID collection defined on the main tab. The Web Self Service Password chosen by this person through the web application is stored encrypted and cannot be viewed. Taxpayers should change their password via the web application.

The Web Self Service Password Hint and Web Self Service Password Answer are defined by the taxpayer when registering and are used when the taxpayer has forgotten the password.

Note: The values for the password hint field are customizable using the Lookup table. This field name is WEB_PWD_HINT_FLG.

Web Self Service Receive Marketing Info indicates whether or not the taxpayer has chosen to receive marketing information. The possible values are Receives Marketing Info and Doesn't Receive Marketing Info. This information may be used by your web application to optionally send marketing information to this taxpayer via email.

Person - Miscellaneous

This page contains zones that show where this person may be linked to Accounts or Tax Roles. Use Menu > Registration > Person > Miscellaneous to open this page.

Description of Page

The Person's Account Relationship List zone lists information for all the accounts to which the person is linked, together with the relationship type description. It provides the ability to filter the list by account relationship type.

The Tax Role Relationship List lists information for all the tax roles to which the person is linked, together with the relationship type description. It provides the ability to filter the list by tax role relationship type and account.

Maintaining Locations

The location record contains geographic information about your service addresses.

The following methods list the various ways in which locations can be created:

- A location can be added via the location replicator.

- A location can be added using this transaction.

The topics in this section describe the location maintenance transaction.

Next in This Section

- Location - Main Information

- Location - Characteristics

- Location - Geographic Data

- Location - Alternate Address

Location - Main Information

The Location page contains basic location information. Open Menu > Registration > Location to maintain this information.

Description of Page

Basic information about the Location and the location's unique identifier (i.e., the Location ID) are displayed on every page. These values only appear after the location exists on the database. The ID is a system assigned random number that stays with a location for life.

Enter a Location Type to categorize the type of location.

The address's constituent fields vary based on the Country. Please refer to the Country page for more information.

Note:

Default note. A location's state, city, county, division, characteristics and geographic data default from your postal default information. If you change the location's postal code, the system will default geographic values based on the new postal code.

Use Division to define the jurisdiction in which the location is located. This defaults based on the Country and the Postal Code, but can be overridden here.

Indicate whether the address is a valid Mailing Address. Locations that are valid mailing addresses may be specified as the mailing location on an account. Refer to Account - Person Information for more information.

You may reference a Parent Location to include this location in a location hierarchy.

At the bottom of this page is a tree that shows the various objects linked to the location. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained.

Location - Characteristics

The Characteristics page contains information that controls taxation and other rate options that differ based on geography. Use Menu > Registration > Location > Characteristics to open this page.

Description of Page

The assessed value of a location and the total obligation amount are controlled by the location's characteristic values (e.g., the taxing city defines the city tax percent applied to the location's value or certain renovations made to the location affect the appraised value). Refer to An Illustration Of A Rate Factor And Its Characteristics for more information.

Note:

You can only choose characteristic types defined as permissible on the location record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

Effective Date

Indicate the effective date of the characteristic type and value. The effective date defaults from the Installation Record when you are adding a new location. The effective date defaults to the current date when you are changing an existing location.

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Note:

Default note. A location's characteristics default from your postal default information. Refer to Setting Up Location Postal Defaults for more information. If you change the location's postal code, the system will default characteristic values based on the new postal code.

Location - Geographic Data

The Geographic Data page contains information that defines where the location is located. Use Menu > Registration > Location > Geographic Data to open this page.

Description of Page

Enter the Time Zone in which the location is located. This value defaults from your postal defaults. The following fields display:

Geographic Type

Indicate the type of geographic data.

Geographic Value

Specify the coordinate value. If the entered value must be in a specific format, a description of the required format is displayed adjacent. For example, if you see the format 99A 99A 99 9, you must enter 2 numbers, followed by a letter, followed by a space, followed by 2 numbers, followed by a letter, followed by a space, followed by 2 numbers, followed by a space, followed by a single number.

Note:

Formatting is performed by a plug-in. The format that is applied to a Geographic Value is controlled by the algorithm that is plugged in on the respective Geographic Type. If you prefer a different format, your system administrator should configure this algorithm appropriately. Note, algorithms of this type will NOT convert the input value into the relevant format (i.e., you must enter the information in the exact format dictated by the algorithm).

Note:

Default note. A location's geographic data defaults from your postal default information. Refer to Setting Up Location Postal Defaults for more information. If you change the location's postal code, the system will default geographic values based on the new postal code.

Location - Alternate Address

CAUTION:

This tab only appears if you have enabled alternate addresses on the installation record. Refer to the description of the Alternate Representation field under Installation - Main for more information.

This page is used when you have an alternate way to define a location's address. This is typically used in countries that use multiple character sets (e.g., the Main address is entered in Chinese, the Alternate Address is entered in English). When a location has an alternate address, both the main and alternate addresses can be used to search for a location.

Open Menu > Registration > Location > Alternate Address to maintain this information.

Description of Page

The remaining fields on the page are used to define the location's alternate address.

The address's constituent fields vary based on the Country. Country is always protected on this page because a location's alternate address must be located in the same country as its main address. Please refer to the Country page for more information about address constituents.

Note:

Default note. An alternate address's state, city and county default from your postal default information. Refer to Setting Up Location Postal Defaults for more information.

The Swap Main / Alt Address button becomes enabled when you've entered an Alternate Address. When clicked, the contents of the address on the Main tab are swapped with the Alternate Address.

Additional Location Management Tools

Next in This Section

- Using The Location Replicator

- Location Management

- Location Management Page

Using The Location Replicator

You use the location replicator to create many copies of a location.

Perform the following steps to replicate a location:

- Add a location.

- Use the location replicator to create copies of the location.

The topics in this section describe how to use the location replicator.

CAUTION:

The system warns you if you attempt to create. However, this is just a warning as you may want to generate similar locations and then update them with, for example, a unique apartment number on Location - Main Information.

Next in This Section

- Location Replicator - Main

- Location Replicator - Location

Location Replicator - Main

Use Menu > Registration > Location Replicator to open this page.

Description of Page

Choose the Location that serves as the template location.

Note:

Recommendation. Carefully verify the template location using the other pages in this page before you save the replicated locations. After you save the replicated locations, any corrections could prove time consuming.

The two sections at the top of the page determine the number of replica locations to be created and the address information that will be set up for each location. The left section is used to define how the system will create the part of the address that is different for each replica location. The right section defines the parts of the address that will be the same for each replica location.

In the left section:

Use the Replicate option to control how the position of the replicated number in the first address line:

- Choose Street Number if the replicated number should prefix the Base value in the first address line of the location. For example, if you have a Start # of 1020 and a Base value of Main St and you choose the Street Number option, the first replicated location will be 1020 Main St.

- Choose Apartment Number if the replicated number should suffix the Base value in the first address line of the location. For example, if you have a Start # of 1020 and a Base value of 101 Main St, Apt. and you choose the Apartment Number option, the first replicated location will be 101 Main St, Apt. 1020.

Indicate the Number Of Locations you wish to create.

Use Base to define the information that will appear at the end of the first address line on each of the replicated locations. Use Start # to define the number assigned to the first copy of the location. Use Increment to define the value to increment successive numbers by. The first and last address lines to be created by the replicator are displayed below.

For example, if the first address you want to create is 101 Derby St, and the last address is 199 Derby and you want to do the odd numbered side of the street, you'd enter the following parameters:

Number of Locations would be 50

Address Suffix would be Derby St

Start From would be 101

Increment by would be 2

The right section displays the rest of the address information that will be copied onto each replicated location. This information is defaulted from the template location that you selected. The Address 1 field is not shown because you define the information to be entered there in the previous section, as explained above. The remaining fields, however, may be edited if so desired.

After entering the parameters, click the Replicate button to generate your new locations. You can use the sections at the bottom of the page to view the locations that will be created when you click save. The left section will show how Address Line 1 will look on the first 10 locations. If you are creating more than 10 locations, the right section will show how Address Line 1 will look on the last 10 locations. If everything looks clean, click save.

Location Replicator - Location

The Location page is a display only page provided to let you confirm that the location you selected on the add dialog is the one to be used as the template by the replicator. Use Menu > Registration > Location Replicator > Location to open this page.

Description of Page

This is a display only page that displays key information about the location being replicated.

Location Management

The location management functionality facilitates the following:

- Grouping locations together under a single parent location

- Quick & efficient setup and maintenance of apartment complexes and high-rises

- And more…

The topics in this section describe location management functionality.

Next in This Section

- Define Location Hierarchy

- Manage Groups of Locations

Define Location Hierarchy

Location management allows you to define location hierarchy. For example, you could also have the notion of

- A building

- Multiple floors

- Multiple apartments per floor

To define this hierarchy you must create a location for each level in the hierarchy and for each "child" location, indicate its appropriate parent location. Once you have set up your location hierarchies, you may view the hierarchies on trees on the location page and on the control central location tree.

In addition, the system provides the following alerts:

- When viewing a parent location, an alert indicates how many child locations exist

- When viewing a child location, an alert indicates that it is linked to a parent location.

Manage Groups of Locations

The powerful search criteria on the location management page allows you to view different groups of locations based on any combination of parent location address information and general geographic type information. You may also define search criteria such "locations linked to any parent location" or "locations not linked to any parent location". For example, you could display all locations in a given latitude / longitude that are not linked to any parent location.

Once your search results display the desired list of locations, you could do a mass update to assign or remove the parent location.

Location Management Page

This page allows you to display a list of locations using a combination of search criteria. In addition, you can perform actions on one or more of the resulting locations, including:

- Assigning a parent location to one or more locations

- Removing the link to a parent location from one or more locations

Open this page using Menu > Registration > Location Management.

Description of Page

The top half of the page is where you enter the criteria used to search for locations.

Note:

Multiple search criteria may be specified. You can search for locations using a combination of search criteria.

Note:

At least one positive criterion is required. You may not define your search criteria to only use filter values that start with "Not Linked…". At lease one "positive" filter value is required.

The following table describes each of the different search methods.

Search Method

Description

Parent Location Filter

Use this filter to narrow down your search based on parent location. Enter one of the following values:

Not Applicable

Linked To This Parent Location - for this option, you must enter a Location ID for the parent location

Not Linked To This Parent Location - for this option, you must enter a Location ID for the parent location

Linked To Any Parent Location

Not Linked To Any Parent Location.

A filter value of Not Applicable defaults.

Location Filter

Use this filter to narrow down your search based on account. Enter one of the following values:

Located At This Address - for this option, you must enter address constituents

Located At This Geographic Type / Value - for this option, you must enter a Geo Type and Value

Not Applicable

Show This Specific Location - for this option, you must enter a Location ID

A filter value of Not Applicable defaults.

The Select All / Clear All buttons are used to select locations if you plan on issuing any of the mass update actions at the bottom of the page. Refer to the description of the "mass update" actions below for more information.

Note:

50 locations at a time. Clicking Select All selects the first 50 locations in the grid. If more than 50 locations exist, you must select them in batches.

The grid that follows contains the locations that match your search criteria. The following information appears in the grid:

- Select box. Use this checkbox to select locations for mass update actions.

- The Location Information column shows information about each location. Click the hyperlink to transfer to the Location page where you can update information about the location in question.

- The Parent Location Information column displays information about the location's parent location, if one exists.

This transaction has sophisticated logic that can be used to perform "mass updates" to the locations that appear in the grid using the buttons at the bottom of the page. The buttons are enabled if you select at least one row from the location grid. The following points describe these mass update actions:

The Assign Parent Location button is used to assign a parent location to one or more locations. When clicked, the Assign Parent Location window opens. Specify the Parent Location ID and click Assign.

The Remove Parent Location button is used to remove the parent location from one or more locations. When clicked, the parent location ID of all selected locations is reset.

Setting Up Bill Print Groups

Bill print groups allow you to categorize an account's obligations into groups for bill print purposes.

Note:

Bill print groups are optional. Typically, only accounts with many obligations will use bill print groups because the standard bill print priority is sufficient for accounts with a limited number of obligations. Refer to Obligation Type - Billing for more information about the standard bill print priority.

Let's use an example to clarify the bill print group concept. Consider a local government's account. This account would have many obligations (some for the police department, others for the court system, others for the department of public works, etc.).

If you don't create a bill print group for this taxpayer, their bill segments will be printed in the order dictated by each segment's obligation's obligation type's bill print priority. If you create a bill print group for this taxpayer, you can define the taxpayer's desired categories (e.g., police, courts, DPW, etc.) and then link each of the account's obligations to the appropriate category.

Note:

Nomenclature. We refer to the categories under a bill print group as "subgroups". A bill print group can have an unlimited number of subgroups. When you create a subgroup, you define its relative bill print priority and the associated verbiage to print on the bill (assuming you print information about the subgroup on the bill).

We'd like to highlight the following characteristics of bill print groups:

- A bill print group is associated with a specific account. If multiple taxpayers have the exact categorization preferences, you will have to set up multiple bill print groups.

- Over time, a taxpayer could have many bill print groups. This would happen if a taxpayer's bill categorization preferences change over time. We'd like to stress that while an account can have multiple bill print groups, only one will be used by the bill print process (the one effective on the bill date).

- Bill print groups only affect printed bills. Bill print groups do not affect the order in which obligations appear on the bill maintenance transaction.

- If new obligations are added after a bill print group is set up for an account, they will not be linked to a subgroup. If you neglect to link the new obligations to one of the bill print group's subgroups they will be printed under the "default" subgroup (every bill print group must have one default subgroup to cater for this situation).

CAUTION:

Important! While the system supports the definition of bill print groups and the categorization of an account's obligations into the various subgroups, the base package's bill print extract does NOT take advantage of this information.

The topics in this section describe how to set up a bill print group and how to link an account's obligations to its subgroups.

Next in This Section

- Bill Print Group - Main

- Bill Print Group - Obligation Sub Group

Bill Print Group - Main

Open Menu > Registration > Bill Print Group to maintain an account's bill print group and subgroups. After defining this information, transfer to the Obligation Sub Group tab to link the account's obligations to the subgroups.

Description of Page

The Bill Print Group ID is displayed on every page. This value only appears after the bill print group exists on the database. The ID is a system-assigned random number that stays with a bill print group for life.

Enter the Account ID associated with the bill print group.

Use Effective Date to define when the bill print group is effective for the account. This date is important as it allows a taxpayer to change their preferences over time. For example, if the taxpayer wants to change the number of subgroups on a given date, you would simply add a new bill print group effective on this date and then define the new subgroups (and link each obligation to one of the subgroups).

Use Status to define if the bill print group is Active or Inactive. You would only use the Inactive value if the bill print group is no longer needed (as there is no delete action on this transaction).

Enter a brief Description of the bill print group.

Use Comments to describe anything special about the bill print group.

The grid contains the bill print group's subgroups. The following information should be defined for each subgroup:

- Bill Print Sub Group. This is the unique identifier of the bill print subgroup.

- Sub Group Bill Print Priority. This is the relative print priority of the subgroup in respect of the other subgroups.

- Use as Default. Turn on this switch for the default sub group. A bill print group must have one and only one default subgroup. The default group is used by the bill print process if it detects an obligation that is not linked to a subgroup (it links this obligation to the default subgroup).

- Sub Group Description. This is a brief description of the subgroup.

- Description on Bill. This is the verbiage that will print on the bill (assuming you print something on your bills for the subgroup).

After defining the bill print group's subgroups, navigate to the Obligation Sub Group tab to link the account's obligations to the subgroups.

Bill Print Group - Obligation Sub Group

This page is used to link the account's obligations to one of the bill print group's subgroups.

Open Menu > Registration > Bill Print Group > Obligation Sub Group to maintain this information.

Description of Page

The Bill Print Group's ID, Account ID and Effective Date are displayed at the top of the page.

The filters control the obligations that appear in the Obligations in Bill Print Group grid. The following points describe the various options:

- Use the Obligation Filter to define the types of obligations that appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict obligations based on obligation attributes.

- Bill Print Sub Group. Use this option to restrict obligations to those that are linked to a given Bill Print Sub Group.

- Obligation type. Use this option to restrict obligations to those linked to a given Division and Obligation Type.

- Use Status Filter to restrict the obligations based on their status. The following options are available:

- All. This option shows all obligations regardless of status.

Don't forget to click the search button after changing the filters.

The Obligations in Bill Print Group contains an entry for every non-cancelled obligation linked to the account that is linked to one of the bill print group's subgroups. The following information appears in the grid:

- Use Bill Print Sub Group to define the subgroup associated with the obligation.

- Use Sequence when there is more than one obligation in the subgroup. The sequence controls the order in which the obligation's financial information appears on the bill.

- The Obligation Information column provides a brief description of the obligation.

- The Obligation column contains the unique identifier of the obligation.

- The Location Information column contains the characteristic location associated with the bill segment's obligation.

The next set of filters control the obligations that appear in the Obligations Not in Bill Print Group grid. The following points describe the various options:

- Use the Obligation Filter to define the types of obligations that appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict obligations based on obligation attributes.

- Obligation type. Use this option to restrict obligations to those linked to a given Division and Obligation Type.

- Use Status Filter to restrict the obligations based on their status. The following options are available:

- All. This option shows all obligations regardless of status.

Don't forget to click the search button after changing the filters.

The Obligations Not in Bill Print Group contains an entry for every non-cancelled obligation linked to the account that is NOT linked to one of the bill print group's subgroups. The following information appears in the grid:

- Use Bill Print Sub Group to define the subgroup associated with the obligation.

- Use Sequence when there is more than one obligation in the subgroup. The sequence controls the order in which the obligation's financial information appears on the bill.

- The Obligation Information column provides a brief description of the obligation.

- The Obligation column contains the unique identifier of the obligation.

- The Location Information column contains the characteristic location associated with the bill segment's obligation.

Forms Processing

In this section, we describe working with tax forms, registration forms and uploading either of these types of forms from an external system.

Next in This Section

- Understanding Forms

- Maintaining Registration Forms

- Maintaining Tax Forms

- Maintaining Form Batch Headers

- Maintaining Form Upload Staging

- Maintaining Form Controls

Understanding Forms

This section describes concepts related to forms processing.

Next in This Section

- Registration Forms

- About Tax Forms

- Validating Forms

- About Suspended Forms

- Forms May Wait for Information

- About Form Versions

- About Uploading Forms

- Form Control Overview

Registration Forms

A registration form is a form that is used for taxpayer registration, for example a business registration form or demographic maintenance, for example, a change of address form. Forms of this type do not result in any financial impact for a taxpayer. Processing these types of forms typically results in updates to taxpayer information.

Each registration form refers to a form type that defines the form section and lines and includes the rules that govern the validation and processing of the registration form data.

Note:

Your implementation defines your forms and the rules for processing these forms. Refer to Defining Form Processing Options for details.

About Tax Forms

A tax form represents the fulfillment of an obligation to file a tax return for a given filing period. Tax forms may be interfaced from an external source or created in the system.

Each tax form refers to a form type that defines the form section and lines and includes the rules that govern the validation and processing of the tax form data. It also identifies the obligation type (and therefore tax type) for the tax form.

Note:

Your implementation defines your forms and the rules for processing these forms. Refer to Defining Form Processing Options for details.

Validating Forms

After a tax form or registration form's data has been entered into the system, it must be validated. A user may request the validation of a given form. Alternatively, a background process runs periodically to pick up forms awaiting validation and processes them.

Tax forms and registration forms are validated by executing rules that are configured for the form's form type. If a form passes validation, it continues through to a state where the form is ready to post.

If there are any validation errors or missing information, the details are captured as exceptions to the form.

On Demand Validation

There are cases where a user may be entering data or correcting data in a form and may want to check the form's validity. The product provides the ability to execute validation rules and return the list of possible exceptions for display to a user, if the form's business object has been configured to do so.

Note:

The base product has implemented this logic for the Tax Form and Registration Form parent business objects. For any specific form business object that refers to one of these as its parent business object, this functionality is available.

When a user is creating a form or is changing a form in a state that allows changes, a Check Form button is available. Clicking this button executes the form type's validation rules for the current view of the form. If any exceptions are found they are displayed to the user.

Note:

No updates to the database are made for on-demand validation. A user must save the form and click Validate to update the form and cause updates to the form exceptions.

About Suspended Forms

When a tax form or registration form fails a validation rule, the configuration of the rule indicates whether or not the form should suspend. If one or more of the exceptions for the form indicate that it should suspend, it moves to the Suspended state. A To Do is generated using the message of the suspense issue with the highest priority. An appropriate user must review the suspense issue(s) and correct them.

Refer to Correcting Suspended Tax Forms or Correcting Suspended Registration Forms for more information.

Forms May Wait for Information

When a form fails a validation rule, the configuration of the rule indicates whether or not the form needs additional information. If there are no suspense issues and one or more of the exceptions for the form indicate that it requires more information, it moves to the Waiting for Information state.

At this point it may be that a letter is sent to the taxpayer requesting the missing information. A rule configured on the form type is responsible for initiating such a letter.

The system monitors registration forms that are waiting for information to ensure that the forms are not waiting for too long. The number of days that are considered too long depends on your system configuration.

About Form Versions

A form's data is likely to be modified a number of times during its lifetime. The system stores a version of a form (a snapshot of the data for the entire form) when certain changes are made.

- After a form is created, just before validation rules are executed. This version is considered the As Reported version. Note that in addition to capturing a full version of the form at this time, any individual form line that has been configured in the system to include an As Reported element, which
is snapshot of the original values that was reported on the line. It is populated when the form exits the Pending state and is visible to a user when viewing the current version of the form.

- If the form enters a status that allows user modification, a form version is captured. This is done in case form rules made automatic updates to any form lines after the initial "as reported" version is captured. In the base product business objects for registration form and tax form, this applies to the Suspended, Waiting for Information and Re-edited states.

- If the form is changed by a user while in the a state that allows user modification, a version is captured. Based on how the form type is configured, the user may be required to provide an overall reason for changing the form or reasons for changing each individual line or both.

A version is not captured for the final posted version of the form. The current data in the form is considered the current version.

About Uploading Forms

Many tax forms and registration forms are received in batches from an external source. In addition, many tax authorities have imaging equipment that captures paper returns and can produce files to upload to the system.

Forms that are uploaded to the system are created as Form Upload Staging records with a Form Batch Header record that groups together uploaded records that belong to a given batch of forms.

Each form upload staging record refers to a form upload staging type that defines the source of the information, the destination form type and tools for mapping the data received to the expected format in the resulting tax form or registration form.

Note:

Your implementation defines your form upload staging types and the rules for processing these upload records. Refer to Form Upload Staging Type Controls Everything for details.

Next in This Section

- Form Batch Header Details

- Form Upload Staging Details

- About Processing Batches of Forms

Form Batch Header Details

Forms uploaded in batch are grouped by form batch headers. The form batch header defines what types of forms can be included in the batch. It is also a control record as it can capture summary information about the included form upload staging records.

Note:

Refer to Designing Form Batch Headers for more details on what form batch headers can define.

Form Upload Staging Details

Actual form data is uploaded through a 'raw' XML field in the form upload staging record.

A form upload staging record specifies a type, which controls how the uploaded data is mapped and stored into tax forms or registration forms.

About Processing Batches of Forms

After a batch of forms has been uploaded to the system, several steps are needed to successfully upload the batch of forms. The following steps highlight the process. Note that many of these steps are performed by background processes.

- The form batch header is validated. If there are any problems, it gets suspended and a user must fix the problems before continuing. Refer to Correcting Suspended Form Batch Headers for more information.

- If the form batch header is valid, the form upload staging records are validated. If there are any problems, the record is suspended and a user must fix the problems before continuing. Refer to Correcting Suspended Form Upload Staging Records for more information.

- Each form upload staging record that passes validation goes through the step of mapping the input data to the target form type. At this point, the following may occur:

- An error may be received in the process of attempting to map the data. This is typically a result of a problem with the submission and not something a user is able to fix. In this case, the record is rejected. If any form upload staging records are rejected, a user is alerted and may choose to cancel the batch. Refer to Reviewing Batches Where Records Were Rejected for more information.

- The algorithm may perform some basic form validation, for example to detect missing data such as a receive date. In this case the record is suspended and a user must fix the problems before continuing. Refer to Correcting Suspended Form Upload Staging Records for more information.

- Once a form upload staging record passes the validation and mapping steps, it transitions to the Ready to Load state. If all upload staging records are ready to load, the next step is to create the resulting tax form or registration form.

Form Control Overview

The base product's standard set of form processing batch jobs are configured by default to process all tax and registration forms received. Any form that passes validation is processed through to Posted if all the batch processes are run.

There are some implementations that want to control volumes of tax forms that are posted and prefer to select which tax forms should be posted. In addition, certain implementations may choose to hold off on processing a certain set of tax forms. The product provides an object called Form Control that may be used by implementations that prefer to work this way. The following topics provide more information about form control records.

Note: Form control is only applicable to tax forms.

Creating Form Controls Via Interface

In this approach, analysis is performed using an appropriate reporting or analysis tool. The tax form IDs are selected in that tool and interfaced to the system.

Creating Form Controls For Uploaded Forms

Form controls can also be created automatically for batch-uploaded forms. A special background process can be run after form upload and tax form validation, to create a form control for each processed form batch header and to link the included tax forms to the form control.

Tax Form Link Status

The tax forms that are eligible to be linked to a form control are in a status of Ready for Posting and remain in that state until the form control is approved. There is another status, referred to as the Link Status that identifies the status of a particular tax form to a particular form control. The following points highlight the status values.

- When a tax form is initially linked it has a link status of Active. Only tax forms linked as active are considered eligible for posting.

- A tax form's link status may change to Skipped by the validation if the algorithm detects that the tax form is no longer in the status Ready for Posting. For example, maybe the status of the tax form is now Canceled due to some other process. The background process that posts tax forms linked to an approved form control may also detect this situation.

- A tax form's link status may change to Invalid by the validation if external IDs are provided by the interface and the validation algorithm cannot find a tax form for that external ID (DLN).

- A tax form's link status may change to Duplicate if it is found that the tax form is listed twice in the list for a given form control or if it is found to be linked to another form control. This is especially important for form controls that are put on hold. Refer to the Form Control Review section that follows for more information.

Form Control Review

Once the form control and its list of tax forms are validated, the system transitions the record to Approval in Progress and a To Do entry is created to alert the appropriate user(s). At this point, the reviewing user may do one of the following.

- If there is some issue related to this group of forms that needs to be investigated and the revenue authority would like to hold posting of the forms until an investigation can take place, the user should transition the form control to the On Hold status. The record remains in this status until a user rejects or approves the form control. All the tax forms linked to form control records in this are held from further processing. The system checks whether the tax forms in the On Hold form control are linked to an approved form control. If so, the link status of the tax form for the approved form control is updated to Duplicate .

- If the user decides that the form control was not created correctly or has decided not to process the form control, it may be Rejected. The tax forms remain linked to the form control as an audit. But the tax forms are now eligible to be linked to a different form control.

- If the form control appears correct the user may

- When a form control is correct and the user would like the tax forms to be posted, it may be transitioned to Approved. Note that if it is determined that any tax forms in this form control are also linked to a form control that is On Hold, the tax form is marked with a link status of Duplicate in the approved form control and will not be processed.

Posting the Tax Forms

Once a user approves a form control, a batch process processes the linked tax forms to transition them to posted. The expectation is that this process is part of the nightly batch cycle because it creates financial transactions and other objects based on the tax form posting rules. As such there may be a delay from the time that a form control is approved to the time its related tax forms are posted.

Maintaining Registration Forms

To create a registration form, navigate using Menu > Forms > + Registration Form . Choose the appropriate form type to continue. Fill in the registration form details and click the save button.

Registration forms can also be created as part of processing uploaded forms. Refer to About Uploading Forms for more information.

Use the Registration Form transaction to view and maintain registration forms. Navigate using Menu > Forms > Registration Form. The section describes the tab pages that appear on the Registration Form portal.

Next in This Section

- Registration Form Query

- Registration Form Portal

- Common Registration Form Procedures

Registration Form Query

Use the query portal to search for an existing registration form. Once a registration form is selected, you are brought to the maintenance portal to view and maintain the selected record.

Registration Form Portal

Next in This Section

- Registration Form - Main

- Registration Form - Exceptions

- Registration Form - Versions

- Registration Form - Log

Registration Form - Main

This portal appears when a registration form has been selected from the Registration Form Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Registration Form Zone

The Registration Form zone contains display-only information about the registration form.

Please see the zone's help text for specific information about the data displayed in the form.

Registration Form - Exceptions

When a form's data is validated the system may identify errors which it stores as exceptions. To see the exceptions associated with the tax form, navigate to the Exceptions tab.

This list of the registration form exception records is displayed. Select a specific exception to view detailed information about the exception.

Registration Form - Versions

Some form types require a form version to be created if the form is modified while in a certain state. If a form has versions, you can view them by navigating to the Versions tab.

The list of versions for the form is displayed. Select a specific version to view the snapshot of the form data in that version of the form and the exceptions that were in effect at the time of that version.

Fastpath: Refer to About Form Versions for information about when versions are captured.

Registration Form - Log

This is a standard log zone.

Common Registration Form Procedures

This section describes common registration form procedures based on functionality provided in the base product.

Note: The functionality described in this section is based on the business objects supplied by the base product. It is possible for your implementation to implement different business processes.

Next in This Section

- Manually Adding Registration Forms

- Correcting Suspended Registration Forms

- Re-editing Registration Forms

- Manually Posting a Valid Registration Form

- Canceling Registration Forms

Manually Adding Registration Forms

Use this procedure to manually add a registration form.

- Use the menu navigation to launch the add a registration form dialogue.

- Use the form type search to find the form type you wish to add. The maintenance map of the chosen form type is displayed.

- Enter the form data. The Save and Continue button allows for interim saves. The Save when the form is completely filled in.

Note: The base business objects do not capture versions when a form is in pending status. It captures the initial "as reported" version only when transitioning to the Validate state. Refer to About Form Versions for more information.

- Click Validate or Validate and Post to process the form. If Validate and Post is clicked and the form does not have any exceptions, the form is posted. No further processing is needed. Otherwise,

- If the user clicks Validate and the form passes validation, it transitions to the Ready for Post status. Refer to Manually Posting a Valid Registration Form for further information.

- If the form does not pass validation and transitions to the Suspended status, the user may correct the form as needed. Refer to Correcting a Suspended Registration Form for further information.

- If a validation form rule indicates that additional information is needed the form transitions to the Waiting for Information status. From here the logic depends on your business rules, but typically forms in this state trigger a letter to the taxpayer requesting for more information.

Note: A manually created form will not get processed by the batch form monitor process. The user must progress the form by clicking Validate or Validate and Post.

Correcting Suspended Registration Forms

If a registration form has suspense issues that prevent it from being posted, you must correct them and then validate the registration form.

- Navigate to the registration form portal and display the registration form you want to validate.

- If you have not already corrected the condition causing the issues, do so now. Click the Edit button in the Actions zone. Review the exceptions reported and use the down arrow adjacent to the exception message to drill to the data in error.

- Correct the error. Depending on the configuration of the form type, you may be required to enter a change reason for the individual line being corrected or an overall reason for the change or both. Save the record. (Upon successful save, you are returned to the Registration Form portal.)

- Click the Validate button in the Actions zone.

The system attempts to validate the registration form.

- If the system still detects issues with the registration form, the issues are displayed for your review.

- Any suspense issues that are resolved get closed.

- Any suspense issues that are still not resolved remain open.

- Any new suspense issues are added to the list.

Repeat this process to resolve the issues and then re-validate.

- If validation succeeds, its status is updated and the registration form is ready for posting.

Note: Refer to Manually Posting a Valid Registration Form for information on posting a valid form.

Re-editing Registration Forms

Use this procedure to update a registration form that has passed validation, has not yet posted and has been identified as needing correction. You can only re-edit a registration form if its current status supports it. If the action is not supported, the Re-edit button will not be displayed.

- Navigate to the Registration Form portal and display the form you want to re-edit.

- Click Re-edit in the Actions zone. The maintenance map will display. Edit the form and make desired changes. Depending on the configuration of the form type, you may be required to enter a change reason for the individual line being corrected or an overall reason for the change or both. Save the form.

- The system updates the state of the registration form to Re-edited. The form stays in this state until you try to validate / post.

Note: A form version is captured every time a Re-edited form is updated.

Manually Posting a Valid Registration Form

Registration forms that pass validation transition to the Ready for Posting state. At this point, a subsequent batch process transitions it further to the Posted status the next time it runs. Forms that are manually transitioned to Ready for Posting may be posted real time by clicking Post if a user does not wish to wait for the batch process to run.

Canceling Registration Forms

Use this procedure to cancel a registration form that has not been finalized.

You can only cancel a registration form if its current status supports it. If the action is not supported, the Cancel button will not be displayed.

- Navigate to the Registration Form portal and display the registration form you want to cancel.

- Click the Cancel button in the Actions zone. Enter an appropriate cancel reason.

The system validates the action and displays an error message if the action cannot be completed.

Maintaining Tax Forms

To create a tax form, navigate using Menu > Forms > Tax Form . Choose the appropriate tax type and the form type to continue. Fill in the tax form details and click the save button.

Tax forms can also be created as part of processing uploaded forms. Refer to About Uploading Forms for more information.

Use the Tax Form transaction to view and maintain tax forms. Navigate using Menu > Forms > Tax Form. The section describes the tab pages that appear on the Tax Form portal.

Next in This Section

- Tax Form Query

- Tax Form Portal

- Common Tax Form Procedures

Tax Form Query

Use the query portal to search for an existing tax form. Once a tax form is selected, you are brought to the maintenance portal to view and maintain the selected record.

Tax Form Portal

This page appears when viewing the detail of a specific tax form.

Next in This Section

- Tax Form - Main

- Tax Form - Exceptions

- Tax Form - Versions

- Tax Form - Log

Tax Form - Main

The topics in this section describe the base-package zones that appear on this tab.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Tax Form Zone

The Tax Form zone contains display-only information about the tax form.

This zone also displays any existing tax form exceptions. The exception list includes a 'go to' button that allows quick navigation to the field in error.

This zone may also display the following when the tax form being displayed is a generated tax form.

- A Form Navigator appears on the left hand side and contains quick links to the various sections of the form and an option to display the full form.

- The Main section shows basic information that is common to all tax forms. It includes a dropdown that provides a way of quickly navigating to the obligation's other forms.

- Form Change Reasons / Comments are displayed when the tax form has history of changes (e.g. while in suspended state).

Please see the zone's help text for specific information about the data displayed in the form.

Estimated Balance Details Zone

This zone appears for audit forms only. It shows the detailed P&I view for either a proposed audit assessment or an actual audit assessment.

Please see the zone's help text for specific information about the data displayed in the zone.

Tax Form - Exceptions

When a form's data is validated the system may identify errors which it stores as exceptions. To see the exceptions associated with the tax form, navigate to the Exceptions tab.

This list of the tax form exception records is displayed. Select a specific exception to view detailed information about the exception.

Tax Form - Versions

Some form types require a form version to be created if the form is modified while in a certain state. If a form has versions, you can view them by navigating to the Versions tab.

The list of versions for the form is displayed. Select a specific version to view the snapshot of the form data in that version of the form and the exceptions that were in effect at the time of that version.

Fastpath: Refer to About Form Versions for information about when versions are captured.

Tax Form - Log

Navigate to the Log tab to view the logs for a tax form.

Common Tax Form Procedures

This section describes common tax form procedures based on functionality provided in the base product.

Note: The functionality described in this section is based on the business objects supplied by the base product. It is possible for your implementation to implement different business processes.

Next in This Section

- Manually Adding Tax Forms

- Correcting Suspended Tax Forms

- Re-editing Tax Forms

- Manually Posting a Valid Tax Form

- Canceling Tax Forms

- Adjusting Tax Forms

- Changing the Receive Date

- Transferring Tax Forms

- Reversing Tax Forms

- Auditing Tax Forms

Manually Adding Tax Forms

Use this procedure to manually add a tax form.

- Use the menu navigation to launch the add a tax form dialogue.

- Use the form type search to find the form type you wish to add. The maintenance map of the chosen form type is displayed.

- Enter the form data. The Save and Continue button allows for interim saves. The Save when the form is completely filled in.

Note: The base business objects do not capture versions when a form is in pending status. It captures the initial "as reported" version only when transitioning to the Validate state. Refer to About Form Versions for more information.

- Click Validate or Validate and Post to process the form. If Validate and Post is clicked and the form does not have any exceptions, the form is posted. No further processing is needed. Otherwise,

- If the user clicks Validate and the form passes validation, it transitions to the Ready for Post status. Refer to Manually Posting a Valid Tax Form for further information.

- If the form does not pass validation and transitions to the Suspended status, the user may correct the form as needed. Refer to Correcting a Suspended Tax Form for further information.

- If a validation form rule indicates that additional information is needed the form transitions to the Waiting for Information status. From here the logic depends on your business rules, but typically forms in this state trigger a letter to the taxpayer requesting for more information.

Note: A manually created form will not get processed by the batch form monitor process. The user must progress the form by clicking Validate or Validate and Post.

Correcting Suspended Tax Forms

If a tax form has suspense issues that prevent it from being posted, you must correct them and then validate the tax form.

- Navigate to the tax form portal and display the tax form you want to validate.

- If you have not already corrected the condition causing the issues, do so now. Click the Edit button in the Actions zone. Review the exceptions reported and use the down arrow adjacent to the exception message to drill to the data in error.

- Correct the error. Depending on the configuration of the form type, you may be required to enter a change reason for the individual line being corrected or an overall reason for the change or both. Save the record. (Upon successful save, you are returned to the Tax Form portal.)

- Click Validate in the Actions zone.

The system attempts to validate the tax form.

- If the system still detects issues with the tax form, the issues are displayed for your review.

- Any suspense issues that are resolved get closed.

- Any suspense issues that are still not resolved remain open.

- Any new suspense issues are added to the list.

Repeat this process to resolve the issues and then re-validate.

- If validation succeeds, its status is updated and the tax form is ready for posting.

Note: Refer to Manually Posting a Valid Tax Form for information on posting a valid form.

Re-editing Tax Forms

Use this procedure to update a tax form that has passed validation and has not yet posted and has been identified as needing correction. You can only re-edit a tax form if its current status supports it. If the action is not supported, the Re-edit button will not be displayed.

- Navigate to the Tax Form portal and display the form you want to re-edit.

- Click Re-edit in the Actions zone. The maintenance map will display. Edit the form and make desired changes. Depending on the configuration of the form type, you may be required to enter a change reason for the individual line being corrected or an overall reason for the change or both. Save the form.

- The system updates the state of the tax form to Re-edited. The form stays in this state until you try to validate / post.

Note: A form version is captured every time a Re-edited form is updated.

Manually Posting a Valid Tax Form

When a tax form uploaded in batch passes validation it transitions to Ready for Posting and then transitions automatically to the Posted state. However, any tax form that has had manual intervention prior to its transition to Ready for Posting is ignored by the batch process that attempts to transition Ready for Posting forms to Posted. This is to safeguard against a situation where a user is still working on a tax form. For example, a tax form may have passed validation, but upon review the user may identify information that needs to be corrected (and will therefore be re-edited to resolve the issue). The user does not want the tax form to get inadvertently processed by the tax form batch process.

The following are examples of tax forms in the Ready for Posting state that do not automatically transition to Posted:

- Manually created tax forms that have passed validation.

- Suspended tax forms, created either manually or via form upload that are subsequently corrected by a user.

- Waiting for Information tax forms, created either manually or via form upload that are subsequently corrected by a user.

Use this procedure when a manually added or corrected tax form is ready to be posted.

- Click Post to post the tax form immediately.

- Click Batch Post to mark the tax form to be processed the next time the batch monitor process runs.

Canceling Tax Forms

Use this procedure to cancel a tax form that has not been finalized.

You can only cancel a tax form if its current status supports it. If the action is not supported, the Cancel button will not be displayed.

- Navigate to the Tax Form portal and display the tax form you want to cancel.

- Click Cancel in the Actions zone. Enter an appropriate cancel reason.

The system validates the action and displays an error message if the action cannot be completed.

Fastpath: The product also supplies the ability to perform mass cancellation of a group of tax forms using an entity correction. Refer to Entity Correction for more information.

Adjusting Tax Forms

Use this procedure to correct line item details on a tax form that has already been posted.

You can only adjust a tax form if its current status supports it. If the action is not supported, the Adjust button will not be displayed.

- Navigate to the Tax Form portal and display the tax form you want to adjust.

- Click Adjust in the Actions zone. Enter an appropriate adjust reason.

- The system updates the state of the original tax form to Adjusted and typically reverses the financial impact of the original form, depending on your form type's processing rules for Adjusting forms.

- A new tax form is created that is a duplicate of the original tax form. At this point, you should make the appropriate line item changes, save the form and click Validate in the Actions zone to validate the tax form changes.

If validation succeeds, its status is updated and the tax form is ready for posting. If the system detects issues with the tax form, the issues are displayed for your review.

Changing the Receive Date

Use this procedure to change the receive date on a tax form. This is only possible on a Posted form for users that have security for the Form Change Receive Date access mode for the tax form's business object.

- Navigate to the Tax Form portal and display the form whose receive date needs to change.

- Click Change Receive Date in the Actions zone. A map will display to allow the user to enter a new receive date. If the form type supports overall change reasons, the map will also include prompts for the change reason and comments. Once the values are entered, click OK.

- The system updates the receive date of the tax form and updates the change reasons and comments with the entered values, if applicable.

- A log entry is stored indicating that the receive date was changed and the old and new values.

- The system calls the Update Penalty and Interest service to recalculate penalty and interest in case the change the receive date impacts calculations for penalty and interest.

Note:

No special form version is captured when the form receive date is changed.

Transferring Tax Forms

Use this procedure to correct the taxpayer or the obligation for a tax form that has already been posted.

You can only transfer a tax form if its current status supports it. If the action is not supported, the Transfer button will not be displayed.

- Navigate to the Tax Form portal and display the tax form you want to transfer.

- Click Transfer in the Actions zone. Enter an appropriate transfer reason.

- The system updates the state of the original tax form to Transferred and typically reverses the financial impact of the original form, depending on your form type's processing rules for Transferring forms.

- A new tax form is created that is a duplicate of the original tax form. At this point, you should make the appropriate changes to correct the taxpayer information and / or the filing period information to direct the tax form to the appropriate taxpayer and/or obligation. Save the form and click Validate in the Actions zone to validate the tax form changes.

If validation succeeds, its status is updated and the tax form is ready for posting. If the system detects issues with the tax form, the issues are displayed for your review.

Reversing Tax Forms

Use this procedure to cancel a tax form that has already been posted and is not valid.

You can only reverse a tax form if its current status supports it. If the action is not supported, the Reverse button will not be displayed.

- Navigate to the Tax Form portal and display the tax form you want to reverse.

- Click Reverse in the Actions zone. Enter an appropriate reversal reason.

- The system updates the state of the original tax form to Reversed and typically reverses the financial impact of the original form, depending on your form type's processing rules for Adjusting forms.

Fastpath: The product also supplies the ability to perform mass reversal of a group of tax forms using an entity correction. Refer to Entity Correction for more information.

Auditing Tax Forms

Use this procedure to create an audit tax form from a tax form that is already in the Posted state. You can only audit a tax form if its current status supports it. If the action is not supported, the Audit button will not be displayed.

- Navigate to the Tax Form portal and display the form you want to audit.

- Click Audit in the Actions zone. Select the Audit Case ID to associate with the audit form

- The system creates a new Pending form with a filing type of Audit and copies the information from the Posted form.

Note:

The Posted form remains unchanged.

- Edit the new form.

- Validate the form and make subsequent changes as needed. Audit forms that pass validation typically go to the Ready for Posting state, where a proposed assessment is calculated, depending on the form type's processing rules. The calculated audit assessment can be reviewed before posting the audit form.

- If the audit assessment needs to be corrected or changed, you can cycle through the Re-edit and Validate steps as many times until the correct audit assessment is calculated.

Maintaining Form Batch Headers

Use the Form Batch Header transaction to view and maintain form batch headers. Navigate using Menu > Forms > Form Batch Header .

Next in This Section

- Form Batch Header Query

- Form Batch Header Portal

- Adding Form Batch Headers

- Validating Form Batch Headers

- Correcting Suspended Form Batch Headers

- Canceling Batches of Forms

- Reviewing Batches Where Records Were Rejected

Form Batch Header Query

Use the query portal to search for an existing form batch header. Once a form batch header is selected, you are brought to the maintenance portal to view and maintain the selected record.

Form Batch Header Portal

This page appears when viewing the detail of a specific form batch header.

The topics in this section describe the base-package zones that appear on this portal.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Form Batch Header

The Form Batch Header zone contains display-only information about the form batch header.

Please see the zone's help text for information about this zone's fields.

Form Upload Staging List

This zone lists the form upload staging records that are included in the selected form batch header.

Form Batch Header Log

This is a standard log zone.

Included Forms

This zone displays tax forms and / or registration forms that have created and linked for this form batch header.

Adding Form Batch Headers

Although, most form batch headers are uploaded in batch, it is possible to create a record manually. To create a form batch header, navigate using Menu > Forms > + Form Batch Header , select an appropriate form batch header business object to continue. Fill in the form batch header details and click save button.

Validating Form Batch Headers

After the form batch header and its form upload staging records have been entered into the system, they must be validated. A user may request the validation of a given form batch header. Alternatively, a background process runs periodically to pick up form batch headers awaiting validation and processes them.

To request validation of a form batch header,

- Navigate to the form batch header portal and display the form batch header you want to validate.

- Click the Validate button in the Actions zone.

If a form batch header passes validation, it continues through to the Form Upload in Progress state and the related form upload staging records can get processed.

If there are any validation errors, the details are captured as issues related to the form and it transitions to Suspended.

Correcting Suspended Form Batch Headers

If a form batch header has suspense issues that prevent it from continuing, you must correct them and then validate the form batch header.

- Navigate to the form batch header portal and display the form batch header you want to validate.

- If you have not already corrected the condition causing the issues, do so now. Click the Edit button in the Actions zone. Review the issues reported.

- Correct the error. Save the record. (Upon successful save, you are returned to the form batch header portal.)

- Click the Validate button in the Actions zone.

The system attempts to validate the form batch header. If validation succeeds, its status is updated and the form upload staging records may now be processed (orchestrated by a background process). If the system still detects issues with the form batch header, the issues are displayed for your review.

Repeat this process to resolve the issues and then re-validate.

Canceling Batches of Forms

Use this procedure to cancel a form batch header that has not been finalized and all its related form upload staging records.

You can only cancel a form batch header if its current status supports it. If the action is not supported, the Cancel button will not be displayed.

- Navigate to the Form Batch Header portal and display the form batch header you want to cancel.

- Click the Cancel button in the Actions zone. Enter an appropriate cancel reason.

Because of the potentially large number of related form upload staging records that must be canceled as part of this procedure, the record is updated to Pending Cancel and the cancellation will be finalized by a background process.

Reviewing Batches Where Records Were Rejected

Use this procedure to review a form batch header that has been marked as needing review. This may occur when one or more of the related form upload staging records has been rejected.

- Navigate to the Form Batch Header portal and display the form batch header you want to cancel.

- Using the Form Upload Staging list, review the upload records that have been rejected.

- If the rejected upload records highlight a possible problem with the entire batch of records, you may choose to Cancel the batch and its upload staging records. Because of the potentially large number of related form upload staging records that must be canceled as part of this procedure, the record is updated to Pending Cancel and the cancellation will be finalized by a background process.

- If you decide that the rejected upload records are an anomaly that does not affect the rest of the batch of forms, click the Complete button to complete the batch and upload the forms. Because of the potentially large number of related form upload staging records that must be processed as part of this procedure, the record is updated to Pending Complete and the upload of the forms will be finalized by a background process.

Maintaining Form Upload Staging

Use the Form Upload Staging transaction to view and maintain form upload staging records. To maintain form upload staging records, select Menu > Forms > Form Upload Staging.

Next in This Section

- Form Upload Staging Query

- Form Upload Staging Portal

- Adding Form Upload Staging Records

- Validating Form Upload Staging Records

- Correcting Suspended Form Upload Staging Records

- Canceling Forms Upload Staging Records

Form Upload Staging Query

Use the query portal to search for an existing form upload staging record. Once a form upload staging is selected, you are brought to the maintenance portal to view and maintain the selected record.

You can click the Add link on this portal to add a form upload staging.

Form Upload Staging Portal

This page appears when viewing the detail of a specific form upload staging record.

Next in This Section

- Forms Upload Staging - Main

- Forms Upload Staging - Log

Forms Upload Staging - Main

The topics in this section describe the base-package zones that appear on this tab.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Form Upload Staging

The Form Upload Staging zone contains display-only information about the form upload staging.

Please see the zone's help text for information about this zone's fields.

Forms Upload Staging - Log

This portal contains a standard log zone.

Adding Form Upload Staging Records

The product does not provide a user friendly mechanism to add a form upload staging record manually such that the detailed data from the form can be entered. The expectation is that form upload staging records are created by a background process.

Validating Form Upload Staging Records

After the form batch header has been validated, the related form upload staging records may be validated. This typically occurs through a background process that runs periodically to pick up form upload staging records awaiting validation whose form batch headers are valid and processes them. However, a user may request the validation of a form upload staging record.

To request validation of a form upload staging record,

- Navigate to the form upload staging portal and display the form upload staging you want to validate.

- Click the Validate button in the Actions zone.

If a form upload staging passes validation, it continues through to map the received form data to the appropriate form type. If that step succeeds, the upload record transitions to Ready to Load. At this point, it cannot proceed further until all the form upload staging records for the batch are ready.

If there are any validation errors, the details are captured as issues related to the form upload staging and it transitions to Suspended.

If a problem is detected when attempting to map the data to the appropriate form business object, the form upload staging record is Rejected at which point it cannot be fixed. This should occur rarely and only when there is something corrupt with the transmission.

Correcting Suspended Form Upload Staging Records

If a form upload staging record has suspense issues that prevent it from continuing, you must correct them and then validate the form upload staging record.

- Navigate to the form upload staging portal and display the form upload staging you want to validate.

- If you have not already corrected the condition causing the issues, do so now. Click the Edit button in the Actions zone. Review the issues reported.

- The system renders the upload staging record in a simple editable form allowing the raw received data to be fixed. Correct the error. Save the record. (Upon successful save, you are returned to the form upload staging portal.)

- Click the Validate button in the Actions zone.

The system attempts to validate the form upload staging record. If validation succeeds, it continues through to map the received form data to the appropriate form type. If that step succeeds, the upload record transitions to Ready to Load. At this point, it cannot proceed further until all the form upload staging records for the batch are ready.

If a problem is detected when attempting to map the data to the appropriate form business object, the form upload staging record is Rejected at which point it cannot be fixed. This should occur rarely and only when there is something corrupt with the transmission.

If the system still detects issues with the form upload staging record it returns to Suspended and the issues are displayed for your review.

Repeat this process to resolve the issues and then re-validate.

Canceling Forms Upload Staging Records

Use this procedure to cancel a form upload staging record that has not been finalized and is not a valid record.

You can only cancel a form upload staging record if its current status supports it. If the action is not supported, the Cancel button will not be displayed.

- Navigate to the Form Upload Staging portal and display the form upload staging record you want to cancel.

- Click the Cancel button in the Actions zone. Enter an appropriate cancel reason.

Maintaining Form Controls

Use the Form Control transaction to view and maintain form controls. Navigate using Menu > Forms > Form Control. The section describes the tab pages that appear on the Form Control portal.

Next in This Section

- Form Control Query

- Form Control Portal

- Common Form Control Procedures

Form Control Query

Use the query portal to search for a form control. Once a record is selected, you are brought to the maintenance portal to view and maintain the selected record.

Form Control Portal

This page appears when viewing the detail of a specific form control.

Next in This Section

- Form Control - Main

- Form Control - Log

Form Control - Main

This portal appears when a form control has been selected from the Form Control Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Form Control

The Form Control zone contains display-only information about the selected Form Control.

Please see the zone's help text for information about this zone's fields.

Refer to the Common Form Control Procedures section for more information about common functions.

Linked Tax Forms

This zone displays a list of the tax forms that are currently linked to the form control along with the status of the link. Refer to Form Control Overview for more information about the link status. The filter allows the user to select a subset of records to display based on information such as link status and ID ranges.

Form Control - Log

Navigate to the Log tab to view the logs for a form control.

Common Form Control Procedures

This section describes common form control procedures based on functionality provided in the base product.

Reviewing and Approving a Form Control

Once a form control is validated, if it requires review to determine if it should be approved, rejected or put on hold, a To Do entry is sent to the appropriate group of users based on the To Do role configured on the form control type. When a user in that group reviews the form control, this procedure should be followed:

- Drill into the form control record from the To Do entry (or from the email, if the To Do is routed to an email).

- Review the summary counts of the linked tax forms to see if the information is as expected. If desired, use the Linked Tax Forms zone to spot check and even drill into any tax forms.

- Choose whether to Approve, Reject or put the record On Hold. Refer to Form Control Overview for more information.

Asset

An asset captures information about a type of property, e.g. real property, personal property, etc. It is the central object for billing the property.

An asset’s valuations contain specific details about the asset that are used in billing.

The following sections describe how to maintain assets and valuations.

Next in This Section

- Understanding Assets

- Maintaining Assets

- Maintaining Valuations

Understanding Assets

The topics in this section provide background information on assets and valuation.

Next in This Section

- About Assets

- About Valuation

- About Valuation Upload

About Assets

Asset is the central object for information that’s used in billing taxes for assets/property.

Each asset references an asset type, which controls the aspects of how the asset is processed. These include the following:

- The lifecycle of the asset

- The valid external identifier types for the asset.

- The associated tax type(s).

Refer to The Big Picture of Assets for a description of business rules that you control when you set up your asset types.

About Valuation

Valuation is an appraisal or estimation of an asset’s value as of a given period of time.

Each valuation refers to a valuation type that defines the information that a specific type of valuation contains.

Refer to The Big Picture of Valuation for a description of business rules that you control when you set up your valuation types.

About Valuation Upload

Valuation information maintained at external systems can be uploaded into the system. The base product provides a Valuation business object that can be used for uploading valuations.

Refer to Uploading Valuations for more details.

Maintaining Assets

Use the Asset transaction to view and maintain assets. Navigate using Menu > Asset > Asset.

Next in This Section

- Asset Query

- Asset Portal

Asset Query

Use the query portal to search for an existing asset. Once an asset is selected, you are brought to the maintenance portal to view and maintain the selected record.

Asset Portal

This page appears when viewing the detail of a specific asset.

The topics in this section describe the base-package zones that appear on this portal

Next in This Section

- Asset - Main

- Asset - Ownership

- Asset - History

- Asset - Log

Asset - Main

This portal appears when an asset has been selected from the Asset Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Asset Zone

The Asset zone contains display-only information about the selected asset.

Please see the zone's help text for information about this zone's fields.

Map Zone

This zone displays a map of the addresses associated with the asset.

Asset - Ownership

Navigate to the Ownership tab to view the asset’s ownership information.

The topics in this section describe the base-package zones that appear on this portal.

Ownership History

This zone displays the asset’s ownership history. The list is sorted in descending order of Ownership Start Date.

To limit the list to a specific ownership date range, specify the Start Date and End Date.

By default, active ownership records are displayed. To include canceled ownership records, click on Include Canceled accordingly.

Asset - History

Navigate to the History tab to view the asset’s valuation and billing history.

The topics in this section describe the base-package zones that appear on this portal.

Asset’s Valuations

This zones lists the asset’s valuations that are currently in effect. The list is sorted in descending order of Valuation Date.

To limit the list to a specific Valuation Date range, open the filters and specify the Start Date and End Date.

Billing History

This zone lists the asset’s existing bills. This list is sorted in descending order of Bill Start Date.

To limit the list to a specific Bill Start/End Date range, open the filters and specify the Start Date and End Date.

Asset - Log

Navigate to the Log tab to view the logs for an asset.

Maintaining Valuations

Use the Valuation transaction to view and maintain valuations. Navigate by selecting a valuation record in any of the following options:

- When viewing an asset on the Asset Portal, go to the Asset — History tab to view the Asset’s Valuations.

- Anywhere asset information is displayed, use the Asset context menu to Go to Valuation. This navigates to the Asset’s Valuations portal.

- When viewing valuations in error on the Valuation Errors Query portal.

Next in This Section

- Valuation Portal

- Valuation Errors Query

Valuation Portal

This page appears when viewing the detail of a specific valuation.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Valuation - Main

- Valuation - Log

Valuation - Main

This portal appears when selecting a record from a list of valuations.

The topics in this section describe the base-package zones that appear on this portal.

Valuation

The Valuation zone contains display-only information about the selected valuation.

Please see the zone's help text for information about this zone's fields.

Valuation - Log

Navigate to the Log tab to view the logs for a valuation.

Valuation Errors Query

This page shows valuations that are in the Error state. Use Menu > Asset > Valuation Errors to open this page.

Selecting a record in the list navigates to the Valuation Portal.

Fastpath:

For information about valuation upload and error processing, refer to Uploading Valuations.

Penalty and Interest

Penalty and Interest or "P&I" is a generic term used to describe a wide range of penalty, interest, and fee liabilities that are calculated and imposed by a tax authority.

Next in This Section

- Background Topics

- Detailed P&I View

- Maintaining Waivers

Background Topics

The topics in this section provide background information about penalty and interest functionality.

Next in This Section

- Dynamic Credit Allocation

- Bringing Penalty and Interest Up to Date

- Forecasting Penalty and Interest

- Waiving Penalty and Interest

Dynamic Credit Allocation

Credit allocation is the process of taking credits within an obligation and applying business rules to allocate them against tax, penalty, interest, and fees (in other words, allocated by debt category).

We use the term 'dynamic credit allocation' to indicate that credit allocation should be re-evaluated any time penalty and interest is calculated, whether for updates or forecasting.

The base product provides zones on the 360 Degree View - Financial Information portal and on Control Central on both the Account Information portal and the Taxpayer Information portal that show the balances by debt category at various levels (person, account, tax role, obligation, assessment). Refer to the details of the zone for more information.

Note:

Configuration required. Dynamic credit allocation must be configured for an obligation. Refer to The Big Picture of Credit Allocation for more information.

Bringing Penalty and Interest Up to Date

Depending on how your system is configured, several business processes may force the recalculation of penalty and interest real-time. Some examples of events in the system that may have been configured to bring P&I up to date are as follows:

- When a tax form posts or is reversed, transferred or adjusted. Basically any state transition of a form that causes adjustments to be created should include a step to bring P&I up to date.

- When a payment is frozen or canceled

- When the effective date of a frozen payment is changed

- When certain adjustments, such as manual penalties, are frozen or canceled

- An obligation's override due date changes.

- When a waiver is activated or canceled

- An event in an overdue process

In addition to real-time requests to bring P&I up to date, the system provides a background process that may periodically recalculate penalty and interest for all obligations governed by P&I.

A user may also request that P&I is brought up to date using the Credit Allocation zones on the 360 Degree View - Financial Information portal and on Control Central on both the Account Information portal and the Taxpayer Information portal.

Note:

Calculation through date. Every time the system recalculates P&I for an obligation its calculation through date is updated. This allows a user to know the accuracy of the balance viewing the details provided by dynamic credit allocation.

Forecasting Penalty and Interest

The system supports forecasting penalty and interest. This request executes the Calculate P&I logic in memory. A user may ask the system to forecast P&I to the current date or to a future date using the Credit Allocation zones on the 360 Degree View - Financial Information portal and on Control Central on both the Account Information portal and the Taxpayer Information portal.

Waiving Penalty and Interest

The tax office generally has broad discretionary power to waive penalty, interest and fees. Waivers may be for part of the amount imposed or the full amount or may be tied to a specific period.

Note:

Refer to Waivers for more information about configuring waivers.

Next in This Section

- Waiver Type

- Creating and Activating a Waiver

- Canceling a Waiver

- Waiver Log Information

Waiver Type

Each waiver has an associated waiver type. The waiver type defines the configuration information that is common to waivers of a given type.

The base product provides support the following types of waivers:

- One-time waivers. Waivers of this type are used to waive charges for a given assessment / debt category up to a specific amount.

- Effective dated waivers. Waivers of this type are used to waive charges for a given assessment / debt category that occur on or after a given start date. Waiver of this type may optionally specify an end date to waive charges for a specific period.

- Ongoing waivers. Waivers of this type are used to waive all charges for a given assessment / debt category.

Creating and Activating a Waiver

A waiver is typically added in pending status allowing a user to configure the attributes of the waiver such as the assessment and the amount, if applicable or the effective dates, if applicable. The waiver has no financial effect at this time.

When the user is happy with the waiver's setup and activates it, the obligation's penalty and interest is recalculated.

For any penalty and interest charge that is waived, an adjustment is created for the waived amount (to credit the charge being waived). This information is visible on the waiver portal.

Note:

Controlled by configuration. The actual behavior of the waiver and its lifecycle are controlled by the configuration of the waiver. The above information describes the logic provided for waivers in the base product. Your implementation may introduce a different business process.

Canceling a Waiver

If a waiver was created in error or created incorrectly, it may be canceled. At this point the obligation's penalty and interest is recalculated to cancel the waiver financial transactions.

Note:

Controlled by configuration. The actual behavior of the waiver and its lifecycle are controlled by the configuration of the waiver. The above information describes the logic provided for waivers in the base product. Your implementation may introduce a different business process.

Waiver Log Information

A waiver log contains an entry for every recorded event during the lifecycle of a waiver. There are two general types of log entries:

- Automatic entries. The system automatically creates an entry in the log when a waiver is created or there is a status change or when a related entity is created. This also includes any implementation-specific log entries. Users cannot modify or delete these log entries.

- Manual entries. Users can add manual entries to record significant events at their discretion.

Detailed P&I View

This page allows a user to select an obligation and view the details of the penalty and interest calculation as of a certain date. For example, if a taxpayer were to call the tax authority to inquire about how a certain penalty or interest amount was calculated, this page could be used to view the calculation basis, the rate used, the number of days, etc.

Note:

The base package does not store the details of the calculation with the penalty and interest adjustments. Rather the details are only provided when the Calculate P&I service is called in forecast mode. The page can be used to "forecast" to any date, past, present or future in order to view the calculation details

Note:

The ability to view details of the calculation relies on the implementation of the P&I rule algorithms to provide the details. Refer to P&I Calculation Details for more information.

Open this page using Menu > Accounting > Detailed P&I View

The topics in this section describe the base-package zones that appear on this tab.

Detailed P&I Zone

Select the Account and Obligation for which you would like to review P&I calculation details.

Enter the Calculation Date that is passed to the Calculate P&I service.

Click Calculate to cause the P&I to be forecasted to the calculation date for the chosen obligation.

Balance Details Grid

Initially a grid showing the obligation's balance details for the forecasted date is displayed, with a row for each unique debt category for the charges associated with the obligation.. The grid includes a checkbox adjacent to any debt category whose debt type is Penalty or Interest. All boxes are checked by default, but a user may unselect certain row to customize the amount of detail shown.

Click Refresh P&I Details to redisplay the P&I Details after changing the selections.

P&I Details

This section displays a tree view of the details of the Penalty and Interest calculations.

Refer to the zone specific help text for more information about the data displayed.

Maintaining Waivers

Use the Waiver transaction to view and maintain pending or historic waivers. Navigate using Menu > Accounting > Waiver.

Next in This Section

- Waiver Query

- Waiver Portal

Waiver Query

Use the query portal to search for a waiver. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.

Waiver Portal

This portal appears when a waiver has been selected from the Waiver Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Waiver

The Waiver zone contains display-only information about the selected waiver.

Please see the zone's help text for information about this zone's fields.

Existing Charges

This info zone displays all existing adjustments that have the same Assessment Id and Debt Category as the waiver being displayed.

Existing Waivers

This info zone displays all existing waiver adjustments created for this waiver.

Waiver Log

This is a standard log zone.

Billing

In this section, we describe how to manage bills.

Next in This Section

- Maintaining Bills

- Common Bill Procedures

Maintaining Bills

A bill is used to calculate the details of a financial obligation and communicate those details to the recipient. The topics in this section describe how to maintain bills.

It's important to be aware that there is little about a bill that is directly modifiable by a user. If you want to change a bill's amount, you must cancel or discard the bill and generate a new bill after amending the source information; you cannot change the bill's amount by modifying the billing details.

Next in This Section

- Bill Query

- Billing Portal

- Bill - Log

Bill Query

Use the query portal to search for an bill. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.

Billing Portal

This portal appears when a bill has been selected from the Bill Search results.

The topics in this section describe the base-package zones that appear on this portal.

Bill

The Bill zone contains display-only information about a Bill. This zone appears when a bill has been selected from the Bill Search results, 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 C1_TAX_BILL.

Value Details

The Value Details List zone provides a view of all the value details linked to a bill. The value details are shown in the order in which they were added to the bill during generation. The list includes a description of the value detail type, the value, value class and precision and information about the associated valuation if applicable.

Calculation Lines

The Calculation Lines List zone provides a view of all the calculation lines linked to a bill. The calculation lines are shown in the order in which they were added to the bill during generation. The list includes information for the calculation rule that created the line and a hyperlink to the rule's maintenance portal. Please see the zone’s help text for information about the fields in this zone’s list.

Bill - Log

Navigate to the Log tab to view the logs for a bill. Bill logs may include an audit trail of bill generation errors.

Common Bill Procedures

This section describes common bill procedures based on functionality provided in the base product.

Note: The functionality described in this section is based on the business objects supplied by the base product. It is possible for your implementation to implement different business processes.

Next in This Section

- Manually Adding A Bill

- Canceling Bills

- Overriding Due Dates

- Maintaining Batch Control Group Values

Manually Adding A Bill

Use this procedure to manually add a bill.

- Use the menu navigation to launch the add a bill dialogue.

- Use the tax role search to find the tax role for which to add the bill. When a tax role is selected, a list of valid bill types is displayed.

- Select a bill type.

- Use the revenue period search to find the revenue period for the bill.

- Enter OK to continue. The maintenance map of the chosen bill type is displayed.

- Enter any additional bill data. (the available fields will be limited). Enter Save when the bill information is filled in.

Click Generate to generate the bill.

- If the user clicks Generate and the bill generates correctly, it transitions to the Ready for Completion status. At this point the user may choose to click Complete to complete the bill or Batch Completion to allow the bill to be completed next time the monitor runs

- If the bill does not generate and transitions to the Error status, the user needs to diagnose the problem and correct the underlying cause. Note that bill details are not directly updated. Once the problem has been corrected, the bill must be manually transitioned back through the Generate state to delete and recreate the bill details.

- A manual bill can be Discarded any time prior to completion.

Note: A manually created bill will not get processed by the bill monitor process unless explicitly requested. The user must progress the form by clicking Complete or Batch Completion.

Canceling Bills

The base product expects only one bill of a given type for an obligation’s revenue period. If the effect of a bill needs to be reversed, or a corrected bill needs to be issued, the existing bill for the period must be manually canceled and a new bill added.

You can only cancel a bill if its current status supports it. If the action is not supported, the Cancel button will not be displayed.

Transitioning a bill to the Canceled state causes the cancellation algorithms for the bill type to be executed.

Overriding Due Dates

Use this procedure to change the due dates of any of the bill’s segments. This is only possible on a Completed bill for users that have security for the Override Due Dates access mode for the bill's business object.

- Navigate to the Bill portal and display the bill whose due dates need to change.

- Click Override Due Dates in the Actions zone. A map will display to allow the user to enter a new due date for each bill segment. Once the values are entered, click OK.

Maintaining Batch Control Group Values

Batch Control Groups provide a mechanism for controlling which bills are processed when the bill monitor is run. Use this procedure to change the value of the batch control group field on a bill. This is only possible on a bill that is not yet Completed for users that have security for the Maintain Batch Control access mode for the bill's business object.

- Navigate to the Bill portal and display the bill whose batch control needs to change.

- Click Maintain Batch Control in the Actions zone. A map will display to allow the user to enter a new batch control group. Once the value is entered, click OK.

Payments

In this section, we describe how to manage your taxpayer's payments.

Next in This Section

- The Big Picture of Payments

- Maintaining Payment Events

- Payment Event Quick Add

- Payment Quick Add

- Maintaining Payments

- How To

- Financial Transactions On A Payment

- Payment History

- Payment / Tender Search

- Payment Event Exception

- Payment Exception

- Maintaining Deposit Controls

- Maintaining Tender Controls

- Interfacing Payments From External Sources

The Big Picture of Payments

A payment reduces how much an account owes. The topics in this section provide background information about a variety of payment topics.

Next in This Section

- A Payment Event Has Payments And Tenders

- Multiple Tenders Used To Pay For Multiple Accounts

- An Overview Of The Payment Event Creation & Allocation Process

- Payments and Penalty and Interest

- Payment Date and Effective Date for Payment Events

- Distributing A Payment Event

- Distributing A Payment Amongst An Account's Obligations

- Overpayment

- Canceling A Tender Versus Canceling A Payment

- NSF Cancellations

- Transferring A Payment

- Unbalanced Payment Events

- Tender Management and Workstation Cashiering

- Exceptions

- Payment Financial Transaction Considerations

- A Payment May Affect More Than Just Taxpayer Balances

- Automatic Payments

- Issuing A Payment Advice Instead Of Creating An Automatic Payment

A Payment Event Has Payments And Tenders

The following diagram illustrates the relationship between a payment event, its payment(s) and its tender(s).

The following concepts are illustrated above:

A payment event defines the event

A payment event is required whenever any form of payment is received. The payment event defines the payment date and effective date (and that's all).

A payment event has tender(s)

A tender exists for every form of tender remitted as part of the payment event. A payment event must have at least one tender otherwise nothing was remitted. A payment event may have many tenders when multiple payment methods are associated with an event (e.g., paying with cash, a check, and a credit card).

A payment is allocated to account(s)

The total amount of tenders under a payment event is distributed to one or more accounts.

A payment is distributed to obligations

The system allocates an account's payment amount amongst its obligations. The system creates a payment segment for each obligation that receives a portion of the payment.

Payor and payee are frequently the same

The account remitting the tender (the payor) is frequently the same as the account to which the funds are allocated (the payee). The next illustration provides an example when this is not the case.

Multiple Tenders Used To Pay For Multiple Accounts

The following diagram illustrates a payment event with multiple tenders where the payor of the tender is not the same as the account(s) receiving the payment.

A payment event may have many tenders

A single payment event may have many tenders. While the above example shows both tenders being paid by the same account, each tender may reference a different account.

Many accounts may be paid under 1 event

The total amount of tenders under a payment event are distributed to one or more accounts.

Payor may differ from payee

The account(s) remitting the tender may differ from the account(s) whose debt is relieved.

An Overview Of The Payment Event Creation & Allocation Process

When a payment event occurs, the system stores a tender for each form of remittance (e.g., cash, check, charge). It then allocates the sum of the tenders to one or more accounts.

Typically the amount represented by the sum of the tenders are distributed to the account that remits the tenders. You may override this default and specify any number of accounts and their respective payment allocation amount. This is useful, for example, when a social service agency pays for many accounts. If applicable, you may also configure the system to use your own payment event distribution rule(s).

Fastpath: Refer to Distributing A Payment Event for more information.

The system distributes a payment amongst an account's obligations based on the age of each obligation's debt AND distribution priority. The system creates a payment segment for each obligation that receives part of the payment.

Fastpath: Refer to Distributing A Payment Amongst An Account's Obligations for more information.

You may manually redistribute the payment amount amongst the account's obligations before you commit the distribution. When the distribution is acceptable, you freeze the payment. Freezing a payment causes the system to create a financial transaction for each related payment segment. It is the financial transaction(s) that causes the obligations' payoff and current balances to be reduced. The financial transaction also contains the journal details that debit "cash" and credit some other GL account.

And that's it. The remaining topics in this section provide more information about the creation and allocation of payment events.

Note: Batch and real-time payment event creation / allocation. There is only one payment event creation / allocation routine and therefore anything the batch payment process does for whole batches of payments, you can do to a payment on-line.

Payments and Penalty and Interest

If your organizations levy penalty and interest (P&I) charges for unpaid tax assessments, creating or canceling payments should recalculate penalty and interest.

The recalculation occurs when a payment is frozen or canceled assuming that the correct algorithm has been plugged in to the account's account type.

Payment Date and Effective Date for Payment Events

This section discusses the payment and effective dates used in payment events.

By default, the payment and effective dates are equal but the algorithm used to create the payment may calculate the dates differently based on business rules.

A payment event records a payment date and an effective date. The payment date should be the date that the payment was considered "received". This could be the system date or it could be a postmark date. The effective date is used to populate the effective date of the payment segment's financial transactions and is the date that the payment should affect penalty and interest.

The following examples illustrate when the effective date may differ from the payment date:

- Consider the following collections scenario. A collections notice is sent to a taxpayer with penalty and interest forecasted to a future date (for example, the 30th). If the payment is received (postmarked) on the 20th, this date is used as the payment date. However, your organization's business rules may dictate that for P&I purposes, the payment should be considered effective on the 30th (the date noted in the collection notice). In this case the distribution algorithm that directs this payment to a collection notice should set the payment effective date to the 30th. This ensures that penalty and interest will be calculated according to what was forecast.

- Consider an obligation whose filing period due date is April 15th, where the payment grace days on the obligation type is 3. If the taxpayer files and pays on April 17th, the payment distribution algorithm determines that this is within the grace days and sets the effective date to the 15th. In this case the payment date would still be the 17th.

Note: Changing effective date. A BPA script Change Payment Effective Date is provided as an option on the payment event context menu. The script prompts you for a new effective date. It updates the payment event and its related FT and then causes penalty and interest to be recalculated.

The base package also provides an obligation type payment freeze algorithm C1-PAYADJEFD that adjusts a payment FT’s effective date if required. This algorithm checks whether the payment was received within the payment grace period for the related obligation and, if so, resets the FT's effective date to match the obligation filing due date. The algorithm provides a centralized place to implement the effective date rule rather than having to check dates whenever a payment is created or transferred. It also caters for situations where a payment event is distributed to more than one obligation.

Distributing A Payment Event

Payment Event distribution relies on one or more distribution rule values to be provided with the payment that may be used to direct the payment to one or more obligations. For example, a payment event may include one of the following references:

- An external reference to an obligation.

- A reference to a form’s document locator number.

- A reference to a collection notice.

For each reference that a taxpayer may supply with a payment, there is an appropriate Distribution Rule that contains the appropriate algorithms that understand how to create the payments and payment segments for a payment event. Depending on the type of distribution rule values that an implementation supports, a single payment event may result in multiple payments and / or payments with multiple payment segments.

Fastpath: Refer to Making Payments Using Distribution Rules for information on how to configure your system to use this distribution method.

Distributing A Payment Amongst An Account's Obligations

The system supports the option to not use distribution rules when creating payments but to rather direct a payment to an account and use a predefined algorithm to distribute the debt amongst an account’s obligations.

Note: Manual overrides. Most of the time, you'll let the payment distribution algorithm distribute the payment amongst an account's obligations. However, you may manually distribute a payment when a taxpayer directs a payment to specific obligation(s).

Overpayment

Overpayment refers to the situation where money is left over after a payment has been distributed to all eligible obligations, and all debt is relieved. Refer to Overpayment (Excess Credit) Obligations for a description on how to configure the system to handle your overpayment requirements.

Canceling A Tender Versus Canceling A Payment

A payment event has tender(s) and payment(s). You can cancel a tender when it's not valid, e.g., when a check bounces. You can cancel a payment when the account should not have received the payment (e.g., a mis-distribution or a canceled tender).

When you cancel a tender, the system automatically cancels ALL frozen payments. We do this because if the tender is canceled, there are no funds to distribute to accounts (unless there are other non-canceled tenders under the event). However, when you cancel a payment, the system does NOT cancel the tender(s) because we assume that, if the tenders were incorrect, you would have canceled them rather than the payment.

NSF Cancellations

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 NSF charge algorithm specified on the tender's account's account type. Algorithms of this type will typically create an adjustment to levy the NSF charge.

Besides calling this algorithm, an NSF cancellation may affect the tendering account's compliance rating. The cancellation reason indicates the extent to which the account's ratings are affected.

Transferring A Payment

If the account on an event's tender and payment are wrong, you can use the Transfer button on the Payment Event page to transfer the payment to another account.

If the account on the payment is wrong - but the tender is correct, you can use the Transfer button on the Payment page to transfer the payment only to another account.

Unbalanced Payment Events

The system checks that the sum of a payment event's tenders equal the sum of the payment allocations. If the sums to not match, the payment event is unbalanced and must be corrected.

There are several ways this can happen:

- While the system defaults the payment amount to be the tender amount, you can override the payment amount and therefore make a previously balanced event unbalanced.

- While the system defaults the payment account to be the tender account, you can add additional accounts / amounts and therefore make a previously balanced event unbalanced.

- When you cancel a tender (e.g., because a check bounces), the system cancels all payments linked to the tender's payment event. If the payment event has multiple tenders, this will cause the event to become unbalanced. To correct this situation, you must add payment allocations to equal the amount of non-canceled tenders.

- If you cancel a payment and forget to add another payment for the same amount, the event becomes unbalanced. To correct this situation, you must add another payment (or cancel the tender).

- You may delete a tender from an event while its tender control is open. If you delete a tender and don't do anything about the related payments, the event becomes unbalanced.

- You may add a tender to an event at any time. If you don't allocate the tender amount to an account, the event becomes unbalanced.

Fastpath: Refer to Payment Event Exceptions for more information about how the system reminds you about unbalanced payment events.

Tender Management and Workstation Cashiering

When you add a tender, you must identify its Tender Source. For example,

- A specific cash drawer ID is the source of tenders remitted to a cashier.

- The notional lockbox ID is the source of tenders interfaced from a lockbox.

- The remittance processor is the source of tenders interfaced from a remittance processor.

Fastpath: For more information, refer to Setting Up Tender Sources.

A tender source's tenders must be balanced against an expected total before they can be deposited at a bank. This periodic balancing requires all tenders to exist in respect of a Tender Control. Over time, a tender source may have many tender controls (one per balancing event).

An example of a cashier's cash drawer will help clarify the tender control concept:

- When a cashier starts in the morning, s/he starts with a fresh cash drawer (i.e., one without tenders). Whenever a drawer starts afresh, a new Tender Control must be created because you balance the contents of a drawer.

- A cash drawer typically contains funds to make change. These funds are the tender control's Opening Balance.

Note: Default note. A tender control's starting balance defaults from its tender source.

- During the day, taxpayers remit tenders to the cashier. Every tender put into the drawer is associated with the drawer's tender control created at the start of the day.

- A tender control's balance increases during the day as tenders are recorded. A cashier can view the balance at any time.

- The cashier can turn in funds to the head cashier during the day. Each turn in event can be recorded in the system. Note well, if the amount of funds in a tender control exceeds the maximum balance defined on the tender control's tender source, a warning is issued to the cashier to remind him/her to turn in funds.

- At some point, the contents of the drawer must be balanced against the total tenders linked to the tender control. When balancing starts, no additional tenders may be put into the tender control. If the cashier receives additional tenders after balancing starts, a new tender control must be created (and the above process starts afresh).

- During the balancing process, some modifications may be made to the tenders associated with the tender control, but no additional tenders may be added. When the tender control is balanced, neither it nor its tenders may be modified.

Fastpath: For more information, refer to Managing Your Cash Drawers.

While the above explanation is true, it isn't complete. In addition to the requirement that a tender must reference a tender control, the tender control must refer to a Deposit Control. Deposit controls give you administrative control over all of the tender controls whose contents will be deposited en masse. The following concepts will help explain the power of deposit controls:

- As explained above, when a cash drawer is started afresh, a new tender control must be created. The tender control "holds" all new tenders received by the cashier.

- Similarly, when a tender control is created, it must reference a deposit control. During the day, a deposit control's tender controls are constantly changing. You can view the total impact of a deposit control's tender controls at any time.

- At some point, you will want to deposit the tenders received during the day. To do this, you must indicate how much will be deposited at the bank. This deposit amount must equal the sum of the tender controls linked to the cash drawer. When this deposit balancing starts, no additional tender controls may be associated with the deposit control.

- When the deposit total equals the sum of the tender controls, the deposit control becomes balanced and no changes may be made to it, its tender controls, or its tender controls' tenders.

Fastpath: For more information, refer to Managing Your Cash Drawers.

Note: Background processes use the same concepts. Tenders that are interfaced from external sources (e.g., lockboxes and remittance processors) make use of the concepts describe above. For example, tenders interfaced from a remittance processor are linked to a tender control and this tender control is linked to a deposit control. The main difference is that the background processes require no human intervention; the system automatically creates tender and deposit controls and sets their states to balanced when the interface concludes successfully.

Note: The ACH activation process also creates tender and deposit controls. Refer to Activating Automatic Payments for more information.

The topics in this section elaborate on the tender management concepts described above.

Next in This Section

- Managing Your Cash Drawers

- Turn Ins

- Balancing By Tender Type

- Cash Back

- Managing Payments Interfaced From External Sources

Managing Your Cash Drawers

CAUTION:

This section assumes you are familiar with the concepts described in The Lifecycle Of A Deposit Control and The Lifecycle Of A Tender Control.

There are many ways to handle the daily management of tenders received via cash drawers. It really depends on how your organization works. To help you understand the potential of the system, we'll continue the example started above.

Assume that the cash drawers in your western office are balanced and deposited independently from those in your eastern office. We'll assume that both offices follow the same daily routine:

- Load fresh drawers first thing in the morning. Each drawer contains a starting balance of $150.00. Note: the drawer's tender control's starting balance defaults from its tender source.

- At 10 am, the cashier turns in funds to the chief cashier and continues to receive additional tenders.

- At 12 noon, each drawer is pulled and balanced by a supervisor.

- By 12:30 pm, the tender controls are balanced.

- At 4 pm, the cashiering stations are closed. Each drawer is pulled and balanced by a supervisor.

- By 4:30 pm, the tender controls are balanced.

- At 5 pm, the deposit control is balanced and funds are ready to be deposited at the bank.

Given this, the following diagram illustrates the deposit controls and tender controls used by each office on a given day.

The following concepts are illustrated above:

- An Open deposit control must exist before you can create a tender control. And an Open tender control must exist before you can create a tender. From a business process standpoint, this means:

- A supervisor would create a deposit control at the start of the day (8 am in the above illustration).

- Each cashier would create a tender control when they start a drawer and reference the deposit control created by the supervisor.

- During the day, the cashier can turn-in moneys to the chief cashier. These turn-in events are recorded in the system as they play a part in the ultimate balancing of the drawer. Refer to Turn Ins for more information.

- At some point, the contents of a drawer can be pulled and balanced. If additional tenders can be received in a drawer, a new tender control must be created for the drawer. Refer to Balancing By Tender Type for more information.

- At the end of the day, the supervisor checks to make certain that all tender controls linked to the deposit control are Balanced. After this has been done, the supervisor indicates the deposit amount on the deposit control and changes it to Balanced. Notice that in the above illustration each deposit control references four tender controls.

- Typically, a cash drawer has one tender control Open at any point in time (meaning that the tenders being received are being linked to a specific tender control). However, this is not a hard rule. If you want, you may have multiple tender controls Open at any point for a specific cash drawer (for example, if multiple cashiers can work the same drawer during the day but take their drawer with them).

- Typically, a specific cashier puts tenders into a specific tender control. However, this is not a hard rule. On a tender control, you can define if it's limited to a specific operator OR if any operator can link tenders to it.

- When you're ready to balance a drawer, you change the tender control to Balancing in Progress. This prevents new tenders from being added to the tender control. If the cashier can continue to receive tenders, s/he must create another tender control. In the above example, all drawers are balanced at 12 noon by a supervisor while the cashier continues to take payments.

- When the tender control is balanced, you change its state to Balanced. This prevents any changes to the tender control or its tenders.

- All tender controls exist in respect of a deposit control (in fact, the deposit control must be created before the tender control). This way, a supervisor can check the state of the related drawers throughout the day. Notice that the state transition of a deposit control is identical to that of the tender control (refer to The Lifecycle Of A Deposit Control and The Lifecycle Of A Tender Control). There is only a temporal difference. Notice that the deposit control stays open throughout the day while any number of tender controls are being opened and balanced.

Note:

Multiple deposits in a day. While the above example illustrates a single deposit per office per day, it is quite possible to have multiple deposit controls on any given day.

Note:

Turns ins. The above example did not illustrate the fact that a cashier can turn-in moneys during the day without having to balance the drawer. Refer to Turn Ins for more information.

Turn Ins

A cashier may optionally turn-in funds received into a cash drawer to a head cashier. The turn-in process requires two steps:

- Each time a cashier turns-in funds, they add a turn-in event on the Tender Control - Turn Ins page. Note that a separate turn-in event is required for each type of tender that's turned in. This is because the balancing of a tender control is performed for each tender type and therefore the system must know how much of each tender type has been removed from the drawer.

Note:

Turn in warning. If the amount of cash-like funds in a tender control exceeds the maximum balance defined on the tender control's tender source, a warning is issued to the cashier to remind him/her to turn in funds.

- The head cashier (the person responsible for the deposit control associated with the various tender controls) approves the turn in using the Deposit Control - Turn Ins page.

Note:

All turn-ins must be approved for balancing to complete. A tender control cannot be balanced until the head cashier has approved all turn-in events.

Balancing By Tender Type

It should be noted that when it's time to balance a tender control, the cashier must enter the amount of each tender type that is in the drawer in order to balance it. For example, assume the following takes place:

- A drawer is opened with a starting balance of $150.50 (tender type is Cash).

- During the day, the cashier receives $5,000 in Cash, and $1,000 in Checks.

- During the day, the cashier turns in $750 or the Checks and $4,000 of Cash.

At the end of the day, the following operator would have to enter the balances shown in the Ending Balance column.

Tender Type

Starting Balance

Tenders Received

Turn Ins

Ending Balance

Cash

$150.50

$5,000

$4,000

$1150.50

Check

-

$1,000

$750

$250

Note:

Time saver. The system assists in the balancing effort by amalgamating the amount of tenders by tender type when the tender control's status is changed from Open to Balancing In Progress. The cashier just needs to enter the Ending Balance. The system can then compare the cashier's Ending Balance against the Expected Ending Balance. When these values are equal for all tender types, the tender control's status can become Balanced.

Cash Back

When a payment is added, the user defines the following:

- The amount of debt to be relieved (i.e., the payment amount)

- The amount remitted (i.e., the tender amount)

- The form of the remittance (i.e., the tender type)

The payment amount typically equals the tender amount unless cash will be returned to the taxpayer. For example, if a taxpayer remits $100, but only wants to pay off $25 of debt, the tender amount will be $100 and the payment amount will be $25. The system will only allow a user to remit more than the payment amount if the tender type indicates "cash back" is allowed. For example, you may not allow cash to be returned if a check is remitted, but you may allow it to be returned if cash is remitted.

If cash back is allowed for the tender type, the system displays the amount of cash to be returned on the Payment Event. In addition, because the system enforces balancing the cash drawer by tender type, the system adjusts the payment event's tendered information as follows:

- When there is cash back, the payment event will have two tenders - one will be for the amount and type entered by the user, the other will be a negative amount with a tender type of cash (note, this tender type is retrieved from the Starting Balance Tender Type on the installation record). For example, if a taxpayer remits $100 in traveler's checks, but only wants to pay off $25 of debt, there will be two tenders: one for the $100 travelers check and the other for the -$25 of cash.

Note:

Multiple tenders and payment cancellation. If multiple tenders were created because of "cash back" processing, both tenders must be cancelled if the payment event needs to be cancelled.

When modifying an unfrozen payment on the Payment Event, if the payment becomes unbalanced, a button is displayed allowing the user to Recalculate Cash Back. If the user clicks this button, the system reassesses the cash back tender as follows:

- If there is now cash back, a new tender is created for the credit amount

- If the cash back amount has changed, the tender for the cash back is adjusted to the new amount

- If there is no longer cash back due, the tender for the cash back is removed.

Managing Payments Interfaced From External Sources

Just like a payment recorded on-line via a cash drawer, a payment interfaced from an external source (e.g., lock box or remittance processor) must reference a tender control and the tender controls, in turn, must reference a deposit control. The only real differences between these two types of payments are highlighted below:

- Whilst an operator must create and balance the tender and deposit controls for real-time payments, the system creates the tender and deposit controls associated with interfaced payments.

- It's impossible for an invalid account to be referenced on a payment recorded real-time. However, it is quite possible for an interfaced payment to reference an unknown account. If an invalid account is referenced on an interfaced payment (using no distribution rules), the system links it to the suspense obligation referenced on the tender source control table.

Fastpath:

Refer to Interfacing Payments From External Sources for more information.

Exceptions

The topics in this section describe exceptions that are detected when the system allocates a payment.

Next in This Section

- Payment Exceptions

- Payment Event Exceptions

- Resolving Exceptions Automatically

Payment Exceptions

When the system attempts to distribute a payment, there are a small number of situations where it can't do its job. Some examples of classic errors:

- No obligation to hold a credit. For example, if an account overpays their debt and the account doesn't have a single obligation that is allowed to hold a credit, a payment error is generated.

The system saves payments that are in error just as it saves payments that are error-free. This is done because payments are nothing more than a snapshot of the data that was used to distribute the payment. By saving the snapshot, you can see the information the system used when it detected the error and therefore more effectively correct it.

Every payment in error is written to the Payment Exception table. A To Do background process creates To Do entries for records in this table.

Payment Event Exceptions

It is possible for a payment event's tenders to not equal its payments. Such events are classified as unbalanced. Refer to Unbalanced Payment Events for how this can happen.

For each unbalanced payment event, a record is written to the Payment Event Exception table. A To Do background process creates To Do entries for records in this table.

Resolving Exceptions Automatically

Some payment errors occur because master data was not fully set up prior to receiving a payment for the account. For these cases, the system will periodically check to see whether the master data problem has been resolved by attempting to distribute and freeze the payment in error.

A background process, Resolve Payments in Error - PY-RPE, exists for this purpose. This background process works as follows:

- It looks for payments in error where the error was caused by the lack of active obligations linked to the payment's account.

- For each such payment, it attempts to re-distribute the payment. If obligations have been created in the meantime, this payment will distribute and freeze successfully.

Payment Financial Transaction Considerations

A payment segment exists for each obligation that receives a portion of a payment. Linked to every frozen payment segment is a financial transaction. This financial transaction affects an obligation's payoff balance and/or current balance. It also contains the journal details that debt cash and credit some other account.

The topics in this section provide information about the financial impact of a payment segment.

Fastpath:

Refer to The Financial Big Picture for more information about a payment's place in the financial big picture.

Next in This Section

- Payment - Current Balance versus Payoff Balance

- The Source Of GL Accounts On A Payment Financial Transaction

Payment - Current Balance versus Payoff Balance

CAUTION:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

A payment segment financial transaction almost always affects payoff balance and current balance by the same amount (think of it like this - when a taxpayer pays, the amount they think they owe goes down by the amount they really owe). The only exception is a payment segment for a charitable contribution. These payment segments only affect current balance because the taxpayer was never assessed for the contribution in the first place.

Fastpath:

Refer to Setting Up Payment Segment Types for more information about how payment segment type affects how a payment segment is produced and how its financial transaction is generated.

The Source Of GL Accounts On A Payment Financial Transaction

A payment segment's financial transaction also contains the double-sided accounting entry that defines how the payment segment affects the general ledger.

Fastpath:

Refer to The Source Of GL Accounts On Financial Transactions for a description of where the system extracts the distribution codes used to construct the GL accounts.

A Payment May Affect More Than Just Taxpayer Balances

The topics in this section provide information about obscure things that may happen when a payment is distributed and frozen.

Next in This Section

- Open Item Accounting and Match Events

- FT Freeze Repercussions

Open Item Accounting and Match Events

Fastpath:

Refer to Payments and Match Events for more information about how payments can create match events for open-item accounts.

FT Freeze Repercussions

Fastpath:

Refer to Obscure Things That Can Happen for more information about things that can happen when an FT is frozen (and FT's get frozen when a payment is frozen).

Automatic Payments

This section discusses how to set up and manage taxpayers who make payments automatically (via direct debit or credit card debits)

Next in This Section

- How To Set Up A Taxpayer To Pay Automatically

- What Are Automatic Payments?

- How And When Are Automatic Payments Created?

- Determining Bank Details

- Automatic Payment Dates

- How To Implement Maximum Withdrawal Limits

- How Are Automatic Payments Cancelled?

- Match Events Are Created For Open-Item Customers When An Automatic Payment Is Created

- Pay Plans and Automatic Payment

How To Set Up A Taxpayer To Pay Automatically

If a taxpayer wants to pay automatically, transfer to Account - Auto Pay and define the source of the funds and the taxpayer's account or credit card number.

Optionally, if automatic payments are for SEPA direct debits, transfer to Account - Direct Debit Mandate and specify the taxpayer's SEPA bank account information.

Refer to SEPA Direct Debit Mandate for more information on SEPA mandates.

What Are Automatic Payments?

An automatic payment is just like any other payment (refer to A Payment Event Has Payments And Tenders for more information about payments in general). However, automatic payments have one special trait - they cause funds to be transferred into your company's bank account. Refer to Downloading Automatic Payments and Interfacing Them To The GL for how this transference happens.

How And When Are Automatic Payments Created?

Automatic payments can be created in several ways:

- If a taxpayer with an account that is set up for automatic payment has a pay plan that is not excluded from automatic payment, a background process (C1-PAYPA) creates an automatic payment on the scheduled payment dates. Please note, the automatic payment is NOT distributed and frozen when the automatic payment is initially created. Rather, a separate background process (APAYDSFR / C1-APYDF) distributes and freezes the automatic payment on the automatic payment GL distribution date (refer to Automatic Payment Dates for more information on how this date is calculated). Refer to The Big Picture of Pay Plans for more information about pay plans.

- A user can create an automatic payment by simply adding a payment tender with a tender type that indicates it is for automatic payment purposes.

- The system creates automatic payments for bills linked to accounts with an active auto pay option.

- At bill completion time, the bill is stamped with the automatic payment's extract date and amount. The date is the automatic payment source's extraction date (refer to Automatic Payment Dates for more information on how this date is calculated).

- The automatic payment background process (APAYCRET) creates the automatic payment on the extract date stamped on the bill.

Note: An algorithm is used to create automatic payments. The logic used to create automatic payments is plugged in on the Installation Record. For more information, go to Installation Options - Algorithms and scroll to the Automatic Payment Creation system event. The base package supplies two sample algorithms. APAY-CREATE creates each auto pay as one payment event with one tender and one payment. Use APAY-CREATE if you use standard payment distribution. C1-APAY-CRDR creates automatic payments using distribution rules. Use C1-APAY-CRDR if you use distribution rules.

- The automatic payment is NOT distributed and frozen when the automatic payment is initially created. A separate background process (APAYDSFR / C1-APYDF) distributes and freezes the automatic payment on the automatic payment GL distribution date (refer to Automatic Payment Dates for more information on how this date is calculated). This means that the taxpayer's balance increases when the bill is completed and is only reduced when the automatic payment is marked for interface to the general ledger.

Note: APAYDSFR uses standard payment distribution. This process assumes the automatic payment was created as: one payment event, one payment. Use this to distribute / freeze payments created by APAY-CREATE.

Note: C1-APYDF uses distribution rules. This process assumes that the automatic payment was created using distribution rules. Use this to distribute / freeze payments created by C1-APAY-CRDR.

An algorithm plugged in on the Installation Record retrieves the details of the bank account from which the automatic payment will be withdrawn. Refer to Determining Bank Details for more information about this plug-in.
An algorithm plugged in on the Installation Record calculates the payment amount whether the automatic payment is created at bill completion time or on the extract date. For more information, go to Installation Options - Algorithms and scroll to the Payment Amount Calculation system event. The base package supplies the algorithm APAM-DFLT.

Note: With balance forward accounting, automatic payments are not just for new charges. The base package algorithm includes prior balances when it creates a taxpayer's first automatic payment. For example, if a taxpayer has an existing balance of $100 and then signs up for automatic payment, their next bill will cause an automatic payment of $100 plus any new charges to be created (assuming the $100 remains unpaid at the time the next bill is completed). Refer to Open Item Versus Balance Forward Accounting for information about balance forward accounting.

When an automatic payment is first created, it gets marked with a distribution date. The distribution date is the date on which the automatic payment's FT's GL details can be interfaced to the general ledger (via the standard GL interface). The distribution date is determined as follows:

- Every automatic payment references an auto pay source.

- Every auto pay source references an auto pay route type.

- Every auto pay route type contains an algorithm that is responsible for calculating the GL Distribution (Posting) date. On the GL distribution date, the automatic payment will be interfaced to the general ledger.

Determining Bank Details

Each automatic payment specifies the details of the bank account, from which funds will be withdrawn. Depending on business rules, bank account details can be captured on Person, Account or Tax Role. Current base logic supports capturing the details on the Account level, i.e. via Account — Auto Pay.

The Bank Details Determination algorithm on the Installation Record is used to retrieve the currently effective bank details that are used for an automatic payment. When called in ‘Read’ mode, this algorithm returns bank details such as Bank Account Number, Bank Routing Number, Account Name, Bank Account Type, etc.

The algorithm can optionally return the following, if applicable:

- Auto pay withdrawal limit

- Additional implementation-specific bank details captured as a list of characteristics.

Note: This characteristics list is provided for implementation use, specially for cases where bank details are stored at an external system. The base-supplied Automatic Payment Creation algorithms store any returned characteristics from Bank Details Determination into the automatic payment’s related Tender. However, the mapping of these saved characteristics into the output auto pay extract file is assumed to be custom logic.

The algorithm that is supplied with the base package assumes that the bank details are stored in Account — Auto Pay. For more information, go to Installation Options - Algorithms and scroll to the Bank Details Determination system event.

Automatic Payment Dates

As described in the previous section, an algorithm (that's plugged in on Auto Pay Route Types) controls the date on which the automatic payment is interfaced to your general ledger. We refer to this date as the GL distribution date.

This algorithm also populates the following dates:

- The payment date that is stored on the payment.

- The date on which the automatic payment is interfaced to the financial institution.

The algorithm that is supplied with the base package provides many parameters that allow you to dictate how these dates are calculated. Please refer to APAY-DTCALC for the details.

How To Implement Maximum Withdrawal Limits

In some locales, taxpayers can define a "maximum withdrawal amount" to limit the amount of money that is automatically debited from their bank account. For example, a low-income taxpayer may want to prevent direct debits of more than $50 from being applied to their checking account.

You define a taxpayer's maximum withdrawal amount when you setup their automatic payment information on Account - Auto Pay.

The following points describe how the system implements maximum withdrawal limits:

- When a bill is completed for a taxpayer who pays automatically the system calls the automatic payment creation algorithm that's plugged in on the Installation Record. The base-package auto pay creation algorithm checks if the amount of the automatic payment exceeds the taxpayer's maximum withdrawal amount. If so, the auto pay creation algorithm calls the automatic payment over limit algorithm that's plugged in on the account's account type. Algorithms of this type have the ability to reduce the amount of the auto pay or to prevent the auto pay from being created. Refer to APOL-RA for an example plug-in.

- When a user manually creates an automatic payment (by adding a tender with a tender type that indicates that it is for automatic payment purposes), the system issues a warning message when the tender amount exceeds the account's maximum withdrawal amount.

Note:

Pay plans. Please note that automatic payments that are created as a result of pay plans are not subject to maximum withdrawal limits. This is because both of these options required taxpayer approval and therefore the taxpayer should be able to plan accordingly. Refer to How And When Are Automatic Payments Created for more information.

How Are Automatic Payments Cancelled?

There are two ways to cancel an automatic payment:

- A user can cancel an automatic payment (refer to How To Cancel A Tender) at any time. You would do this if the financial institution rejected the automatic payment.

- For legacy billing, the system will cancel an automatic payment behind-the-scenes if the related bill (if any) is reopened before the automatic payment is interfaced to the financial institution. When you recomplete the bill, the system will create a new automatic payment that reflects the new amount due (and the canceled automatic payment will net out the original automatic payment).

Match Events Are Created For Open-Item Customers When An Automatic Payment Is Created

The system creates a match event when a bill is completed for open-item customers that pay automatically (i.e., direct debit taxpayers). The match event groups together the bill's new charges against the automatic payment's payment segments.

If the bill is subsequently re-opened, the match event will be cancelled when the automatic payment is cancelled.

Fastpath:

Refer to Open Item Accounting for more information.

Pay Plans and Automatic Payment

If a taxpayer wants to pay their pay plan scheduled payments automatically, the account must be set up for automatic payment (as described under How To Set Up A Taxpayer To Pay Automatically). In addition, the pay plan must indicate that automatic payment is being used.

When this is done, a background process referred to as C1-PAYPA creates automatic payments on the scheduled payment date by calling the automatic payment creation algorithm plugged in on the installation record.

Issuing A Payment Advice Instead Of Creating An Automatic Payment

If the system is configured to send the taxpayer a payment advice (instead of initiating an electronic funds transfer) when a bill is completed, the automatic payment records - i.e. payment event, payment, tender and auto pay clearinghouse staging - are not created. Refer to Payment Advice for more information.

Next in This Section

- How To Set Up A Taxpayer To Receive Payment Advice

- Payment Advice Option Is For Bill-Related Automatic Payments Only

How To Set Up A Taxpayer To Receive Payment Advice

Use Account - Auto Pay to capture the taxpayer's bank details and indicate an auto pay method of Payment Advice.

Payment Advice Option Is For Bill-Related Automatic Payments Only

Payment advice can be printed for auto pays that result from completed bills.

An auto pay for a pay plan scheduled payment will not be created if the account's effective auto pay option is set to Payment Advice. The Pay Plan Pay Plan Auto Pay ( C1-PAYPA) batch process will log an error in this case.

Manually created automatic payments (i.e. auto pays created via payment event UI) are always processed as direct debit.

Maintaining Payment Events

A payment event is used to record when moneys are remitted and how the moneys are allocated amongst accounts. The topics in this section describe how to maintain payment events.

Note:

The system creates most payment events behind-the-scenes. Most payment events are created by the system when it uploads payments and when it creates automatic payments. You should only have to access the payment event transaction if you need to correct a payment event or add a payment event real-time. For information about how the system creates payment events, refer to The Big Picture of Payments.

Next in This Section

- Payment Lifecycle

- Payment Event - Add Dialog

- Payment Event - Main Information

- Payment Event - Tenders

- Payment Event Action Codes

Payment Lifecycle

The topics in this section describe the lifecycle of the various payment objects.

Next in This Section

- Payment Event Lifecycle

- Tender Lifecycle

- Payment Lifecycle

Payment Event Lifecycle

The following diagram shows the possible lifecycle of a payment event.

CAUTION:

This diagram only makes sense in the context of the page used to maintain payment events. Refer to Payment Event - Main Information for the details.

The system, by default, distributes the sum of a payment event's tenders to the account that remits the tenders. After distribution the sum of the tenders equals the sum of the payments (remember, the term payment is used to refer to an allocation of some/all of a payment event's tenders to an account's debt) when the event is first created. We refer to such an event as being Balanced.

It is possible via any of the methods described in Unbalanced Payment Events to make a balanced payment event Unbalanced.

Click Delete to physically remove a balanced or unbalanced payment event from the database. You may not delete a payment event if: a) there are frozen or canceled payments linked to the event, or b) if there are canceled tenders linked to the event, or c) if a tender linked to the event is part of a balanced tender control. When the payment event is deleted, the system also deletes its tenders, payments, and payment segments.

Tender Lifecycle

The following diagram shows the possible lifecycle of a payment event.

CAUTION:

This diagram only makes sense in the context of the page used to maintain tenders. Refer to Payment Event - Tenders for the details.

A tender is initially saved in the Valid state. It is possible via any of the methods described in Unbalanced Payment Events to make a balanced payment event Unbalanced.

If a tender is invalid, click Cancel to cancel the tender AND ALL PAYMENTS LINKED TO THE EVENT.

Click the delete button to physically remove a tender from the database. You may not delete a tender if it is part of a balanced tender control.

Payment Lifecycle

The following diagram shows the possible lifecycle of a payment.

CAUTION:

This diagram only makes sense in the context of the page used to maintain a payment. Refer to Payment - Main for the details.

Payments are initially created in the Incomplete state. Payments in this state don't have payment segments or financial transactions; they are simply a stub awaiting distribution.

Click Distribute to distribute a payment amongst an account's obligations.

- If the system cannot distribute the payment (for whatever reason), the payment is moved to the Error state. You may delete such a payment.

- If the system successfully distributes a payment, the payment becomes Freezable.

Click the - button to physically remove an Incomplete, Error or Freezable payment from the database.

Click Freeze to freeze a payment and its financial transaction. Freezing the payment causes the following to occur:

- The system executes any payment freeze algorithms linked to the account's account type and to the obligation's obligation type.

- The payment's state becomes Frozen and the payment may now appear on a taxpayer's bill.

You may not change a payment once it is frozen. However, you may reverse the payment's financial effect by clicking Cancel button. Clicking this button will cause the following to occur:

- A new financial transaction is generated and linked to the payment. This financial transaction reverses the financial effects of the original payment.

- The system executes any payment cancellation algorithms linked to the account's account type.

- If the payment has a related adjustment, this adjustment is also cancelled.

- The payment becomes Canceled.

Payment Event - Add Dialog

The Payment Event transaction features an unusual dialog that simplifies the addition of new payment events. This page appears if you open the Menu > Payments > + Payment Event or from the Account context menu (it also appears if you click the clear button when on the Payment Event page).

Note: If you have opted to always use the payment event distribution rules method as your default method, the Payment Event Quick Add (Single Payment Event) page appears instead.

Description of Page

The Payor Account ID is the account that remitted the payment. We assume this account is both the tendering account and the account whose debt is being relieved by the payment. If this assumption is not correct, choose a Distribute Action of Do Not Distribute and then change the tendering or paying account when the Payment Event page appears (after you click OK).

Note: Default note. If you have navigated to this page from account context menu, the Payor Account ID and Payment Amount are defaulted to this account.

The Payment Amount is the amount of the taxpayer's debt to be relieved by the payment. Note, this amount is defaulted using an algorithm plugged in on the Installation Record. Please refer to APAM-DFLT for more information about how the algorithm that is supplied with the base package calculates this amount.

The payment tenders grid allows you to enter multiple tender types and amounts. Click + to add a new tender. For each tender specify the following fields:

- The Amount Tendered is the amount of moneys remitted for the tender type.

- Tender Type describes what was remitted (e.g., cash, check, …). Tender Type defaults from the Quick Add Tender Type that is defined on the installation record.

- If a check was tendered, use Check Number to specify the identity of the check.

Note: Cash back causes an additional tender to be created. If cash should be returned to the taxpayer (because the taxpayer overpaid and the tender type's cash back allowed switch is true and the tender type is not "like cash"), a negative tender for the cash back amount is created for the payment event. Refer to Cash Back for a description of how the system can recommend Cash Back amount if the taxpayer tendered more than they are paying.

Match Type and Match Value are used if either of the following conditions is true:

- This Payor Account belongs to an open item account type. In this situation, specify a Match Type to define how the payment should be matched to the taxpayer's open-items and use Match Value to define the open-items covered by the payment. For example, if this payment is in respect of a bill, specify a match type of "bill id" and a match value of the bill id being paid.

Note: Shortcut. If you enter a Match Type of "bill id" and leave the Match Value blank, the system assumes the taxpayer wants to pay the latest bill.

- The taxpayer wants to restrict the distribution of the payment to a specific obligation. In this situation, specify a Match Type of "obligation ID" and a Match Value of the respective obligation ID.

The Payment Date defaults to the current date.

If the Payor Account ID's account type is designated as non-tax agency payor (i.e., the person making the payment isn't a taxpayer), the following information appears in the above window:

Non Tax Agency Name is the name of the person remitting the payment.

Reference Number is the reference number of the item being paid (e.g., the property tax reference number).

Non Tax Agency Comments are used to describe anything unusual about the non tax agency payment.

Use Distribute Action to describe what you'd like to have happen when you click the OK button:

- Choose Distribute and Freeze if OK if this is a simple payment that should require no manual intervention. By "simple payment" we mean:

- The account is both the tendering account and the account whose debt is being relieved by the payment

- The payment date is the current date

- The payment should be distributed amongst the account's obligations using standard distribution logic

If this option is selected, the system distributes the Payment Amount amongst the account's obligations. If the distribution is successful, the system automatically freezes the payment. If the distribution is not successful, the payment will be in the Error or Incomplete state. When the Payment Event page appears, you can view the error and then correct it. After the cause of the error is corrected, you must distribute and freeze the payment manually (this can be done on several pages including Payment Event - Main and Payment - Main).

- Choose Manual Distribution if you need to manually distribute the payment amongst the account's obligations. If this option is selected, the system creates a payment event, a tender and a payment and then transfers you to the Payment - Manual Distribution page where you can define the amount to be allocated to each of the account's obligations. After you've distributed the payment, don't forget to freeze it.

- Choose Do Not Distribute if you want to process the payment event manually (e.g., if you need to define multiple accounts whose debt is relieved by the payment). If this option is selected, the Payment Event - Main page opens with the information you entered defaulted accordingly. You can make any changes you want and then distribute and freeze the payment. Refer to How To Add A New Payment Event for more information.

Payment Event - Main Information

The Main page contains core payment event information. Open this page using Menu > Payments →Payment Event.

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How To for a description of how to perform common payment event maintenance functions.

Description of Page

Pay Event Info contains a concatenation of the payment date, amount, and the name of the main taxpayer on the account that remits the tender. If multiple tenders exist, the taxpayer's name is not displayed. If the payment event is associated with a single distribution detail, the rule name and the description of the rule value are displayed as well. If multiple distribution details exist, Multiple Distribution Details Exist is displayed instead. Pay Event Info is only displayed after the payment event has been added to the database.

Payment Event ID is the system-assigned unique identifier of the payment event.

The area under Pay Event Info provides warnings about the payment event. Possible warnings are Unfrozen Payments and The Payment Event is Unbalanced. A warning is also issued to the cashier to remind him/her to turn in funds - see Turn Ins.

If multiple distribution details are linked to the payment event, the distribution rule, value and amount for each distribution detail is displayed.

Payment Date is the business date associated with the payment event.

CAUTION:

If you change the payment date and this event's tender(s) are automatic payments, the extract date (i.e., the date the automatic payment is sent to the financial institution) will be changed to equal the payment date. Refer to Automatic Payments for more information.

Effective Date is populated by the algorithm that creates the payment and is used to populate the FT effective date. For example, an income tax return that the taxpayer files on April 1st that is due on April 15th has an effective date of April 15th.

Note:

Changing effective date. Refer to Payment Date and Effective Date for Payment Events for information about changing the effective date of a distributed payment event.

Payment(s) contains the total number and value of payments linked to the event.

Tender(s) contains the total number and value of tenders linked to the event.

Amount Tendered contains the amount that was tendered by the taxpayer.

The system displays a Cash Back Amount if the taxpayer tenders more than they are paying (refer to Cash Back for details).

If the payment event becomes unbalanced, a Recalculate Cash Back button appears. If this button is clicked, the system creates, deletes or recalculates the cash back tender. Refer to Cash Back for details.

While most payment events contain a single payment, the system allows many payments to exist under a payment event (when the payment event's tender(s) are distributed amongst multiple accounts). If a payment event has a large number of payments, you can use the Account Filter to limit the payments that appear in the Payments grid. The following options are available:

- Account. Use this option if you only want to see the payment linked to an Account ID.

- All. Use this option to view all payments linked to the payment event.

- Person Name. Use this option to restrict payments linked to accounts whose main taxpayer has a primary name that matches Person Name.

The Payments grid contains the payment(s) linked to the payment event. The following points describe the attributes in this scroll; refer to How To for instructions describing how to perform common maintenance activities.

- If the payment is created via distribution details, the Distribution Sequence associated with this payment is displayed.

- Account ID references the payment's account. The name of the account's main taxpayer is displayed adjacent.

- Payment Amount is the amount of the account's debt relieved by the payment. The adjacent context menu allows you to drill down to the details of the payment (this is where you can see the payment's payment segments and where you can override the distribution of the payment).

- Payment Status is the payment's status. If the payment's status is Error, the error message is displayed adjacent. Refer to Payment Lifecycle for the potential values and how to handle a payment when it exists in a given state.

- Match Type and Match Value should only be used if either of the following conditions is true:

- This Account ID belongs to an open item account type. In this situation, specify a Match Type to define how the payment should be matched to the taxpayer's open-items and use Match Value to define the open-items covered by the payment. For example, if this payment is in respect of a bill, specify a match type of "bill id" and a match value of the bill id being paid.

- The taxpayer wants to restrict the distribution of the payment to a specific obligation. In this situation, specify a Match Type of "obligation ID" and a Match Value of the respective obligation ID.

- The remaining columns are only used if the payment is linked to an Account ID that belongs to an account type that is used for non-agency payments. Refer to Setting Up Account Types for more information. If such an account exists, the following fields must be defined.

- Non Tax Agency Name is the name of the person remitting the payment.

- Reference Number is the reference number of the item being paid (e.g., the property tax reference number).

- Non Tax Agency Comments are used to describe anything unusual about the non tax agency payment.

Note, you can also define a comment for a non tax agency payment. To define a comment, use the context menu adjacent to Payment Amount to drill to Payment - Main.

- Payment ID is the unique, system-assigned identifier of the payment. This value only appears after the payment has been added to the database.

Refer to Payment Actions and Payment Event Actions for information about the action buttons on this page. Refer to How To for a description of typical business processes that use these buttons.

Payment Event - Tenders

The Tenders page contains a scroll showing one row for every tender associated with the payment event. Open this page using Menu > Payments > Payment Event and navigate to the Tenders tab.

Fastpath: The Description of Page section that appears below simply describes the fields on this page. Refer to How To for instructions describing how to perform common maintenance functions.

Description of Page

Pay Event Info contains a concatenation of the payment date, amount, and the name of the main taxpayer on the account that remits the tender. If multiple tenders exist, the taxpayer's name is not displayed. If the payment event is associated with a single distribution detail, the rule name and the description of the rule value are displayed as well. If multiple distribution details exist, Multiple Distribution Details Exist is displayed instead. Pay Event Info is only displayed after the payment event has been added to the database.

Payment Event ID is the system-assigned unique identifier of the payment event.

Payment Date is the business date associated with the payment event.

Payment(s) contains the total number and value of payments linked to the event.

Tender(s) contains the total number and value of tenders linked to the event.

Amount Tendered contains the amount that was tendered by the taxpayer.

The system displays a Cash Back Amount if the taxpayer tenders more than they are paying (refer to Cash Back for details).

If the payment event becomes unbalanced, a Recalculate Cash Back button appears. If this button is clicked, the system creates, deletes or recalculates the cash back tender. Refer to Cash Back for details.

The Tenders scroll controls the display of the tenders linked to the payment event. The following simply describes the fields in this scroll; refer to How To for instructions describing how to perform common tender maintenance activities.

- Payor Account ID references the tendering account. The name of the account's main taxpayer is displayed adjacent.

CAUTION:

If you change the Payor Account ID and the tender has an associated automatic payment request, the automatic payment request will be removed. A new automatic payment request will be created for the new Payor Account ID. Refer to Automatic Payments for more information.

- Tender Amount is the amount of the tender.

- If a check was used, the Check Number contains the identity of the check.

- Pay Tender ID is the system-assigned unique identifier of the tender. This value appears after the tender has been added to the database.

- Tender Type describes what was remitted (e.g., cash, check). If the Tender Type is associated with an automatic payment, the page displays a section that includes information about how and when the automatic payment was interfaced to the payment source.

- Tender Status is the tender's status. Refer to Tender Lifecycle for the potential values and how to handle a tender when it exists in a given state.

- If the Tender Type is associated with an automatic payment, the system attempts to default automatic payment information from the account's auto pay option if the tender type is the same as the tender type on the account's auto pay source and if the auto pay option is effective on the payment date. If the system is unable to default information, you must specify the source of the funds and the taxpayer's account number / credit card number at the financial institution. You can override automatic payment information as long as the automatic payment has not been sent to the financial institution or cancelled.

- Auto Pay Source Code is the financial institution / credit card company that receives the automatic payment request.

- Scheduled Extract Date is the date the automatic payment request was sent / is scheduled to be sent to the financial institution. This information is display-only.

- Bank Routing Number identifies the financial institution.

- External Account ID is the taxpayer's account number at the financial institution.

- Expires On is only needed if the Tender Type indicates that an expiration date is necessary (e.g., for a credit card payment).

- Name is the taxpayer's name in the financial institution's system.

- Bill ID is the ID of the bill whose completion caused the creation of the automatic payment. This information only appears if your implementation uses Classic Billing and the automatic payment was created as a result of a bill. This information is display-only.

- If the payment was uploaded, the following fields may contain information (if they were populated in the interface file):

- MICR ID is the value of the magnetic ink character recognition (MICR) line on the payment.

- Customer ID is the taxpayer's account ID that appeared on the interfaced payment.

- External Reference ID is the unique identifier of the payment upload interface record.

- Name is the taxpayer's name on the interfaced payment record.

- In the Tender Control area, the Tender Control ID is the identity of the remittance processor batch or cash drawer bundle in which the tender was remitted. Refer to Tender Management and Workstation Cashiering for more information about tender controls.

Displayed adjacent to Tender Control is the date, tender source, and status of the tender control.

Every new tender must reference an open tender control. The system will attempt to default an appropriate tender control as follows:

- If the user has at least one open, user-specific Tender Control, the system will default one, at random.

- If the user has no open, user-specific Tender Controls; the system will default an open, "all users" tender control if it can find one whose tender source indicates it's used for online cashiering. If multiple exist, one will be selected at random.

Turn off Included in Tender Ctl Balance if the tender should not be included in the tender amount in the tender control's tender balance. You would turn this switch off if you canceled a tender because it was mistakenly applied to the wrong account (or the amount was wrong). This switch is only enabled if:

- The tender control isn't balanced.

- The tender is canceled.

Deposit Control contains a concatenation of the tender control's deposit control's creation date, tender source type, and status. Refer to Tender Management and Workstation Cashiering for more information about deposit controls.

- The Tender Action area contains a button that you use to cancel a tender. Refer to Tender Actions for information about this button. Refer to How To Cancel A Tender for more information.

The Characteristics collection contains information that describes miscellaneous information about the tender. The following fields display:

Characteristic Type indicate the type of characteristic.

Sequence controls the order in which characteristics of the same type are displayed.

Characteristic Value indicates the value of the characteristic.

Payment Event Action Codes

The topics that follow describe each of the actions that appear on the payment event pages.

Next in This Section

- Payment Actions

- Payment Event Actions

- Tender Actions

Payment Actions

The topics that follow describe payment-oriented actions. Refer to How To for a description of several business processes that use these buttons.

Next in This Section

- Distribute (Payments)

- Redistribute (Payments)

- Print

- Freeze (Payments)

Distribute (Payments)

Clicking the Distribute button distributes all Incomplete, Error, or Freezable payments linked to the event. Refer to Distribute (A Payment) for information of how a single payment is distributed.

This button is enabled if at least one payment is Incomplete, Error, or Freezable.

Redistribute (Payments)

Clicking the Redistribute button redistributes all Incomplete, Error, or Freezable payments linked to the event. Refer to Redistribute (A Payment) for information of how a single payment is redistributed.

This button is enabled if at least one payment is Incomplete, Error, or Freezable.

Print

This button is enabled under the following conditions:

- The document cm_POSPrint.js must be present on the web server and the variable defined in that document must be set to true. This is to indicate that point of sale (POS) printers are in use. Refer to the installation guide for more information about setting up receipt printers.

- The payment event must have at least one payment that is frozen AND no payments that are in Incomplete, Error or Freezable

Refer to How To Print Receipts And Endorsements for more information.

Freeze (Payments)

Clicking the Freeze button causes all Freezable payments linked to the event to become frozen. Refer to Freeze (A Payment) for information of how a single payment is frozen.

This button is enabled if at least one payment is Freezable.

Note:

If problems are detected after freezing. A payment may not be changed after it is frozen. All subsequent changes must occur by canceling the frozen payment and creating a new one. You can cancel and redistribute a payment on the next tab. Refer to Canceling A Tender Versus Canceling a Payment for more information.

Payment Event Actions

The topics in this section describe payment event-oriented actions. Refer to How To for a description of typical business processes that use these buttons.

Next in This Section

- Transfer

- Delete A Payment Event

Transfer

If the payment event was created using distribution rule(s), any transfer of its payments should also be done using the distribution rules method. Hence, a different dialog opens when you click Transfer based on whether the payment event is associated with at least one distribution detail or not.

Transfer (No Distribution Details Exist)

The Transfer button is enabled if:

- There is a single non-cancelled tender linked to the event AND

- There is a single frozen payment linked to the event AND

- The account on the tender is the same as the account on the payment.

You must specify the following parameters in order to transfer a payment:

- Account ID is the account to which the payment event should be transferred.

- Cancel Reason defines why you are performing the transfer.

- Match Type and Match Value are defaulted based on their values for the payment event that you are transferring. If necessary, modify the values appropriately for the account to which you are transferring the payment event. Match Type and Match Value are used for an account that belongs to an open item account type or to restrict the distribution of the payment to a specific obligation. Refer to Payment Event - Main for more information.

- Turn on Freeze Payment if the transferred payment should be frozen automatically. You may want to leave this turned off if you want to examine the payment distribution before freezing the payment.

- Non Tax Agency Name, Reference Number, and Non Tax Agency Comments appear if the Account ID belongs to an account type that is used for non tax agency payments. Refer to Setting Up Account Types for more information.

Clicking OK causes the following to take place:

- The account on the tender is changed to reflect the transfer to account.

- The original payment and its segments are cancelled.

- A new payment is added for the transfer to account.

- The new payment is distributed.

- If so designated, the new payment is frozen.

- The payment characteristics associated with the original payment are copied to the new payment.

Transfer (Distribution Details Exist)

The Transfer button is enabled if:

- There is a single payor AND

- All existing payees before the transfer are the same as the payor AND

- There is at least a single non-cancelled tender linked to the event

You must specify the following parameters in order to transfer payment(s):

- Distribution Rule is the code that the system uses to determine how the new payment event should be distributed.

- Rule Value is the value associated with the payment and expected by the distribution rule.

- Amount is the payment amount.

- Cancel Reason defines why you are performing the transfer.

Clicking OK causes the following to take place:

- The payment(s) associated with the original account are canceled.

- The new set of distribution details are processes, creating new payment(s) for the transfer to account.

- If all new payments are for the same payee account (and the payee is different than the current payor) the account on the tender is changed to reflect the transfer to account.

- Original distribution details (only those with a non-zero amount) are deleted and replaced by the new set of details on the payment event.

Note:

Distribution rule entries can have a zero amount. Refer to Rule Value Can Capture Additional Information for more information about how to use distribution details to capture additional payment related information.

Note:

Determine Tender Account. This dialog does not call the Determine Tender Account algorithm defined on distribution rule as this action does not rebuild the payment tender collection.

Fastpath:

Refer to Rule Value Can Capture Additional Information for more information about how to use distribution details to capture additional payment related information.

Delete A Payment Event

The Delete button deletes a payment event and its tenders and payments.

This button is enabled if there are no frozen or canceled payments and no canceled tenders.

Tender Actions

The topics that follow describe tender-oriented actions. Refer to How To for a description of several business processes that use these buttons.

Next in This Section

- Cancel A Tender

Cancel A Tender

Clicking Cancel causes the following to take place:

- All payments associated with the tender's payment event are canceled.

- The tender becomes canceled.

- If the cancellation reason indicates the cancellation is due to non-sufficient funds, other actions may occur. Refer to NSF Cancellations for more information.

The Cancel button is enabled if the tender is not canceled

You must specify the following parameters in order to cancel a tender:

- Select a Cancel Reason to describe why the tender is being canceled.

- The system also needs to know which Bank Account To Charge the cancellation against. The system will default the Bank Code and Bank Account from the original bank information used when the tender was deposited. You can override them here.

When you click the OK button, the system cancels the tender and ALL payments linked to the event.

Note:

When non-canceled tenders are still linked to the event. If there are multiple tenders linked to the payment event, you must either add new payment(s) that equal the sum of the event's non-canceled tenders or cancel the remaining tenders.

Note:

Cancellation after cash back. If a taxpayer tenders a check for $100, but only owes $80, the system will recommend returning $20 in cash to the taxpayer (assuming the tender type for checks allows overpayment). If the tender type for checks is not "like cash", a second tender is created for -$20 (the first tender is for $100). If the check subsequently bounces, both tenders must be cancelled.

Payment Event Quick Add

The Payment Event Quick Add page is used to quickly add, distribute and freeze one or more payment events using distribution rules. Open this page using Menu > Payments > Payment Event Quick Add .

Description of Page

Specify the Tender Control ID in which the tenders will be recorded. Every new tender must reference an open tender control. The system will attempt to default an appropriate tender control as follows:

- If the user has at least one open, user-specific Tender Control whose tender source has a tender source type of online cashiering or ad hoc, the system will default one, at random.

- If the user has no open, user-specific Tender Controls; the system will default an open, "all users" tender control if it can find one whose type is online cashiering or ad hoc. If multiple exist, one will be selected at random.

Specify the Payment Date. The current date defaults. Note that you can modify the payment effective date on the Payment Event page. See Payment Event - Main for more information.

Use Number of Payment Events to indicate whether you intend to add a single payment event or multiple payment events.

Choose the multiple payment events option if you intend to add "simple" payment events. By "simple" we mean:

- A single account is both the payor account and the account whose debt is being relieved by the payment.

- The payment tender is not an auto pay tender.

For all other cases choose the single payment event dialogue as it is designed to handle more complex payment event configurations such as when:

- The payor account is different than the payee account.

- Multiple payors cover payments for one or more payees.

- The payment tender is an auto pay tender.

Once you have made your selection the page is adjusted to support the corresponding dialog.

Next in This Section

- Multiple Payment Events Dialog

- Single Payment Event Dialog

Multiple Payment Events Dialog

This is the default dialog setup when navigating from Financial, Payment Event Quick Add.

Description of Page

Using the multiple payment events option, each row in the payment detail grid typically represents a unique distribution detail. However, more than one row in the grid can belong to a single payment event. All distribution details for identical tender account will be grouped under a single pay event.

The following columns appear in the Payments grid:

- Select a Distribution Rule by which the payment detail is to be processed. If you have set up a default distribution rule, it is defaulted in the first row. Note that only distributions rules that define a "determine tender account" algorithm are visible.

- Specify the Rule Value associated with the payment and expected by the distribution rule.

- Use Tender Amount to define the amount of the payment.

- Use Tender Type to define the form or remittance (e.g., cash, check, etc.). Note that the Tender Type defaults from the installation record.

Note: Automatic Payments. The multiple payment events dialog does not support automatic payments. Switch to the single payment event dialog to enter automatic payments.

- Use Check Number if a check is remitted.

- MICR ID is the value of the magnetic ink character recognition (MICR) line on the payment.

- You may use Customer ID to record additional taxpayer information.

- You may use External Reference ID to record external information associated with the payment tender.

- You may use Name to record additional payment tender information.

- Payor Account ID is the tender account as determined by the Determine Tender Account algorithm defined on the distribution rule. This information is only populated after the distribution detail has been processed.

After specifying the various payment distribution details in the grid, click Create. The system attempts to create payment event(s) as follows:

- As mentioned earlier, all distribution details for identical tender accounts are grouped under a single pay event. The first step in identifying common tenders is to determine the tender account. To do that the system calls the Determine Tender Account algorithm defined on the distribution rule.

- A payment event is created for each unique tender account.

- All rows having all attributes of the tender identical except for the amount are grouped together where each group represents a single tender.

- A single payment tender is created for each unique tender and linked to the payment event.

- The total payment amount for each distinct group of distribution details (for the payment event) having the same rule and value is summarized. For each distinct group, the system calls the Create Payment algorithm defined on the distribution rule providing it with the rule value and total payment amount. It is the responsibility of this algorithm to create the payments for this payment event.

- Add the distinct payment event distribution detail and its total amount beneath the payment event.

- If the tender control's tender source type indicates that this is a cashiering station and your implementation is configured for printing at a cashier station, the Print Dialog appears.

The Payment Event ID column appears in the grid after the distribution details have been processed. It shows the payment event ID created for the distribution detail record and a short description as to the status of the payment(s) created for the payment event. You can use this field to navigate to the payment event.

After you've added a group of payment events, you should press the clear button (or Alt-C), to ready the page for the next group of payment event details.

Single Payment Event Dialog

If you have opted to always use the payment event distribution rules method as your default method, this is the default dialog setup you would see when you navigate to the Payment Event page in Add mode.

Adding a single payment event at a time, allows for more complex payment event information to be captured.

Enter one row in the Tenders grid for every unique tender associated with the payment event.

- Payor Account ID references the tendering account. The name of the account's main taxpayer is displayed adjacent.

CAUTION:

If you change the Payor Account ID and the tender has an associated automatic payment request, the automatic payment request will be removed. A new automatic payment request will be created for the new Payor Account ID. Refer to Automatic Payments for more information.

- Tender Amount is the amount of the tender.

- Use Tender Type to define the form or remittance (e.g., cash, check, etc.). Note, the Tender Type defaults from the installation record.

- Use Check Number if a check is remitted.

- MICR ID is the value of the magnetic ink character recognition (MICR) line on the payment.

- You may use Customer ID to record additional taxpayer information.

- You may use External Reference ID to record external information associated with the payment tender.

- You may use Name to record additional payment tender information.

- If the Tender Type is associated with an automatic payment, the page displays a section that includes information about how and when the automatic payment was interfaced to the payment source.

- If the Tender Type is associated with an automatic payment, the system attempts to default automatic payment information from the account's auto pay option if the tender type is the same as the tender type on the account's auto pay source and if the auto pay option is effective on the payment date. If the system is unable to default information, you must specify the source of the funds and the taxpayer's account number / credit card number at the financial institution.

- Auto Pay Source Code is the financial institution / credit card company that receives the automatic payment request.

- External Account ID is the taxpayer's account number at the financial institution.

- Expires On is only needed if the Tender Type indicates that an expiration date is necessary (e.g., for a credit card payment).

- Name is the taxpayer's name in the financial institution's system.

The following columns appear in the Payments grid:

- Select a Distribution Rule by which the payment detail is to be processed. If you have set up a default distribution rule, it is defaulted in the first row.

- Specify the Rule Value associated with the payment and expected by the distribution rule.

- Use Amount to define the amount of the payment.

After specifying the various payment distribution details in the grid, click Create.

Note:

Go To Payment Event. If you wish to be transferred to the payment event page once processing is complete, remember to check the Go To Payment Event check box before you click Create. This field does not appear when this page is used as the default Payment Event - Add Dialog and you are automatically transferred to the payment event page once the payment event is created.

After distribution details have been processed, a short description of the payment event that has been created is displayed to the right of the Go To Payment Event field. The description provides information as to the status of the payment(s) created for the payment event. You can use this field to navigate to the payment event.

The system attempts to create the payment event as follows:

- Validate that the sum of the tenders equals the sum of the payments.

- Create the payment event with a separate payment tender for each row in the Tenders grid.

- Summarize the total payment amount for each distinct group of distribution details having the same rule and value. For each distinct group, call the Create Payment algorithm defined on the distribution rule providing it with the rule value and total payment amount. It is the responsibility of this algorithm to create the payments for the payment event.

- Add the distinct payment event distribution detail summary beneath the payment event.

- If the tender control's tender source type indicates that this is a cashiering station and your implementation is configured for printing at a cashier station, the Print Dialog appears.

Note:

Determine Tender Account. Having an explicit collection of tenders eliminate the need to determine the tender account. Therefore this dialog does not call the Determine Tender Account algorithm.

Payment Quick Add

The Payment Quick Add page is used to quickly add, distribute and freeze payment events for up to fifteen accounts. Open this page using Menu > Payments > Payment Quick Add.

Description of Page

Specify the Tender Control ID in which the tenders will be recorded. Every new tender must reference an open tender control. The system will attempt to default an appropriate tender control as follows:

- If the user has at least one open, user-specific Tender Control whose type is online cashiering or ad hoc, the system will default one, at random.

- If the user has no open, user-specific Tender Controls; the system will default an open, "all users" tender control if it can find one whose tender source has a tender source type of online cashiering or ad hoc. If multiple exist, one will be selected at random.

Specify the Payment Date. The current date defaults. Note that you can modify the payment effective date on the Payment Event page. See Payment Event - Main for more information.

Enter one row in the grid for every payment event to be added. The following information is entered for each payment event:

- Use Account ID to define the taxpayer who tendered the payment. It's important to note that this transaction assumes that the tendering account is the same as the account whose balance is relieved by the payment. Refer to How To Allocate The Tender Amount To Multiple Accounts if you need to distribute the payment to an account (or accounts) other than the tendering account.

- Use Payment Amount to define the amount of the payment.

- Use Tender Type to define the form or remittance (e.g., cash, check, etc.). Note, the Tender Type defaults from the installation record.

- Use Check Number if a check is remitted.

- Match Type and Match Value are only used if either of the following conditions is true:

- This Account ID belongs to an open item account type. In this situation, specify a Match Type to define how the payment should be matched to the taxpayer's open-items and use Match Value to define the open-items covered by the payment. For example, if this payment is in respect of a bill, specify a match type of "bill id" and a match value of the bill id being paid.

- The taxpayer wants to restrict the distribution of the payment to a specific obligation. In this situation, specify a Match Type of "obligation ID" and a Match Value of the respective obligation ID.

After specifying the various accounts and amounts in the grid, click the Distribute and Freeze button. When you click this button, the system attempts to create a payment event for each row in the grid. Four potential outcomes are possible for each row:

- If the data you entered for a payment event isn't complete (e.g., you don't specify a valid account or amount):

- No payment event is created.

- A Message describing the problem is displayed.

- All fields on the row remain modifiable.

You should correct each such line and then press the Distribute and Freeze button.

- If the data you entered is complete, but the system issues a warning for any reason:

- No payment event is created.

- A Message containing the warning is displayed.

- All fields on the row remain modifiable.

You must clear the line and add a payment using the Payment Event transaction (note, if you use the Account context menu to transfer to the Payment Event page in add mode, you won't have to retype the Account ID when you add the payment event).

- If the data you entered is complete, but the system is not successful in distributing the payment:

- The system creates a payment event, a payment and a tender.

- A Message describing the problem is displayed.

- The payment's Status is displayed

- All fields on the row are disabled.

You must press the adjacent go to button to drill to the payment event where the error can be corrected.

- If the data you entered is complete and the system is successful in distributing the payment:

- The system creates a payment event, a payment, and a tender.

- The system distributes the payment amongst the account's obligations and then freezes the payment.

- The payment's Status is displayed.

- All fields on the row are disabled.

- If the tender control's tender source type indicates that this is a cashiering station and your implementation is configured for printing at a cashier station, the Print Dialog appears.

You can press the adjacent go to button to view a payment event.

Note: Separate Commits. This page is unusual in that each payment event is committed to the database independently. For example, if you enter seven payment events and one is invalid, six payment events will be added to the database when you press Distribute and Freeze. When the page is redisplayed, the rows containing the valid payments are protected and an indication of their validity is displayed. The row containing the invalid payment remains unprotected. You can correct the erroneous payment and then press the Distribute and Freeze button again.

After you've added a group of payments, you should press the clear button (or Alt-C), to ready the page for the next group of payment events.

Maintaining Payments

Payments and payment segments are automatically created by the system when payment events are created. You should only need to access this transaction as follows:

- To view a payment's payment segments (i.e., to view how a payment was distributed amongst its account's obligations).

- To override the distribution of a payment amongst its account's obligations. Refer to Distributing A Payment Amongst An Account's Obligations for information describing how payments are typically distributed.

The topics in this section describe how to maintain a payment.

Next in This Section

- Payment - Main

- Payment - Pay Segments

- Payment - Manual Distribution

- Payment - Characteristics

- Payment Action Codes

Payment - Main

This page contains basic information about a payment. Open this page using Menu > Payments > Payment.

CAUTION:

Most payments are maintained using the Payment Event page. The transaction described below is typically only used to view a payment's payment segments and to manually distribute a payment amongst an account's obligations.

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How To for instructions on how to perform common maintenance functions.

Description of Page

Payment Info contains a concatenation of the payment date, amount, status, and the name of the main taxpayer on the account.

Payment ID is the system-assigned unique identifier of the payment.

Payment Event ID is the system-assigned unique identifier of the payment event. The adjacent info contains a concatenation of the payment date, amount, and the name of the main taxpayer on the account that remits the event's tender. If multiple tenders exist, the taxpayer's name is not displayed. A warning may also be displayed. The possible warnings are Unfrozen Payments and The Payment Event is unbalanced.

Payment(s) contains the total number and value of payments linked to the payment event.

Tender(s) contains the total number and value of tenders linked to the payment event.

Account ID is the account whose debt is reduced by the payment. The name of the account's main taxpayer is displayed adjacent. This field is gray after the payment is frozen.

Payment Amount is the amount of the payment. This field is gray after the payment is frozen.

Payment Status is the payment's status. Refer to Payment Lifecycle for the potential values and how to handle a payment when it exists in a given state. If the payment is in Error, the error message is displayed adjacent. If the payment is canceled, the Cancel Reason is displayed adjacent.

Match Type and Match Value will only be used if either of the following conditions is true:

- This Account ID belongs to an open item account type. In this situation, specify a Match Type to define how the payment should be matched to the taxpayer's open-items and use Match Value to define the open-items covered by the payment. For example, if this payment is in respect of a bill, specify a match type of "bill id" and a match value of the bill id being paid.

- The taxpayer wants to restrict the distribution of the payment to a specific obligation. In this situation, specify a Match Type of "obligation ID" and a Match Value of the respective obligation ID.

Match Type and Match Value are gray after the payment is frozen.

If the payment is linked to an Account ID that belongs to an account type that is used for non tax agency payments, the following fields appear (note, these fields are gray after the payment is frozen):

- Name is the name of the person remitting the payment.

- Reference Number is the reference number of the item being paid (e.g., the property tax reference number).

- Comments are used to describe anything unusual about the non tax agency payment.

The contents of the Payment Segments section depends on the number of payment segments linked to the payment. If more than 25 payment segments exist, a message appears that allows you to navigate to Payment - Payment Segments where you can view the payment segments (this tab page has special functionality that allows you to define which payment segments should be displayed). If 25 or fewer payment segments exist, the grid contains information about each payment segment:

- Location is the address of the obligation's main premise.

- Click the go to button to transfer to view the financial transaction related to the payment segment. This is only available after the payment has been frozen.

- Obligation Information contains basic information about the obligation.

- Distributed Amt is the amount of the obligation's debt relieved by the payment.

The following information appears at the bottom of the page:

- Payment Amount is the amount of the payment.

- Distributed Amount is the sum of the payment segments linked to the payment.

- The Difference between the Payment Amount and the Distributed Amount appears if it is non-zero.

- Billed Amount is the amount of the bill preceding the payment date.

- Delinquent Amount is the amount of the taxpayer's debt that was due on / before the prior bill's due date.

- Current Balance is the account's current balance.

Refer to Payment Action Codes for information about the action buttons on this page.

Payment - Pay Segments

You can use this page to view all or selected payment segments linked to a payment.

Open Menu > Payments > Payments and navigate to the Pay Segments tab to view this information.

CAUTION:

Most payments are maintained using the Payment Event page. The transaction described below is typically only used to view a payment's payment segments.

Note:

If the payment has more than 25 payment segments, the search criteria are intentionally left blank in order to avoid retrieving all payment segments (with the resultant slow response times). You must therefore use the Obligation Filter to define the type of payment segments that should be retrieved. See the Description of page below for more information about this page's search criteria.

Description of page

Payment Info contains a concatenation of important information about the payment.

Payment ID is the system-assigned unique identifier of the payment.

Payment Event ID is the system-assigned unique identifier of the payment event. The adjacent info contains a concatenation of the payment date, amount, and the name of the main taxpayer on the account that remits the event's tender. If multiple tenders exist, the taxpayer's name is not displayed. A warning may also be displayed. The possible warnings are Unfrozen Payments and The Payment Event is unbalanced.

Payment(s) contains the total number and value of payments linked to the payment event.

Tender(s) contains the total number and value of tenders linked to the payment event.

Note:

If the payment has more than 25 payment segments, the search criteria are intentionally left blank in order to avoid retrieving all payment segments (with the resultant slow response times). You must therefore use the obligation Filter to define the type of payment segments that should be retrieved.

Use the Obligation Filter to define the types of obligations whose payment segments appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict payment segments based on obligation attributes.

- Obligation Type. Use this option to restrict payment segments to those whose obligations are linked to a given Division and Obligation Type.

Don't forget to click the search button after changing the Obligation Filter.

The grid that follows contains the payment segments that match your search criteria. The following information appears in the grid:

- The Location column contains the characteristic location associated with the payment segment's obligation. Refer to Maintaining Locations for more information about this location.

- Click the go to button to transfer to view the financial transaction related to the payment segment. This is only available after the payment has been frozen.

- Obligation Information contains summary information about the obligation.

- Distributed Amt is the amount of the obligation's debt relieved by the distribution.

- Adjustment ID is displayed if there is an adjustment associated with the payment.

The following information appears at the bottom of the page:

- Payment Amount is the amount of the payment.

- Distributed Amount is the sum of the payment segments linked to the payment.

- The Difference between the Payment Amount and the Distributed Amount appears if it is non-zero.

- Billed Amount is the amount of the bill preceding the payment date.

- Delinquent Amount is the amount of the taxpayer's debt that was due on / before the prior bill's due date.

- Current Balance is the account's current balance.

Payment - Manual Distribution

You can use this page to view obligations linked to the payment's account and to manually distribute a payment amongst specific obligations.

Open this page using Menu > Payments > Payment and navigate to the Manual Distribution tan.

CAUTION:

Most payments are maintained using the Payment Event page. The transaction described below is typically only used to view a payment's payment segments and to manually distribute a payment amongst an account's obligations.

Note:

If the payment's account has more than 25 obligations, the search criteria are intentionally left blank in order to avoid retrieving all obligations (with the resultant slow response times). You must therefore use the Obligation Filter to define the type of obligations that should be retrieved. See the Description of page below for more information about this page's search criteria.

Description of page

Payment Info contains a concatenation of important information about the payment.

Payment ID is the system-assigned unique identifier of the payment.

Note:

If the payment's account has more than 25 obligations, the search criteria are intentionally left blank in order to avoid retrieving all obligations (with the resultant slow response times). You must therefore use the obligation Filter to define the type of obligations that should be retrieved.

Use the Obligation Filter to define the types of obligations that appear in the grid. The following options are available:

- All. Use this option if you want to view all obligations.

- Obligation Type. Use this option to restrict obligations to those linked to a given Division and Obligation Type.

Don't forget to click the search button after changing the Obligation Filter.

The grid that follows contains the obligations that match your search criteria. The following information appears in the grid:

- Location contains the characteristic location associated with the obligation.

- Obligation Information contains summary information about the obligation.

- Distributed Amt is the amount of the obligation's debt relieved by the payment. This field is gray after the payment is frozen.

- Billed Amt is the amount that was billed for the obligation on the bill preceding the payment date.

- Delinquent Amt is the amount of debt associated with financial transactions that appear on overdue bills.

- Current Balance is the amount currently owing for this obligation.

Note:

If the account being paid is an open item account, then an alternate grid is displayed. The alternate grid is designed to break down payable balances by individual bill and obligation. Both unpaid bill balances and new charges are displayed. After distribution, a separate match event will be created for each bill paid or partially paid.

The open item manual distribution grid will have the following columns:

- Bill Date

- Shows bill date if the row contains an account's unpaid bill.

- Shows 'New Charges' if the row contains an account's unbilled new charges.

- Shows 'Payment Segment' for the following conditions:

- Row is a pay segment of a cancelled payment.

- Row is a pay segment of an overpayment to the highest priority obligation or an excess credit obligation.

- Row is a pay segment of a balance forward payment distribution.

- Location Information contains the characteristic location associated with the obligation.

- Obligation Information contains summary information about the obligation.

- Distributed Amount

- You can enter an amount to distribute if the payment is non-frozen and non-cancelled, otherwise, this field is protected.

- Billed Amount

- The amount that was billed for the obligation on the row's bill. If the row does not represent a bill amount then this will be zero.

- Unpaid Amount

- This is determined by the "determine open-item bill amount" algorithm as defined on the installation option.

- This column will contain zero if:

- The row is linked to an open non-disputed match event with other bills' FTs on it. In this case, it is not possible to determine the bill amount.

- The row is linked to an open disputed match event.

For either grid, the following information appears at the bottom of the page:

- Payment Amount is the amount of the payment.

- Distributed Amount is the sum of the payment segments linked to the payment.

- The Difference between the Payment Amount and the Distributed Amount appears if it is non-zero.

- Billed Amount is the amount of the bill preceding the payment date.

- Delinquent Amount is the amount of the taxpayer's debt that was due on / before the prior bill's due date.

- Current Balance is the account's current balance.

Payment - Characteristics

To update payment characteristics, open Menu > Payments > Payment and navigate to the Characteristics tab.

Description of Page

The Characteristics collection contains information that describes miscellaneous information about the payment. The following fields display:

Characteristic Type

Indicate the type of characteristic.

Sequence

Controls the order in which characteristics of the same type are displayed.

Characteristic Value

Indicate the value of the characteristic.

Payment Action Codes

The topics that follow describe each of the actions that appear on the payment pages.

Next in This Section

- Distribute (A Payment)

- Redistribute (A Payment)

- Freeze (A Payment)

- Cancel (A Payment)

- Transfer (A Payment)

- Delete (A Payment)

Distribute (A Payment)

Clicking the Distribute button causes a payment to be distributed amongst the account's obligations. Refer to Distributing A Payment Amongst An Account's obligations for a description of how this is achieved.

This button is enabled if a payment is Incomplete, Error, or Freezable. Refer to Payment Lifecycle for more information about these status values.

If the payment is distributed appropriately, click the Freeze button to freeze the payment and its payment segments.

Redistribute (A Payment)

Clicking the Redistribute button causes a payment to be redistributed amongst the account's obligations. Refer to Distributing A Payment Amongst An Account's Obligations for a description of how this is achieved.

This button is enabled if a payment is Incomplete, Error, or Freezable. Refer to Payment Lifecycle for more information about these status values.

If the payment is distributed appropriately, click the Freeze button to freeze the payment and its payment segments.

Note:

This button is only available on the Payment - Main and Payment - Manual Distribution pages.

Freeze (A Payment)

Clicking the Freeze button causes a payment and its payment segments to become frozen. Refer to Payment Lifecycle for more information about freezing.

This button is enabled if the payment is Freezable.

Note:

If problems are detected after freezing. A payment may not be changed after it is frozen. All subsequent changes must occur by canceling the frozen payment and creating a new one.

Cancel (A Payment)

Clicking the Cancel button causes the payment and its payment segments to be canceled. Canceling a payment (as opposed to canceling a tender) is typically only done if the original distribution was frozen and it's incorrect.

This button is enabled if the payment is Frozen. Refer to Payment Lifecycle for more information about these status values.

Transfer (A Payment)

The Transfer button is enabled if the payment is Frozen. Refer to Payment Lifecycle for more information about these status values.

If the payment being transferred was created using payment event distribution rule(s), the payment transfer should also be done using the distribution rules method. Hence, a different dialog opens when you click Transfer based on whether the payment's payment event is associated with at least one distribution detail or not.

Next in This Section

- Transfer Payment (No Distribution Details Exist)

- Transfer Payment (Distribution Details Exist)

Transfer Payment (No Distribution Details Exist)

Payment transfer causes the payment and its payment segments to be canceled and a new payment to be created. Transferring a payment is typically only done if the original distribution was targeted at the wrong account but all tender information for the pay event is correct. Unlike the payment event transfer, transferring a single payment does not affect the pay event's tender information.

You must specify the following parameters in order to transfer a payment:

- Account ID is the account to which the payment should be transferred.

- Cancel Reason defines why you are performing the transfer.

- Match Type and Match Value are defaulted based on their values for the payment event that you are transferring. If necessary, modify the values appropriately for the account to which you are transferring the payment event. Match Type and Match Value are used for an account that belongs to an open item account type or to restrict the distribution of the payment to a specific obligation. Refer to Payment Event - Main for more information.

- Turn on Freeze Payment if the transferred payment should be frozen automatically. You may want to leave this turned off if you want to examine the payment distribution before freezing the payment.

- Non Tax Agency Name, Reference Number, and Non Tax Agency Comments appear if the Account ID belongs to an account type that is used for non tax agency payments. Refer to Setting Up Account Types for more information.

Clicking OK causes the following to take place:

- The original payment and its segments are cancelled.

- A new payment is added for the transfer to account.

- The payment is distributed amongst the new account's obligations.

- If so designated, the new payment is frozen.

- The payment characteristics associated with the original payment are copied to the new payment.

Transfer Payment (Distribution Details Exist)

Payment transfer causes the payment to be canceled and new payment(s) to be created using new payment event distribution rule(s). Transferring a payment is typically done when a payment event has multiple payments and one or more payments have been assigned to the wrong obligation. Each of the incorrectly directed payments can be transferred to the correct obligation(s) using this dialog.

Total Amount is the total payment amount to transfer from.

You must specify the following parameters in order to transfer a payment:

- Distribution Rule is the obligation to which the payment should be transferred.

- Rule Value is the value associated with the payment and expected by the distribution rule.

- Amount is the payment amount.

- Cancel Reason defines why you are performing the transfer.

Clicking OK causes the following to take place:

- The payment associated with the original account is canceled.

- The new set of distribution details is processed, creating new payment(s) for the transfer-to obligation(s).

- The new set of distribution details is added to the payment event. The original distribution details are kept.

Note: Distribution rule entries can have a zero amount. Refer to Rule Value Can Capture Additional Information for more information about how to use distribution details to capture additional payment related information.

Note: Determine Tender Account. This dialog does not call the Determine Tender Account algorithm defined on distribution rule as this action does not rebuild the payment tender collection.

Delete (A Payment)

The Delete button deletes a payment. This button is enabled if the payment is Incomplete, Error, or Freezable.

How To

The topics in this section describe how to perform common payment maintenance functions.

Next in This Section

- How To Add A New Payment Event

- How To Cash A Check

- How To Allocate The Tender Amount To Multiple Accounts

- How To Print Receipts And Endorsements

- How To Cancel A Tender

- How To Transfer A Payment From One Account To Another

- How To Distribute A Payment To A Specific obligation

- How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under)

How To Add A New Payment Event

There are several ways to add a new event:

- You can use Payment Quick Add to quickly add one or more payment events. You'd use this approach to add simple payments where no manual intervention is required. By "simple payment" we mean:

- The account is both the tendering account and the account whose debt is being relieved by the payment

- The payment date is the current date

- The payment should be distributed amongst the account's obligations using standard distribution logic

- If applicable to your business practice, you can use Payment Event Quick Add to quickly add one or more payment events using distribution rules.

- You can use Payment Event Maintenance to add a payment event. You would use this approach if multiple forms of payment are remitted (e.g., cash and a check) or if there are multiple payors and/or payees linked to the payment event.

Note: By default the system opens the Payment Event - Add Dialog when you navigate to this page in add mode. If you have opted to always use the payment event distribution rules method as your default method, the Payment Event Quick Add (Single Payment Event) page appears instead. Refer to these pages for more information.

How To Cash A Check

If you allow taxpayers to cash checks, you'll have a payment event with two tenders:

- The first tender contains information about the check.

- The second tender contains information about the cash refund (the tender amount is a negative amount equal to the amount of the check).

The interesting aspect of this payment event is that it has no payments because the sum of the tenders is zero.

We start this explanation in the middle of How To Add A New Payment Event.

In the Payment Event Add dialog, be sure to select Do Not Distribute before clicking OK.

- On the Main page, click - to remove the payment (cashing a check is a payment event with no payments).

- Transfer to the Payment Event, Tenders page.

- Insert a row in the tender scroll (click the + button) for the cash refund tender. In this row enter a tender type of "cash" and a tender amount of negative the check amount.

- Save the event (note there is nothing to distribute or freeze).

How To Allocate The Tender Amount To Multiple Accounts

When you add a payment event, the system automatically creates a single payment for the account that remitted the funds. If someone is remitting funds for someone other than themselves, you must change/add payments. This section describes how to do this.

Note:

This section assumes you chose to add the payment event using the Payment Event - Add Dialog. Refer to How To Add A New Payment Event for the complete list of options.

In the Payment Event - Add Dialog, be sure to select Do Not Distribute before clicking OK.

Once on the payment event page, go to the Tenders tab and do the following:

- If the remitting account shouldn't have received any part of the payment, Remove it by clicking the - button. Alternatively, you can just change the account id to reflect the recipient.

- If multiple accounts receive the remitted funds, Insert one row in the payment scroll (click the + button) for each additional account.

- When the payment event is balanced, Save it. Then Distribute and Freeze the payment(s). Refer to Payment Event Actions for more information on these action buttons.

How To Print Receipts And Endorsements

The system can be configured to allow you to endorse checks and print receipts using special cashiering station printers. This section describes the print options available.

Note:

These options are only available if they have been installed in your system. Installing these options are a delivery and installation issue and are not within the domain of this document.

The print functions are available from the Payment Event, Payment QuickAdd and Payment Event Quick Add transactions. Refer to those sections for more information.

Description of Page

Use the Endorse button to endorse checks using the cashier station printer. This is only enabled if one of the tender types indicates a check. If there were multiple checks, use the scroll buttons to select them. Feed the appropriate check in the printer and an endorsement message is printed on the back.

Use the Receipt button to print a receipt using the cashier station printer. Choose a Short or Long option. Use the Duplicate button to print a duplicate receipt - this prints the receipt with a "duplicate" label.

Use the Stub button to print special information in bill stub format (account, name, amount). Feed a slip of paper into the printer and the special stub information will be printed.

When you are finished, click Done; click Cancel to exit at any time.

Note:

The various text strings that are printed on the receipt and the endorsement are defined on Installation Options - Messages.

How To Cancel A Tender

If a tender is no longer valid (e.g., a check bounces), the tender must be canceled.

CAUTION:

This process only makes sense in the context of the page used to maintain tenders. Refer to Payment Event - Tenders for the details.

You navigate through the pages as follows:

1. Open the payment event - tenders page for the tender in question. Proceed to step 2.

2. Click the Cancel button . Proceed to step 3.

3. Before the system cancels the tender, you must specify the cancel reason.

Select a Cancel Reason to describe why the tender is being canceled. The system also needs to know which Bank Account To Charge the cancellation against. The system will default the Bank Code and Bank Account from the original bank information used when the tender was deposited. You can override them here.

When you click the OK button, the system cancels the tender and ALL payments linked to the event.

If the cancellation reason you supply is indicated as being "non-sufficient funds", the system will generate an adjustment to levy a NSF charge. Refer to Obligation Type - Main Information for more information.

If the tender is linked to an auto pay staging record, the cancellation reason you supply must be one that allows cancellation of activated auto pays.

Note:

When non-canceled tenders are still linked to the event. If there are multiple tenders linked to the payment event, you must either add new payment(s) that equal the sum of the event's non-canceled tenders or cancel the remaining tenders.

Note:

Cancellation after cash back. If a taxpayer tenders a check for $100, but only owes $80, the system will recommend returning $20 in cash to the taxpayer (assuming the tender type for checks allows overpayment). If the tender type for checks is not "like cash", a second tender is created for -$20 (the first tender is for $100). If the check subsequently bounces, both tenders must be cancelled.

How To Transfer A Payment From One Account To Another

If you need to transfer a payment amount from one account to another, you can use the Transfer button either on the payment event page or the payment page.

Fastpath:

Refer to Transferring A Payment for a description of when to use each option.

How To Distribute A Payment To A Specific obligation

When you click Distribute, the system uses the payment distribution algorithm defined on the account's account type to allocate the payment amongst the account's obligations. In this section, we describe how to override this distribution (e.g., when you need to allocate a payment to specific obligation(s)).

We start this explanation in the middle of How To Add A New Payment Event.

In the Payment Event Add dialog, be sure to select Do Not Distribute before clicking OK.

- Save the payment event (this also saves the payment and tender information).

- Use the Payment Amount context menu to transfer to the Manual Distribution page.

- Fill in the desired Distributed Amt for each obligation and save the payment.

- Click Freeze to freeze the payment when the amount distributed is equal to the payment amount.

How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under)

In order to balance a tender control that is out-of-balance, you must create a tender for an account associated with your company.

Note:

The over / under account. Your organization must set up a company-use account with an obligation whose obligation type references the over/under distribution code. This account should be linked to the person ID associated with company usage.

- If you have more money in the drawer than you have tenders, then you're "over". In this situation, you need to record a payment for the "over" amount. This will cause cash to be debited by the over amount, and the expense account associated with the account's obligation to be credited.

- If you have less money in the drawer than you have tenders, then you're "under". In this situation, you need to record a negative payment for the "under" amount. This will cause cash to be credited by the over amount, and the expense account associated with the account's obligation to be debited.

Note:

Important! You must determine the over/under amount for each tender type and then enter the respective over/under tender for the company-use account. For example, if you have more cash but fewer checks then you must enter two tenders for the company-use account (but you can do this on the same event). Check out the following table for an example:

Tender Type

Starting Balance

Tenders Received

Turn Ins

Actual Ending Balance (Entered by Cashier)

Expected Ending Balance

Over/Under Amount

Cash

$150.50

$5,000

$4,000

$1151

$1150.50

Over $0.50

Check

-

$1,000

$750

$249

$250

Under $1

In this example, you'd have to create two tenders for the company-use account:

- Tender type: Cash, Tender amount: +$0.50

- Tender type: Check, Tender amount: -$1.00

The sum of the tenders is -$0.50 and this is the amount that will be distributed to the company-use account's obligation (debit over/under expense, credit cash).

Note:

You must reopen the tender control. Before you can add an over/under tender to a tender control, you must re open the tender control (tenders may only be added to open tender controls).

Financial Transactions On A Payment

Open Payments, Financial Transactions On A Payment to view the financial transactions on a payment.

Note:

You can also open this page using the go to buttons that prefix the financial transaction summaries on Payment - Main.

Description of page

Payment Id is the system-assigned unique identifier of the payment.

Account ID is the payment's account.

The area beneath Account provides you with options that control which financial transactions appear in the grid. The following points describe the various options:

- Use the Obligation Filter to define the types of obligations whose financial transactions appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict financial transactions based on obligation attributes.

- Obligation ID. Use this option to restrict financial transactions to those of a specific obligation.

- Obligation Type. Use this option to restrict financial transactions to those whose obligations are linked to a given Division and Obligation Type.

Note: Optional information. The following details are only applicable implementations supporting the classic billing functionality.

- Use Match Event Status Filter to restrict the financial transactions based on the status of their match event. This filter only appears if the payment's account is an open-item taxpayer. The following options are available:

- All. This option shows all financial transactions.

- Balanced. This option shows all financial transactions whose match event is balanced.

- Disputed. This option shows all financial transactions whose match event is disputed.

- Unbalanced. This option shows all financial transactions whose match event is unbalanced.

- Unmatched. This option shows all financial transactions that are not linked to a match event.

CAUTION:

Don't forget to click the search button after changing the filters or after selecting a new Payment Id.

The grid that follows contains the financial transactions that match your search criteria. The following information is displayed:

- Match Event Status shows the status of the financial transaction's match event. This column only appears if the account is an open-item taxpayer.

- FT Type displays the type of financial transaction. Click on the hyperlink to transfer to Financial Transaction - Main. On this page, you can change certain aspects of the FT in question.

- Accounting Date is the date the system uses to determine the financial transaction's accounting period in your general ledger.

- Current Amount contains the financial transaction's effect on the obligation's current balance.

- Payoff Amount contains the financial transaction's effect on the obligation's payoff balance. ThePayoff Amount will be dim if it equals the Current Amount.

- Show on Bill indicates if information about the financial transaction appears on the taxpayer's bill.

- Obligation Information contains a summary of the respective obligation.

- Financial Transaction ID is the system-assigned unique identifier of the financial transaction.

At the bottom of the page is a summary of the financial transactions that match the search criteria.

Payment History

The payment history page shows all payments that have been distributed to an account's obligations. Open this page using Menu > Payments > Account Payment History .

Description of Page

One row is displayed for every payment that has been distributed to an account's obligations. The payment date, amount, payment status and the tender source associated with the tender's tender control are displayed for each payment.

Note:

Tender Source typically contains the description of the cash drawer in which the payment was made or the remittance processor that processed the payment. Tender Source will be blank for automatic payments until they are interfaced to the financial institution. Refer to Downloading Automatic Payments for more information about interfacing automatic payments.

If you need to see more detailed information about the payment, click the Go To button to transfer to the payment event page.

Payment / Tender Search

This page allows you to look for payments and/or tenders using a combination of search criteria. Open this page using Menu > Payments > Payment / Tender Search Financial Query, Payment / Tender Search.

Description of Page

The top half of the page is where you enter the criteria used to search for payments and tenders.

Note:

Multiple search criteria may be specified. You can search for payments and tenders using a combination of search criteria. For example, if you enter both a Payment Account name of Brandon and a Payment Amount between 150 and 170; only those payments for taxpayers named Brandon whose amount is between 150 and 170 will be displayed.

CAUTION:

Try to be as specific as possible when entering search criteria. Why? Because entering open-ended search criteria may have a severe impact on response times. For example, if you know the payments you're looking for have a payment date sometime in January 2003 and the taxpayer's name is Brazil, John, then enter both of these criteria. If you also know the payment amount is between 150 and 170, enter these values too.

The following table describes each of the different search methods.

Search Method

Description

Search for

Use this field to define if you're searching for Payments, Tenders or both Payments and Tenders. The value entered in this field controls which of the remaining search methods are enabled.

Distribution Rule

Use this field if you're searching for a tender or a payment and know the distribution rule and value used to created it.

This section appears only if you have configured your system to allow the payment event distribution rules method to be used.

Payment Account

Use this field if you're searching for a payment and know the account ID or the name of any person linked to the account whose debt is relieved by the payment.

- If you know the payment's account ID, first choose Account in the adjacent dropdown and then and enter the account's ID. You must enter all of the account ID.

- If you know the name of any person linked to the account, first choose Person Name in the adjacent dropdown and then enter the person's name. You can enter all or part of the person's name (the more you enter, the faster the search will be). The name search is not case sensitive.

A search method of Person Name defaults.

If you leave the person name or ID blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Tender.

Payment Amount

Use this field if you're searching for a payment and know its amount.

- If you know the exact amount, first choose Equal To in the adjacent dropdown and then enter the amount.

- If you know the payment amount is between a given range of values, first choose Between and then enter the range of values.

A search method of Between defaults.

If you leave the amount(s) blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Tender.

Payor Account

Use this field if you're searching for a tender and know the account ID or the name of any person linked to the tendering account.

- If you know the tender's account ID, first choose Account in the adjacent dropdown and then and enter the account's ID. You must enter all of the account ID.

- If you know the name of any person linked to the tendering account, first choose Person Name in the adjacent dropdown and then enter the person's name. You can enter all or part of the person's name (the more you enter, the faster the search will be). The name search is not case sensitive.

A search method of Person Name defaults.

If you leave the person name or ID blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Payment.

Tender Amount

Use this field if you're searching for a tender and know its amount.

- If you know the exact amount, first choose Equal To in the adjacent dropdown and then enter the amount.

- If you know the tender amount is between a given range of values, first choose Between and then enter the range of values.

A search method of Between defaults.

If you leave the amount(s) blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Payment.

Tender Source

If you're searching for a tender and you know the source of the tender (e.g., the lockbox, cashier, etc.), enter the tender source code.

A search method of Equal To defaults.

If you leave the tender source blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Payment.

MICR ID

Use this field if you're searching for a tender and know its MICR (magnetic ink character recognition) ID.

- If you know the entire MICR ID, first choose Equal To in the adjacent dropdown and then and enter the entire MICR ID.

- If you know the first X characters of the MICR ID, first choose Like in the adjacent dropdown and then and enter the entire MICR ID.

A search method of Like defaults.

If you leave the MICR ID blank, the system ignores this search method.

These fields are protected if you've selected a Search for of Payment.

Payment Date

Use this field if you're searching for a tender or a payment and know its date.

- If you know the exact date, first choose Equal To in the adjacent dropdown and then enter the date.

- If you know the date is between a given range of values, first choose Between and then enter the date range.

A search method of Between defaults.

If you leave the date(s) blank, the system ignores this search method.

The system shows the total number of payments / tenders that satisfy your search results immediately below the grid.

The first group of payments / tenders is displayed in the grid at the bottom of the page. Different columns appear in the grid depending on the value of Search for.

- If you use a Search for of Payment, only payment-oriented columns appear in the grid.

- If you use a Search for of Tender, only tender-oriented columns appear in the grid.

- If you use a Search for of Payment and Tender, both payment-oriented and tender-oriented columns appear in the grid.

CAUTION:

If you use the Payment and Tender search method, and the resultant tenders / payments are linked to payment events that have multiple payments or tenders, multiple rows may be displayed for the payment event's tenders and payments. For example, if a tender with multiple payments is selected, a separate row will be displayed for every payment that matches your payment search criteria. If you don't specify any payment search criteria, a row will be displayed for every payment linked to the tender.

Payment Date

This contains the date of the payment event associated with the payment / tender. This column appears regardless of the value of Search for .

Payment Account Info

This contains a concatenation of important information about the account whose debt was relieved by the payment. This column does not appear if you use a Search for of Tender .

Payment Amount

This contains the amount of the payment. This column does not appear if you use a Search for of Tender .

Payment Status

This contains the status of the payment. Refer to Payment Lifecycle for more information. This column does not appear if you use a Search for of Tender .

Payment ID

This contains the unique identifier of the payment. This column does not appear if you use a Search for of Tender .

Payor Account Info

This contains a concatenation of important information about the account who tendered the payment. This column does not appear if you use a Search for of Payment .

Tender Amount

This contains the amount of the tender. This column does not appear if you use a Search for of Payment .

Tender Control ID

This contains the related tender control. This column does not appear if you use a Search for of Payment .

MICR ID

This contains the MICR (magnetic ink character recognition) ID of the tender. This column does not appear if you use a Search for of Payment .

Tender Status

This contains the status of the tender. Refer to Tender Lifecycle for more information. This column does not appear if you use a Search for of Payment .

Pay Tender ID

This contains the unique identifier of the tender. This column does not appear if you use a Search for of Payment .

Pay Event ID

This contains the unique identifier of the payment event.

Payment Event Exception

Unbalanced payment events cause a record to be written to the payment event exception table with a message indicating the nature of the error.

To view the messages associated with the exception records, schedule the TD-UNBAL background process. This process generates a To Do entry for every record in the payment event exception table.

Fastpath:

Refer to Unbalanced Payment Events for instructions describing how to correct an unbalanced payment event.

Payment Exception

When the system is unable to distribute a payment, a record to be written to the payment exception table with a message indicating the nature of the error.

To view the messages associated with the exception records, schedule the TD-PYERR background process. This process generates a To Do entry for every record in the payment exception table.

After correcting the cause of the error, drill into the Payment and attempt to redistribute it.

Maintaining Deposit Controls

Deposit controls exist to give you administrative control over your cash drawers (and all other tender sources) and the subsequent deposit of funds at banks.

Fastpath:

Refer to Tender Management and Workstation Cashiering for background information.

Note:

The system creates most deposit controls behind-the-scenes. Most deposit controls are created by the system when it processes tenders from your remittance processor and lock boxes. You should only have to access the deposit control pages if you record payments in cash drawers. For information about how the system creates deposit controls, refer to Managing Payments Interfaced From External Sources. Also note that the automatic payment activation process also creates tender and deposit controls. Refer to Activating Automatic Payments for more information.

Next in This Section

- The Lifecycle Of A Deposit Control

- Deposit Control - Main

- Deposit Control - Tender Control

- Deposit Control - Tender Deposit

- Deposit Control - Turn Ins

The Lifecycle Of A Deposit Control

The following diagram shows the possible lifecycle of a deposit control.

Open

A deposit control is initially created in the Open state. While in this state, you may add new deposits to it, change the deposit amount on its deposits, and transfer tender controls into and out of it.

Balancing In Progress

You change a deposit control's status to Balancing In Progress when you're ready to balance its contents. While in this state, you can change the deposit amount on its deposits and transfer tender controls out of it. If you need to add new deposits to it or transfer tender controls into it you must return it to the Open state.

Balanced

You change a deposit control's status to Balanced when the sum of its tender controls is consistent with the total of its deposits. While in this state, you cannot modify its deposits or its tender controls. If you need to make modifications, you must return it to the Open or Balancing In Progress state.

Note:

Background processes and state transition. When payments are interfaced from external sources, the system automatically creates a deposit control and links a tender control to it. When all payments have been successfully loaded, the system changes the state of the respective deposit control to Balanced.

Deposit Control - Main

The Main page contains core deposit control information. Open this page using Menu > Payments > Deposit Control.

Description of Page

Deposit Control contains a concatenation of the deposit control's creation date, tender source type, and status.

Deposit Control ID is the system-assigned, unique identifier of the deposit control.

User is the person who created the deposit control.

Create Date/Time is the date and time the deposit control was created.

Tender Source Type is the type of tender control that has been linked to the deposit control. Valid values are: Ad hoc, Auto Pay, Online Cashiering and Lockbox. The system uses this information to prevent tender controls from different sources from being included under the same deposit control. In other words, you can't mix automatic payment, cashiering and lockbox tenders under the same deposit control.

Currency Code is the currency in which the deposit control's tenders are denominated.

Note:

Default note. The currency code defaults from the installation record.

The summary information that follows contains a summary of the starting balance and the tenders that are linked to the tender control.

- Starting Balance is the sum of the starting balances from all tender controls linked to the deposit control.

- Total Tenders Amount is the sum of tenders from all tender controls linked to the deposit control.

- Total Tender Controls is the number and amount of tender controls linked to the deposit control.

- Total Tender Deposits is the number and amount of tender deposits linked to the deposit control.

- Expected Ending Balance is the Total Tender Control minus Total Tender Deposits.

- Ending Balance is the actual amount of money in the tender control. This amount must equal the Expected Ending Balance before the tender control can be marked as Balanced.

- Outstanding Over/Under is Ending Balance minus Expected Ending Balance.

Deposit Control Status shows the status of the deposit control. Valid values are Open, Balanced, and Balancing In Progress.

For more information, refer to The Lifecycle Of A Deposit Control.

The Balanced User ID and Balanced Date/Time are populated when the status is changed to Balanced.

Use Comments to describing anything unusual about the deposit control.

Deposit Control - Tender Control

The Tender Control page contains a row for every tender control linked to the deposit control. Open this page using Menu > Payments > Deposit Control and navigate to the Tender Control tab.

Description of Page

Deposit Control contains a concatenation of the deposit control's creation date, tender source type, and status.

Deposit Control ID is the system-assigned, unique identifier of the deposit control.

The grid that follows contains a row for every tender control linked to the deposit control. No information about the tender controls may be modified on this page. To view or modify tender control information, click the Go To button.

Deposit Control - Tender Deposit

The Tender Deposit tab page contains a row for every tender deposit linked to the deposit control. Open this page using Menu > Payments > Deposit Control and navigate to the Tender Deposit tab.

Description of Page

Deposit Control contains a concatenation of the deposit control's creation date, tender source type, and status.

Deposit Control ID is the system-assigned, unique identifier of the deposit control.

The Tender Deposit scroll that follows contains one row for every financial institution into which the tenders will be deposited. To insert a new row, click the + button and fill in the following fields:

- Tender Deposit ID is maintained by the system. When a deposit is being created, there is no ID number displayed. Once a deposit is entered and saved, the system generates an ID and displays it here.

- Deposit Amount contains the amount to be deposited at the bank. Currency Code is the currency in which the deposit is denominated.

- Reference ID contains the ID of the deposit (if any).

- Use Bank Code and Bank Account to define where the tenders will be deposited.

Deposit Control - Turn Ins

The Turn Ins page contains a row for every turn-in event linked to the deposit control. Open this page using Menu > Payments > Deposit Controls and navigate to the Turn Ins tab.

Fastpath:

Refer to Turn Ins for background information.

Description of Page

Deposit Control contains a concatenation of the deposit control's creation date, tender source type, and status.

Deposit Control ID is the system-assigned, unique identifier of the deposit control.

The turn-ins grid contains one row for every turn-in event associated with the deposit control. A turn-in event is created when moneys originally deposited in respect of a tender control are turned in to the tender control's deposit control. Turn-in events are created and maintained on the Tender Control - Turn Ins page. Refer to Turn Ins for background information. The following information is displayed in the grid:

- Turn In Status defines if it is a new turn in Awaiting approval or has been Approved by the operator who is responsible for the Deposit Control. Once the turn-in is Approved, this field becomes display-only.

- Tender Type is the type of tender that has been turned in. This is a display-only field.

- Turn In Amount is the amount of the Tender Type that has been turned in. This is a display-only field.

- Receipt Number is the ID of the receipt given to the person who turn-in the funds. This is a display-only field.

- Create Date/Time contains when the turn-in event was created. This is a display-only field.

Maintaining Tender Controls

Tender controls exist to give you administrative control over your cash drawers (and all other tender sources).

Fastpath:

Refer to Managing Your Cash Drawers for more information.

Note:

The system creates most tender controls behind-the-scenes. Most tender controls are created by the system when it processes tenders from the remittance processors and lock boxes. You should only have to access the tender control pages if you record payments in cash drawers. For information about how the system creates tender controls, refer to Managing Payments Interfaced From External Sources. Also note that the automatic payment activation process also creates tender and deposit controls. Refer to Activating Automatic Payments for more information.

Next in This Section

- The Lifecycle Of A Tender Control

- Tender Control - Main

- Tender Control - Tenders

- Tender Control - Turn Ins

- Tender Control - Exceptions

- Tender Control - Characteristics

The Lifecycle Of A Tender Control

The following diagram shows the possible lifecycle of a tender control.

Open

A tender control is initially created in the Open state. While in this state, you may add new tenders to it, change the tender amount on its tenders, and transfer tenders into and out of it.

Balancing In Progress

You change a tender control's status to Balancing In Progress when you're ready to balance its contents. While in this state, you can change the tender amount on its tenders and transfer tenders out of it. If you need to add new tenders to it or transfer tenders into it, you must return it to the Open state.

Balanced

You change a tender control's status to Balanced when the sum of its tenders is consistent with the ending balance in the drawer. While in this state, you cannot modify it or its tenders. If you need to make modifications, you must return it to the Open or Balancing In Progress state.

If the tender control is part of a Balanced deposit control, you may not change its status.

Note:

Background processes and state transition. When payments are interfaced from external sources, the system automatically creates a tender control and links tenders to it (one for each payment interfaced). When all payments have been successfully loaded, the system changes the state of the respective tender control to Balanced.

Tender Control - Main

The Main page contains core tender control information. This page is used to balance the tender control.

Open this page using Menu > Payments > Tender Control.

Note:

Searching For Tender Controls. When you use the Creation Date to search for tender controls, the system returns tender controls that are created on or before the date you specify. If the number of records returned exceeds the search limit (i.e. 300 records), only the records that do not exceed search limit are displayed. Therefore, you may need to specify an earlier creation date to find the record you are looking for. If you do not specify a creation date and search based on other criteria, the system uses the most recent date.

Fastpath:

Refer to Managing Your Cash Drawers, Turn Ins and Balancing By Tender Type for more information.

Description of Page

Tender Control contains a concatenation of the tender control's creation date, tender source, and status.

Tender Control ID is the system-assigned, unique identifier of the tender control.

Tender Source is the source of the tenders (e.g., cash drawer 22, lockbox 1 at Bank of America).

Deposit Control ID is the system-assigned, unique identifier of the deposit control that the tender control is part of. The deposit control's Currency Code is displayed below.

Fastpath:

For more information about deposit controls and tender controls, refer to Managing Your Cash Drawers.

Turn on All Users if any user may insert tenders into this tender control. Turn this switch off and specify the appropriate User ID if only a single user may insert tenders into this tender control.

Create Date/Time is the date and time the tender control was created.

The Starting Balance of the tender control is defaulted from the tender source. This may be overridden while the Tender Control Status is Open or Balancing in Progress.

The Tender Control Status shows the status of the tender control. The Balanced User ID and Balanced Date/Time are populated when the status is changed to Balanced.

Fastpath:

For more information, refer to The Lifecycle Of A Tender Control.

The Balance button is enabled when the Tender Control Status is Balancing in Progress. When this button is clicked, the system checks the following:

- All Turn-Ins have been Approved.

- The sum of all Ending Bal equals the sum of all Expected Ending Bal .

If the above conditions are true, the status of the tender control is changed to Balanced and all modifiable fields become protected.

The tenders grid contains a summary of the tenders linked to the tender control. One row is displayed for each tender type. Each row contains the number of tenders of this type and their total amount. In order to Balance the tender control, you must enter an appropriate Ending Balance for each Tender Type. Refer to Balancing By Tender Type for more information. The following information appears in the grid:

- Tender Type represents the type of tender (e.g., cash, credit card). This is a display-only field.

- Number of Tenders contains the total number of tenders of this type in the tender control. This is a display-only field and is calculated by the system by accumulating the tenders linked to the tender control.

- Tender Total Amount contains the total amount of tenders of this type in the tender control. This is a display-only field and is calculated by the system by accumulating the tenders linked to the tender control. Navigate to the Tenders page to see the individual tenders.

- Turn In Amount contains the total amount of turn-ins of this type. This is a display-only field and is calculated by the system by accumulating the turn-ins linked to the tender control. Navigate to the Turn Ins pages to see the individual turn ins.

- Starting Balance contains the starting balance of this type of turn in. This field is only populated on the row defined as the Starting Balance tender type on the Installation Record. This is a display-only field and is equal to the tender control's Starting Balance.

- Expected Ending Bal is the Starting Balance plus Tender Total Amount minus Turn In Amount for this type of tender.

- Ending Bal is the actual amount of money of this tender type. The cashier must enter this field in order to balance the tender control. This field is protected unless the Status of the tender control is Balancing In Progress. This amount must equal the Expected Ending Balance before the tender control can be marked as Balanced. Refer to How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under) for more information.

- Outstanding Over/Under is the difference between Expected Ending Bal and Ending Bal. This is a display-only field.

The summary information beneath the tender type grid contains a summary of the tenders that are linked to the tender control.

- Total Tender Amount is the total amount of all tenders linked to the tender control.

- Ending Balance is the actual amount of money in the tender control (as defined in the above grid).

- Expected Ending Balance is the expected amount of money in the tender control (as defined in the above grid).

- Outstanding Over/Under is Ending Balance minus Expected Ending Balance. If this amount is zero, the field is not displayed.

If the tender controls were created for a background process, such as the automatic payment extract, the following information is displayed:

- Batch Code is the batch code for which the tender control was created. This field only appears if it contains a value.

- Batch Number is the batch number for which the tender control was created. This field only appears if it contains a value.

Use Comments to describe anything unusual about the tender control (e.g., to explain why a large over/under amount was created).

Tender Control - Tenders

The Tenders page contains a row for every tender linked to the tender control. Open this page using Menu > Payments > Tender Control and navigate to the Tenders tab.

Description of Page

Tender Control contains a concatenation of the tender control's creation date, tender source, and status.

Tender Control ID is the system-assigned, unique identifier of the tender control.

This grid at the top of the page contains a row for every tender linked to the tender control. When first displayed, the grid is ordered by the Create Date/Time column. No information about the tenders may be modified. To view or modify tender information, click the Go To button.

The grid at the bottom of the page contains a summary by tender type of all tenders linked to the tender control.

Tender Control - Turn Ins

Every time you turn in funds to the deposit control that is associated with your tender control, you create a turn-in event using this page. Open this page using Menu > Payments > Tender Control and navigate to the Turn Ins tab.

Fastpath:

Refer to Managing Your Cash Drawers and Turn Ins for more information.

Description of Page

Tender Control contains a concatenation of the tender control's creation date, tender source, and status.

Tender Control ID is the system-assigned, unique identifier of the tender control.

The turn-ins grid contains one row for every turn-in event associated with the tender control. A turn-in event is created when moneys are physically transferred to the deposit control associated with the tender control. Turn-in events are approved on the Deposit Control - Turn Ins page. The following information is displayed in the grid:

- Turn In Status defines if the turn-in is Awaiting approval or has been Approved by the operator who is responsible for the Deposit Control. When a turn-in is first created, its status is Awaiting approval and the following fields should be defined. Once the turn-in is Approved by the user responsible for the deposit control associated with the tender control, all of the following fields become display-only and the turn-in event cannot be deleted.

- Tender Type is the type of tender that has been turned in. This field may only be modified when the Turn In Status is Awaiting approval.

- Turn In Amount is the amount of the Tender Type that has been turned in. This field may only be modified when the Turn In Status is Awaiting approval.

- Receipt Number is the ID of the receipt given to the person who turn-in the funds. This field may only be modified when the Turn In Status is Awaiting approval.

- Create Date/Time contains when the turn-in event was created. This is a display-only field.

Tender Control - Exceptions

This page contains an entry for every exception (i.e., error) associated with the tender control's payments and payment events. Open this page using Menu > Payments > Tender Control and navigate to the Exceptions tab.

Fastpath:

Refer to Exceptions for more information.

Description of Page

This page contains an entry for every exception (i.e., error) associated with the tender control's payments and payment events.

Tender Control - Characteristics

To update tender control characteristics, open Menu > Payments > Tender Control and navigate to the Characteristics tab.

Note: If your tender control is balanced, you cannot update tender control characteristics

Description of Page

The Characteristics collection contains information that describes miscellaneous information about the tender control. The following fields display:

- Characteristic Type indicates the type of characteristic.

- Sequence controls the order in which characteristics of the same type are displayed.

- Characteristic Value Indicate the value of the characteristic.

Interfacing Payments From External Sources

Most payments are NOT added by an operator using the Payment Event page. Rather, they are interfaced from an external source (e.g., a lock box or a remittance processor).

The base-package provides two interfaces to upload payments, each based on a different method of creating payment events.

Fastpath:

Refer to Distributing A Payment Event for more information about how payment event distribution is handled in the system.

The topics in this section describe how these payment interfaces work.

Next in This Section

- Interfacing Payments Using Distribution Rules

- Interfacing Payments Using Account Distribution

Interfacing Payments Using Distribution Rules

The topics in this section describe how the payment interface using distribution rules works.

Next in This Section

- Payment Event Upload

- Payment Event Upload Staging Maintenance

Payment Event Upload

The following diagram illustrates the processes involved in the uploading of payment events into the system using distribution details.

The topics in this section describe the overall procedure and each background process referenced above.

Next in This Section

- Payment Event Upload Overview

- Process X - Populate Payment Event Upload Staging

- The Lifecycle of a Payment Event Upload Staging Record

- Process C1-PEPL0 - Upload Payments (Step 1)

- Process C1-PEPL1 - Upload Payments (Step 2)

- Process C1-PEPL2 - Upload Payments (Step 3)

- Process C1-PEPL3 - Upload Payments (Step 4)

- To Do Entries for Exception

Payment Event Upload Overview

The payment event upload processes are designed to transform remittances from external sources into payment events, tenders and payments within the system, using information is uploaded into the payment event upload staging table.

The following topics highlight the main features of payment event upload.

Determining Distribution Rules

The upload process uses distribution rules to create payments for the target business entity within the system, which is most commonly an obligation. Each upload staging record must have a valid account, distribution rule and value in order for a payment to be created. However, determining the correct distribution rule and value from the available reference information may be a complex process. For example:

- The payment reference information may have multiple valid formats that can only be correctly identified by cross checking against existing system data.

- The payment may be processed prior to the creation of the target obligation, for instance when a payment is uploaded before the associated form is posted.

- A single payment may be remitted to cover multiple obligations, each with a separate payment reference value.

The first stage of upload processing provides the ability to examine the payment details in order to determine the appropriate target. It achieves this by executing a series of algorithms that are responsible for determining the appropriate account, distribution rule and value needed to create the payment. These algorithms are defined on the installation record. The plug in spot provides the ability to:

- Review all the details in the payment upload staging record.

- Add characteristic values to the staging record. These may be used capture information derived by the algorithms that should be stored with the payment for use in later processing.

- Split a single payment into multiple payments by adding additional staging records. Note that the system assumes that the algorithm is responsible for allocating the combined tender amount across the new payments.

- Indicate when the account, distribution rule and value have been determined so that no further algorithms are called.

Note that the algorithms for this plug in spot should not update the staging records directly. They should instead update the details passed from algorithm to algorithm in memory. The staging records are updated by the C1-PEPL0 process when algorithm execution is complete. The base algorithms use the data area C1-PayEvtDetermineDistProcData to read and update those details. Your implementation may extend this data area if your business rules require additional information to be passed between algorithms that does not map to one of the upload staging record fields.

It is possible that the Determine Distribution Rule algorithms are unable to identify the business entity for which the payment was intended. In this case, the system expects that one of the algorithms in this spot will be responsible for returning a distribution rule and value that allocate the payment to excess credit, if the account can be determined, or to general suspense otherwise. Base algorithms are provided for this purpose.

Fastpath: For more information about the first stage of upload processing refer to Process C1–PEPL0 — Upload Payments (Step 1) .

For more information about the Determine Distribution Rule algorithms refer to Installation Options — Algorithms

Creating Tender and Deposit Controls

Each payment event in the system must be linked to a tender control. The second stage of upload processing is responsible for grouping payments by source, transmission and tender type in order to link them to a unique tender and deposit control prior to creating the payments.

The second stage of processing is also responsible for validating the key fields needed to create payments, including tender type and currency code as well as the account and distribution rule details. Validation is deferred until this stage so that records may be uploaded from the source and reviewed without encountering system errors due to invalid foreign keys.

Fastpath: For more information about the second stage of upload processing refer to Process C1–PEPL1 — Upload Payments (Step 2).

Note: While it is not recommended, it is possible for your implementation to populate the account, distribution rule and value and staging record characteristics at upload time, in which case processing should start with the second stage.

Creating Payment Events, Tenders and Payments

The third stage of processing is responsible for creating the payment records. It creates a payment event and tender for each remittance then invokes the Create Payment algorithm for the associated distribution rule and value. The payment event creation is performed in a separate process, after the payor account has been determined, so that the process may be threaded by the account ID for performance reasons.

Fastpath: For more information about the third stage of upload processing refer to Process C1–PEPL2 — Upload Payments (Step 3).

Balancing Tender and Deposit Controls

The fourth and final stage of processing is responsible for simply setting the tender and deposit controls to balanced for each set of completed upload staging records.

Process X - Populate Payment Event Upload Staging

Process X refers to the mechanism used by your organization to populate the payment event upload staging table.

Payment Event Upload Staging Table

You must create a payment event upload staging record for each payment distribution detail to be uploaded into the system. The name of this table is CI_PEVT_DTL_ST. The following table describes each of its columns.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with an external source ID on one of the defined tender sources. Refer to Setting Up Tender Sources for more information.

EXT_TRANSMIT_ID

30

Y

A/N

This is the unique identifier of the transmission from the external source. This must be a unique value for each transmission from the source.

PEVT_DTL_SEQ

12

Y

N

Unique identifier of the detail record within the transmission. The C1-PEPL0 and C1-PEPL1 processes use this field to organize the parallel threads.

PEVT_STG_ST_FLG

4

Y

A/N

If your implementation uses the C1-PEPL0 process to determine account and distribution rule details, this must be set to C1UP (C1UP is the lookup value that corresponds with the Uploaded state).

If your implementation uses the C1-PEPL1 process as the first stage of the upload, this must be set to 10 (10 is the lookup value that corresponds with the Incomplete state)

DST_RULE_CD

12

Y

A/N

This must be a valid distribution rule. The distribution rule contains the set of algorithms designed to process the staging detail. The C1-PEPL0 process will populate this field by calling the Installation — Determine Distribution Rule algorithms.

DST_RULE_VALUE

254

Y

A/N

This must be a valid value for the characteristic type defined on the distribution rule. The C1-PEPL0 process will populate this field by calling the Installation — Determine Distribution Rule algorithms.

Note that if the value is a multi-part key, such as revenue period (calendar code + end date) the values should be entered separated by a semi-colon. For example: ANNUAL;2010-12-31

CURRENCY_CD

3

Y

A/N

This must be a valid currency code (this would be USD for United States dollars).

TENDER_AMT

13.2

Y

N

The amount tendered (i.e., the payment amount).

ACCOUNTING_DT

10

Y

Date

This is the payment date that should be used for accounting purposes. This should correspond with an open accounting period.

TENDER_TYPE_CD

4

Y

A/N

This must be a valid tender type. Refer to Setting Up Tender Types for more information.

CHECK_NBR

10

N

A/N

This is the check number on the payment.

MICR_ID

30

N

A/N

This is the MICR ID associated with the payment tender.

CUST_ID

15

N

A/N

This field may be used to record taxpayer information.

NAME1

40

N

A/N

This is the taxpayer name on the payment.

EXT_REFERENCE_ID

30

N

A/N

This field may be used to capture external information associated with the payment tender, such as a reference number that identifies an obligation or bill.

MATCH_TYPE_CD

8

N

A/N

See the description of the MATCH_VALUE field below.

MATCH_VALUE

30

N

A/N

MATCH_VALUE and MATCH_TYPE_CD are optional. They are available to be used for distribution rule algorithms that rely on this to target the payment in a certain way. If your distribution rule's create payment algorithm doesn't use this information it may be left blank.

If MATCH_TYPE_CD is specified, it must reference a valid Match Type.

Note that if your implementation uses classic billing and open item accounting these fields have specific significance. Refer to Payments And Match Events for more information.

TNDR_CTL_ID

10

N

A/N

Leave this column blank. It will be assigned by the system when it creates a tender control record.

ACCT_ID

10

N

A/N

This is the tender account. The C1-PEPL0 process will populate this field by calling the Installation — Determine Distribution Rule algorithms.

If left blank and your implementation does not use process C1-PEPL0, the C1-PEPL1 process will populate this field by calling the Determine Tender Account algorithm defined on the distribution rule.

Note that this Account ID is not necessarily unique as multiple staging details can reference the same tender account.

PAY_EVENT_ID

12

N

A/N

Leave this column blank. It will be assigned by the system when it creates a payment event record.

PEVT_PROCESS_ID

10

N

A/N

If left blank, the C1-PEPL0 process will set this field equal to the Tender Account ID concatenated with the payment event upload staging record sequence.

If left blank and your implementation does not use process C1-PEPL0, the C1-PEPL1 process will set this field equal to the Tender Account ID.

This field is used for grouping staging records and for organizing parallel threads (in the C1-PEPL2 process). Therefore, it is strongly encouraged that it bears a relationship to the tender account ID.

APAY_SRC_CD

12

N

A/N

This must be a valid auto pay source code.

EXT_ACCT_ID

50

N

A/N

This is the taxpayer's account number at the financial institution

EXPIRE_DT

10

N

Date

This field is only needed if the Tender Type indicates that an expiration date is necessary (e.g., for a credit card payment)

ENTITY_NAME

64

N

A/N

This is the taxpayer's name in the financial institution's system

PAY_DTLS

254

N

A/N

This field may be used to capture free-form text that was supplied with the payment by the payor or financial institution, if applicable

ROUTING_NBR

50

N

A/N

This is the routing number for the taxpayer's account at the financial institution

Payment Event Upload Staging Characteristics Table

The payment event upload staging table has a child table for characteristic records. The C1-PEPL0 process will populate this table with details returned by the Installation — Determine Distribution Rule algorithms, if applicable. It is designed to capture additional reference information to be stored with the payment in the system.

The name of this table is CI_PEVT_DTL_ST_CHAR. The following table describes each of its columns.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with the external source ID of the related payment event upload staging record.

EXT_TRANSMIT_ID

30

Y

A/N

This must correspond with the unique transmission identifier of the related payment event upload staging record.

PEVT_DTL_SEQ

12

Y

N

This must correspond with the unique sequence number of the related payment event upload staging record.

CHAR_TYPE_CD

8

Y

A/N

This must correspond with a characteristic type that is defined as valid for the Payment and Payment Event Upload Staging entities. Refer to Setting Up Characteristic Types & Their Values for more information.

SEQ_NUM

3

Y

N

This should be set to 10 unless you have multiple values for a given payment event upload staging record and characteristic type.

CHAR_VAL

16

N

A/N

Populate this field if your characteristic type is predefined.

ADHOC_CHAR_VAL

254

N

A/N

Populate this field if your characteristic type is ad-hoc or file location.

CHAR_VAL_FK1 - CHAR_VAL_FK5

50 each

N

A/N

Populate these fields if your characteristic type is foreign key reference. Up to five columns of 50 bytes each are provided to accommodate compound keys.

The Lifecycle of a Payment Event Upload Staging Record

The following diagram shows the possible lifecycle of a payment event upload staging record.

- Uploaded. A payment event staging record is initially created in uploaded state. The C1-PEPL0 process sets it to incomplete once it determines its tender account and distribution rule details.
Note that if your implementation chooses not to use the C1-PEPL0 process, payment event staging records should be created in incomplete state.

- Incomplete. The C1-PEPL1 process sets an incomplete record to pending once it links it to a tender control and determines its tender account, if not already populated by the C1-PEPL0 process.

- Pending. The C1-PEPL2 process sets a pending record to complete once all processing logic is executed and a payment event is linked to it.

- Complete. When processing of the staging record is complete the record is in the complete state. This is a final state.

- Error. A payment event staging record may be set to Error from Incomplete or Pending states by the C1-PEPL1 and C1-PEPL2 processes respectively.

- Audit. A payment event staging record may be set to Audit from the Uploaded state by the C1-PEPL0 process. This only occurs if the original staging record has been transformed into multiple staging records by one of the Determine Distribution Rule algorithms.

Fastpath:

Refer to To Do Entries Instead of Exceptions for more information on how To Do entries are used to capture processing errors.

Process C1-PEPL0 - Upload Payments (Step 1)

The batch process C1-PEPL0 refers to the first of four background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of the C1-PEPL0 process is to populate the tender account, distribution rule and distribution rule value and process ID fields on the upload staging records and transition the records from Uploaded to Incomplete.

Each staging record in uploaded status is processed as follows:

- The process invokes the algorithms on the Installation — Determine Distribution Rule plug in spot, passing the staging record and its characteristics, if populated.

- The Account ID, Distribution Rule and Distribution Rule Value fields on the record are populated with the values returned from the plug in spot.

- Any new or changed characteristic records returned by the plug in spot are updated on the staging record characteristics collection.

- The staging record is moved to incomplete state. If additional staging records are returned by the plug in spot, the original record is updated to the audit state and the new records are added in incomplete state.

- If blank, the staging record process ID is set to a value derived by concatenating the account ID with the staging record sequence number. Note that this has the effect of causing each staging record to be treated as a separate payment event by subsequent processing.

- If any error occurs, standard batch error handling applies. Note that the batch process will issue an error if the Account ID, Distribution Rule or Distribution Rule Value fields are not populated by the call to the plug in spot.

Note:

This process is designed to support execution in parallel threads based upon the sequence number portion of the staging table prime key.

Process C1-PEPL1 - Upload Payments (Step 2)

The batch process C1-PEPL1 refers to the second of four background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of this process is to transition the status of the staging records from Incomplete to Pending. The status of a staging record must remain Incomplete until:

- It is linked to a tender control.

- The Tender Account ID field is populated.

- The Pay Event Process ID field is populated.

This process creates new deposit and tender control records, and then updates the payment event upload staging records with the corresponding Tender Control ID.

The recommended approach for populating the Tender Account ID and Pay Event Process ID is via the C1-PEPL0 process which supports a flexible, algorithm driven method of determining the distribution rule details. If your implementation chooses not to use this process, C1-PEPL1 will perform the following extra steps:

- If the Tender Account ID field is left blank, the Determine Tender Account algorithm defined on the distribution rule is called and the returned account ID is posted on the staging record.

- If the Pay Event Process ID field is left blank, this field is set equal to the Tender Account ID.

The following diagram and the sections below describe at a high level the processing phases of the C1-PEPL1 background process.

Phase 1 - Create Tender Control

Note:

This step cannot be bounded by thread range but must execute across the entire population of staging details. Therefore this step in the process is designed so that all parallel threads attempt to execute it at the same time but only one thread succeeds to avoid creating duplicate tender controls.

This step creates all tender controls required by the upload records as follows:

- For each distinct tender source transmissions represented within the incomplete set of upload staging details a deposit control, a deposit tender and a tender control are created in an open state. Note that a deposit tender record is only created if the tender amount is not zero.

- If an error occurs at this stage

- A designated staging record for the transmission group (one is picked at random) is set to Error and a ToDo entry is created and linked to it to capture the error message that applies for the whole transmission group. Other records in the group remain incomplete.

- The process stops.

Group Error. This technique allows for an easier recovery from a setup error that may affect a large volume of records in a single transmission. Capturing the error only on a single designated record requires only this record to be set back to Incomplete once the setup issue is corrected. It is important to note that the transmission group is not processes if at least one of the records in the group is in Error status.

- Once a transmission group of records is fully processed, To Do cleanup processing takes place to complete To Do entries previously raised for its designated staging record.

Fastpath:

Refer to To Do Entries Instead of Exceptions for more information on how To Do entries are used to capture processing errors.

Phase 2 - Validate and Populate Key Fields

After all tender controls have been created the second step attempts to transition all incomplete records to the pending state.

Each incomplete staging record is processed as follows:

- If not yet associated with a tender control ID, the process looks for an Open tender control that matches the batch code, batch number and external source ID and links it to the staging record. An error is raised if a matching tender control is not found.

- The process verifies that the fields on the upload staging records that are needed for subsequent processing are populated and valid. This includes the distribution rule code and value, tender type and characteristic types and values.

- If no tender account has been assigned, the process executes the Determine Tender Account algorithm defined on the distribution rule and populates the record with the returned account ID. An error is raised if a tender account may not be determined.

- If not already populated, the Pay Event Process ID is set equal to the Tender Account ID. The C1-PEPL2 process uses this field to organize the parallel threads and to group multiple staging details into a single payment event.

- The staging record is moved to pending state.

- If any errors occur in the above steps, the record is set to Error and a To Do entry is created for the error message.

- If no error occurred, To Do cleanup processing takes place to complete To Do entries previously raised for the staging record.

Fastpath:

Refer to To Do Entries Instead of Exceptions for more information on how To Do entries are used to capture processing errors.

Note:

This step is designed to support execution in parallel threads based upon the sequence number portion of the staging table prime key.

Process C1-PEPL2 - Upload Payments (Step 3)

The batch process C1-PEPL2 refers to the third of four background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of the C1-PEPL2 process is to create payment events, payment tenders and payments and transition the corresponding staging records from Pending to Complete.

The following diagram and the section below describe at a high level the processing phases of the C1-PEPL2 background process.

Each distinct group of pending staging records associated with the same external source ID, external transmit ID, accounting date, and pay event process ID is processed as follows:

- A payment event is created for the group and stamped on each of its records.

- A payment tender is created for each distinct set of staging records having the same tender account, tender type and other tender information fields, except for the tender amount.

- The Create Payment algorithm is then called for each distinct group of staging records having the same tender account, distribution rule and rule value providing it with the total amount for the group.

- Any characteristic records associated with the distinct group of staging records used to create the payment are added to the payment characteristics collection.

Note:

The process expects the Create Payment algorithm to return the ID of the payment to which the characteristic records should be added. If the ID is blank, no payment characteristics will be created

- The staging record is moved to pending state.

- If any error occurs a designated staging record for the payment event group (one is picked at random) is set to Error and a To Do entry is created and linked to it to capture the error message that applies for the whole group. Other records in the group remain incomplete.

Group Error. This technique allows for an easier recovery from an error that affects all staging records for a single payment event. Capturing the error only on a single designated record requires only this record to be set back to pending once the issue is corrected. It is important to note that the whole set of records is not processes if at least one of the records in the group is in Error status.

- If no error occurred, To Do cleanup processing takes place to complete To Do entries previously raised for the designated staging record.

Fastpath:

Refer to To Do Entries Instead of Exceptions for more information on how To Do entries are used to capture processing errors.

Note:

This process is designed to support execution in parallel threads based upon the payment event process ID field.

Process C1-PEPL3 - Upload Payments (Step 4)

The batch process C1-PEPL3 refers to the last of four background processes that load the contents of the payment event upload staging records into the various payment tables.

The responsibility of the C1-PEPL3 process is to update the status of the related deposit and tender controls from open to balanced.

Each distinct tender control for which all associated staging records are in complete status is processed as follows:

- The tender control is set to balanced.

- The deposit control is set to balanced.

Note:

This process is designed to support execution in parallel threads based upon the Tender Control ID field.

To Do Entries for Exception

When staging records go into the Error state the C1-PEPL1 and C1-PEPL2 background processes create To Do entries and link them to the offending staging records.

Each process determines the To Do Type to use for reporting errors by looking for the To Do Type defined with this process as its creation process.

Payment Event Upload Staging Maintenance

The Payment Event Upload Staging maintenance page has three purposes:

- You can view historical payment event upload staging records associated with uploaded payments.

- You can correct payment event upload staging records that are in error.

- You can add new payment event upload staging records to be processed by the payment event upload batch processes.

The topics in this section describe this page.

Next in This Section

- Payment Event Upload Staging - Main

- Payment Event Upload Staging - Characteristics

Payment Event Upload Staging - Main

This page shows the details of a payment event upload staging record.

Fastpath: Refer to Populating The Payment Event Upload Staging Records for more information about this record.

Open this page using Menu > Payments > Payment Event Upload Staging .

Description of Page

External Source ID corresponds with an external source ID on one of your tender sources. This should be the unique ID of the source of the interfaced payments. Refer to Setting Up Tender Sources for more information.

External Transmit ID is the unique identifier of the transmission of payments from the external source. This must be a unique value for each transmission from the source.

Sequence is the identifier of the record within the transmission. The C1-PEPL0 and C1-PEPL1 processes use this field to organize the parallel threads.

Accounting Date is the payment date that should be used for accounting purposes.

Distribution Rule is the rule by which the payment detail is to be processed. A default distribution rule is displayed if you have set one.

Rule Value is a value associated with the payment and expected by the distribution rule. Note that if the value is a multi-part key, such as revenue period (calendar code + end date) the values should be entered separated by a semi-colon. For example: ANNUAL;2010-12-31

Match Type and Match Value are optional. They are available to be used for distribution rule algorithms that rely on this to target the payment in a certain way. If your distribution rule's create payment algorithm doesn't use this information it may be left blank.

Payment Details is an optional field. It may be used to capture free-form text that was supplied with the payment by the payor or financial institution, if applicable.

Payor Account ID is the tender account. If the field is not populated at upload time or by the C1-PEPL0 process using the Determine Distribution Rule algorithms, the C1-PEPL1 process will populate this field by calling the Determine Tender Account algorithm defined on the distribution rule.

Tender Amount is the amount tendered (i.e., the payment amount).

Currency Code is the currency of the tendered amount. This should be the same as currency defined on the tender source.

Tender Type defines the form of remittance (e.g., cash, check, etc.). Note that the Tender Type defaults from the installation record.

Check Number is the check number on the payment.

MICR ID is the value of the magnetic ink character recognition (MICR) line on the payment.

External Reference ID may be used to record external information associated with the payment tender.

Customer ID may be used to record additional taxpayer information.

Name is the taxpayer name as it appears in the uploaded tender.

Tender Control ID is the tender control associated with the payment. This field is should typically be left for the C1-PEPL1 process to populate.

If the Tender Type is associated with an automatic payment, the following details may apply:

- Auto Pay Source Code is the financial institution / credit card company that receives the automatic payment request.

- Bank Routing Number is the routing number for the taxpayer's account at the financial institution.

- External Account ID is the taxpayer's account number at the financial institution.

- Expires On is only needed if the Tender Type indicates that an expiration date is necessary (e.g., for a credit card payment).

- External Account Name is the taxpayer's name in the financial institution's system.

The system attempts to default automatic payment information from the account's auto pay option if the tender type is the same as the tender type on the account's auto pay source and if the auto pay option is effective on the payment date. If the system is unable to default information, you must specify the source of the funds and the taxpayer's account number / credit card number at the financial institution. The system will also attempt to default the bank routing number from the external source ID on the auto pay source code.

Pay Event Process ID is used to group multiple staging records into a single payment event. If your implementation uses the C1-PEPL0 process to determine account and distribution rule details, the process populates this with a value based on concatenating the Payor Account ID and the staging record sequence number. If your implementation chooses to bypass C1-PEPL0 and run C1-PEPL1 as the first of the upload processes, C1-PEPL1 sets this field equal to the Payor Account ID if the field has not already been populated when the staging record was created

Pay Event Staging Status shows the state of the staging record. Refer to The Lifecycle of a Payment Event Upload Staging for a state transition overview.

Payment Event ID is the system-assigned, unique identifier of the related payment event. The C1-PEPL2 process populates this field when it creates a payment event for the upload staging record. You can use this field to navigate to the payment event page.

If a staging record is in Error state then the error message associated with the corresponding To Do entry is displayed.

Payment Event Upload Staging - Characteristics

To view or update payment event upload staging characteristics, open Menu > Payments > Payment Event Upload Staging and navigate to the Characteristics tab.

Description of Page

The Characteristics collection contains information that describes reference information about the payment event upload staging record. The following fields display:

Characteristic Type

Indicate the type of characteristic.

Sequence

Controls the order in which characteristics of the same type are displayed.

Characteristic Value

Indicate the value of the characteristic.

Interfacing Payments Using Account Distribution

The topics in this section describe how the payment interface using the account based method of creating payment events works.

Next in This Section

- Populating The Payment Upload Staging Records

- PYUP-PRG - Purge Payment Upload Objects

- Maintaining Deposit Control Staging

- Payment Upload Staging

- Payment Upload Exception

Populating The Payment Upload Staging Records

The following diagram illustrates the processes involved in the uploading of payment into the system.

The topics in this section describe each background process referenced above.

Next in This Section

- Process X - Populate Payment Upload Staging

- Process PUPL - Upload Payments

Process X - Populate Payment Upload Staging

Process X refers to the mechanism used by your organization to populate the various staging tables (shown in the orange section of the following ERD).

The topics in this section describe each of these tables.

Deposit Control Staging

You must create a deposit control staging record for each batch of payments to be uploaded into the system. The name of this table is CI_DEP_CTL_ST. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with an external source ID on one of the defined tender sources. Refer to Setting Up Tender Sources for more information.

EXT_TRANSMIT_ID

30

Y

A/N

This is the unique identifier of the transmission from the external source. This must be a unique value for each transmission from the source.

DEP_CTL_STG_ST_FLG

2

Y

A/N

This must be set to 20 (20 is the lookup value that corresponds with the Pending state)

DEP_CTL_ID

10

N

N

Leave this column blank. It will be assigned by the system when it creates a deposit control record.

TRANSMIT_DTTM

15

Y

DateTime

Date and time that the file was transmitted.

CURRENCY_CD

3

Y

A/N

This must be a valid currency code (this would be USD for United States dollars).

TOT_TNDR_CTL_AMT

13.2

Y

N

This column must equal the sum of the payment amounts on the tender control staging records associated with this deposit control staging.

TOT_TNDR_CTL_CNT

10

Y

N

This column must equal the number of tender control staging records associated with this deposit control staging.

LAST_UPDATE_INST

10

N

N

This field is populated during the upload. It is the process scheduler instance ID of the process performing the upload.

You must create one or more Tender Control Staging for this deposit control staging record.

Tender Control Staging

You must create at least one tender control staging record for each batch of payments to be uploaded into the system. The name of this table is CI_TNDR_CTL_ST. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with the external source ID on the parent deposit control staging record.

EXT_TRANSMIT_ID

30

Y

A/N

This must correspond with the external transmission ID on the parent deposit control staging record.

EXT_BATCH_ID

30

Y

A/N

This is the unique identifier of the batch of payments in respect of the external transmission ID.

TNDR_CTL_STG_ST_FLG

2

Y

A/N

This must be set to 20 (20 is the translate value that corresponds with the Pending state)

TNDR_CTL_ID

10

N

N

Leave this column blank. It will be assigned by the system when it creates a tender control record.

TOT_TNDR_AMT

13.2

Y

N

This column must equal the sum of the payment amounts on the payment tender staging records associated with this tender control staging.

TOT_TNDR_CNT

10

Y

N

This column must equal the number of payment tender staging records associated with this tender control staging.

You must create one or more Payment Tender Staging records for this tender control staging record.

Payment Tender Staging

You must create at least one payment tender staging record for each payment associated with the tender control staging record. The name of this table is CI_PAY_TNDR_ST. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with the external source ID on the parent deposit control staging record.

EXT_TRANSMIT_ID

30

Y

A/N

This must correspond with the external transmission ID on the parent tender control staging record.

EXT_BATCH_ID

30

Y

A/N

This must correspond with the external batch ID on the parent tender control staging record.

EXT_REFERENCE_ID

30

Y

A/N

This is the unique identifier of the payment in respect of the external batch ID.

PAY_TND_STG_ST_FLG

2

Y

A/N

This must be set to 10 (10 is the translate value that corresponds with the Pending state)

PAY_TENDER_ID

12

N

N

Leave this column blank. It will be assigned by the system when it creates a tender record.

TENDER_AMT

13.2

Y

N

The amount tendered (i.e., the payment amount).

ACCOUNTING_DT

10

Y

Date

This is the date that should be used for accounting purposes. This should correspond with an open accounting period.

TENDER_TYPE_CD

4

Y

A/N

This must correspond with the prime key of one of your tender types. Refer to Setting Up Tender Types for more information.

CUST_ID

15

Y

A/N

This is the account ID or old account number of the taxpayer tendering the payment. If the system cannot find an account ID or old account number that matches this value, the account ID of the tender source's suspense obligation will be used on the corresponding tender and payment.

MICR_ID

30

N

A/N

This is the MICR ID associated with the payment.

NAME1

40

N

A/N

This is the taxpayer name on the payment.

CHECK_NBR

10

N

A/N

This is the check number on the payment.

Payment Advice Staging

You need only populate rows on this table if any of the following conditions apply:

- If you need to distribute a payment tender to an account other than that defined with the CUST_ID on the payment tender staging record, you must create a payment staging record. You may distribute a tender to multiple accounts by creating multiple payment staging records. Note, if you want to distribute the payment tender to the same account, you do NOT need a payment staging record.

- If you want to restrict a payment to a specific obligation, you must insert a row on this table to indicate the specific the obligation in question. You do this by populating MATCH_TYPE_CD with a value that indicates that you are paying for a specific obligation and MATCH_VALUE with the unique ID of the obligation.

- If you practice open-item accounting, you must insert a row on this table for each to indicate the open-item to which the payment should be matched. Note, because open-item taxpayer typically match payments to bills, you would populate MATCH_TYPE_CD with a value to indicate that you are matching by bill ID and MATCH_VALUE with the unique ID of the bill.

The name of this table is CI_PAY_ST. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

EXT_SOURCE_ID

30

Y

A/N

This must correspond with the external source ID on the parent payment tender staging record.

EXT_TRANSMIT_ID

30

Y

A/N

This must correspond with the external transmission ID on the parent payment tender staging record.

EXT_BATCH_ID

30

Y

A/N

This must correspond with the external batch ID on the parent payment tender staging record.

EXT_REFERENCE_ID

30

Y

A/N

This must correspond with the external reference ID on the parent payment tender staging record.

CUST_ID

15

Y

A/N

This is the account ID or old account number of the taxpayer to which the payment should be distributed. If the system cannot find an account ID or old account number that matches this value, the account ID of the payor is used on the corresponding payment. If the payor's account ID is invalid, the tender source's suspense obligation is used.

PAY_AMT

13.2

Y

N

The amount tendered (i.e., the payment amount).

MATCH_TYPE_CD

8

N

A/N

See the description of the MATCH_VALUE field below. Refer to Payments And Match Events for more information about the significance of this field.

MATCH_VALUE

30

N

A/N

MATCH_VALUE and MATCH_TYPE_CD are used in conjunction to indicate that the distribution of the payment should be restricted in some way (i.e., the standard payment distribution algorithm should not be used). MATCH_TYPE_CD indicates how the payment should be distributed (e.g., only distribute to a specific obligation), MATCH_VALUE contains the ID of the restriction (e.g., the obligation ID).

If MATCH_TYPE_CD is specified, it must reference a valid Match Type.

Process PUPL - Upload Payments

The batch process identified by the batch process ID PUPL refers to the background process that loads the contents of the various payment staging records into the various payment event tables. The tables that are populated by this process are shown in the left orange section of the following ERD (the right orange section are the staging tables populated by the process described above)

The topics in this section describe how these tables are populated.

Phase 1 - Create Deposit Control

The following points describe, at a high level, the first phase of the payment upload process:

- PUPL checks that the record counts and money totals of tender control stagings add up to the expected amount on deposit control staging. If not,

- PUPL sets the status of the deposit control staging to be Error. None of the tender controls within the deposit control will be processed until everything adds up. You can fix these on the Deposit Control Staging page.

- When PUPL runs next, it will recheck the totals on deposit control stagings that are in Error or Pending

- If the record and dollar amounts are clean,

- PUPL creates the corresponding deposit control

- PUPL sets the status of the deposit control staging to be In Progress

Phase 2 - Create Tender Control

The following points describe, at a high level, the second phase of the payment upload process:

- PUPL checks that record counts and money totals of payment tender staging(s) adds up to expected amount on tender control staging. If not,

- PUPL sets the status of the tender control staging to be Error. None of the tender controls within the deposit control will be processed until everything adds up for ALL tender controls. You can fix these on the Tender Control Staging page.

Note: The Deposit Control Staging record is not updated - its status is unchanged. Neither is the Pay Tender Staging record updated - its status also remains unchanged. Only the Tender Control Staging record is updated to be in Error.

- When PUPL runs next, it will recheck the totals of tender control stagings that are in Error or Pending.

- If the record and dollar amounts are clean,

- PUPL creates the corresponding tender control.

- PUPL sets the status of the tender control staging to be In Progress.

Phase 3 - Create Payment Events, Tenders, Payments and Payment Segments

At this point, all deposit control stagings and tender control stagings are in the state of In Progress. Next, PUPL starts the upload of payment tender staging and payment advice staging. The following points describe, at a high level, this phase of the payment upload process:

- If the payment tender staging record has a future accounting date, the processing for the record is skipped. This prevents uploaded payments from being created and subsequently frozen until their accounting date is reached. (Some external sources may provide advance notification of payments to be made in the future.) A skipped staging record remains in the Pending state until its accounting date is reached.

- PUPL checks money totals of payment advices (if any) adds up to expected amount on payment tender staging.

- If not, PUPL sets the payment tender staging's status to Error.

- Any errors are written to the Payment Upload Exception table. You can fix these errors on the Payment Upload Staging page and change the record's status back to Pending.

- When PUPL runs next, it will recheck the totals of the payment tender staging

- If payment tender staging record is clean:

- PUPL creates a corresponding payment event, tender, and payment.

- If the account on payment tender staging is wrong, the account on the corresponding tender will be the tender source's suspense obligation's account. Refer to Setting Up Tender Sources for more information. Refer to How To Transfer A Payment From One Account To Another for how to transfer to payment to the correct account.

- If the account on payment advice is wrong, the account on the corresponding payment will be the account on the payment tender.

- PUPL distributes the payment(s) amongst the account's obligations, and payment segments are created. Note, the payment could be in error if there are no obligation's for the account (as well as other reasons). Payments in error are written to the Payment Exceptions table.

- PUPL changes the payment tender staging's status to Complete.

- If all payment tender stagings are Complete:

- PUPL changes the tender control staging's status to Complete.

- PUPL changes the deposit control staging's status to Complete.

- If there are payment tender staging that are not Complete

- The status of the tender control staging will still be In progress.

- The status of the deposit control staging will still be In progress.

- PUPL will attempt to upload the offending payment tender staging records when it next runs.

PYUP-PRG - Purge Payment Upload Objects

Completed payment upload staging objects should be periodically purged from the system by executing the PYUP-PRG background process. This background process allows you to purge all Completed payment upload staging objects older than a given number of days.

We want to stress that there is no system constraint as to the number of Completed payment upload objects that may exist. You can retain these objects for as long as you desire. However we recommend that you periodically purge Completed payment upload objects as they exist only to satisfy auditing and reporting needs.

Maintaining Deposit Control Staging

The Deposit Control Staging page has three purposes:

- You can view historical deposit and tender control staging records associated with uploaded payments.

- You can correct deposit and tender control records that are in error.

- You can add deposit and tender control records to be uploaded by the payment upload background process.

The topics in this section describe this page.

Next in This Section

- Deposit Control Staging - Main

- Deposit Control Staging - Tender Control Staging

Deposit Control Staging - Main

This page shows the details of a deposit control staging record.

Fastpath:

Refer to Populating The Payment Upload Staging Records for more information about this record.

Open this page using Menu > Payments > Deposit Control Staging .

Description of Page

External Source ID corresponds with an external source ID on one of the your tender sources. This should be the unique ID of the source of the interfaced payments. Refer to Setting Up Tender Sources for more information.

External Transmit ID is the unique identifier of the transmission of payments from the external source. This must be a unique value for each transmission from the source.

Status shows the state of the deposit control staging records. Potential values are: Incomplete, Pending, In Progress, Partial Load, Complete, Error.

Deposit Control ID is the system-assigned, unique identifier of the related deposit control. This value is populated after the system creates a deposit control for the upload staging record.

Transmission Date/ Time are when the information was interfaced into the system.

Total Tender Controls must equal the number of tender control staging records associated with this deposit control staging.

Total Tender Control Amount must equal the sum of the payment amounts on the tender control staging records associated with this deposit control staging. The Currency Code related to the amount is adjacent.

Deposit Control Staging - Tender Control Staging

This page shows the details of a tender control staging record.

Fastpath:

Refer to Populating The Payment Upload Staging Records for more information about this record.

Open this page using Menu > Payments > Deposit Control Staging and navigate to the Tender Control Staging tab.

Description of Page

External Source ID is the external source ID on the parent deposit control staging record.

External Transmit ID is the external transmission ID on the parent deposit control staging record.

The grid that follows contains a row for every tender control staging record linked to the deposit control staging record. The following information is displayed.

External Batch ID

This is the unique identifier of the batch of payments in respect of the external transmission ID.

Status

This is the state of the tender control staging records. Potential values are: Pending , In Progress , Complete , Error .

Tender Control ID

This is the system-assigned, unique identifier of the related tender control. This value is populated after the system creates a tender control for the upload staging record.

Total Tenders Amount

This is the sum of the payment amounts on the payment staging records associated with this tender control staging.

Total Number Of Tenders

This is the number payment tender staging records associated with this tender control staging.

Payment Upload Staging

The Payment Upload Staging page has three purposes:

- You can view historical payment tender and payment advice staging records associated with uploaded payments.

- You can correct payment tender records that are in error.

- You can add new payment tender and payment advice staging records to be uploaded by the payment upload process.

The topics in this section describe this page.

Next in This Section

- Payment Upload Staging - Tender Detail

- Payment Upload Staging - Payment Advice

Payment Upload Staging - Tender Detail

This page shows the details of a payment tender staging record.

Fastpath:

Refer to Populating The Payment Upload Staging Records for more information about this record.

Open this page using Menu > Payments > Payment Upload Staging and navigate to the Tender Detail tab.

Description of Page

External Source ID this is the external source ID on the parent tender control staging record.

External Transmission ID is the external transmission ID on the parent tender control staging record.

External Batch ID is the external batch ID on the parent tender control staging record.

External Reference ID is the external source's unique identifier of the payment tender.

Customer ID is the account ID or old account number of the taxpayer tendering the payment. If the system cannot find an account ID or old account number that matches this value, the account ID of the tender source's suspense obligation will be used on the corresponding tender and payment.

The Tender Amount is the amount tendered (i.e., the payment amount).

Tender Type defines the type of tender. Refer to Setting Up Tender Types for more information.

MICR ID is the MICR ID associated with the tender.

Check Number is the check number on the payment.

Name is the taxpayer's name (as it appeared on the uploaded tender).

Accounting Date is the date that should be used for accounting purposes.

Pay Tender Staging Status shows the state of the tender control staging records. Potential values are: Pending, Complete, Error.

Payment Event ID is the system-assigned, unique identifier of the related payment event. This value is populated after the system creates a payment event for the upload staging record.

Payment Upload Staging - Payment Advice

If a tender was distributed to taxpayers other than that defined on the Tender Detail page, the taxpayers that the tender was distributed to are defined on this page. This page will not contain information if the tender is distributed to the tender detail's taxpayer.

Fastpath:

Refer to Populating The Payment Upload Staging Records for more information about this record.

Open this page using Menu > Payments > Payment Upload Staging and navigate to the Payment Advice tab.

Description of Page

External Source ID this is the external source ID on the parent tender control staging record.

External Transmission ID is the external transmission ID on the parent tender control staging record.

External Batch ID is the external batch ID on the parent tender control staging record.

External Reference ID is the external reference ID of the payment tender.

The grid that follows is only populated if the tender is distributed to taxpayer(s) other than the tendering taxpayer. The following information is displayed.

Customer ID

This is the account ID or the old account number of the taxpayer to which the payment should be distributed.

Customer Info

If the Customer ID is an account ID that exists in the system, the name of the primary person and the account type of the account are displayed here.

Payment Amount

This is the amount of the tender to be distributed to the taxpayer.

Match Type, Match Value

These fields are only used if the distribution of the payment should be restricted in some way (i.e., the standard payment distribution algorithm should not be used). Match Type indicates how the payment should be distributed (e.g., only distribute to a specific obligation), Match Value indicates the ID of the restriction (e.g., the obligation ID). Valid values of Match Type are obligation .

Payment Upload Exception

If errors are detected during the payment upload process, a record is written to the payment upload exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-PYUPL background process. This process generates a To Do entry for every record in the payment upload exception table.

You can fix this error using the Payment Upload Staging page and change the status of the record from Error to Pending. When the payment upload process next runs, it attempts to upload this record again.

Adjustments

In this section, we describe the use of Adjustments to affect an obligation's balance.

Next in This Section

- The Big Picture Of Adjustments

- Maintaining Adjustments

- Multiple Miscellaneous Adjustments

- Multiple P&I Adjustments

- How and When To Use An Adjustment

- Maintaining Adjustments Interfaced From External Sources

- Maintaining Adjustments (Legacy)

The Big Picture Of Adjustments

The topics in this section provide background information about a variety of adjustment issues.

Fastpath:

We strongly recommend familiarizing yourself with the topics described in The Financial Big Picture to fully appreciate the place of an adjustment in the system's financial architecture. In particular, refer to Setting Up Adjustment Types and Setting Up Adjustment Type Profiles.

Next in This Section

- Adjustments - Current Balance versus Payoff Balance

- The Lifecycle Of An Adjustment

- Transfer Adjustments

- Adjustments and Penalty and Interest

- Adjustment Amount

- Adjustment Type Controls Everything

- Adjustment Approval

- Accounts Payable

- An Adjustment May Affect More Than Just Taxpayer Balances

Adjustments - Current Balance versus Payoff Balance

Affecting how much a taxpayer owes involves changing an obligation's payoff balance and/or current balance by creating an adjustment. In this section we describe these two balances.

CAUTION:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

Next in This Section

- When Current Balance Equals Payoff Balance

- When Current Balance Differs From Payoff Balance

- Adjustment Type And Balances

When Current Balance Equals Payoff Balance

For most obligations, payoff balance and current balance are always the same (or in colloquial speech - the amount the taxpayer has been asked to pay equals what they really owe). In this situation, an adjustment is easy: both payoff balance and current balance are adjusted by the same value.

Let's run through a typical example. The values in the payoff balance and current balance columns reflect the amount due after the financial transaction has been applied (i.e., the running balance):

Date

Financial Transaction

Payoff Balance

Current Balance

1-Jan-09

Tax Assessment: $125

125

125

1-Jan-09

Payment: $150

-25

-25

1-Feb-09

Overpayment refund: $25

0

0

As you can see, payoff balance and current balance are always in sync.

When Current Balance Differs From Payoff Balance

For some obligations, payoff balance and current balance differ (or in colloquial speech the amount the taxpayer has been asked to pay differs from what they would owe if they wanted to payoff their account).

The product does not currently include any logic that causes the payoff balance to differ from the current balance, but an implementation can use this technique, for example for a loan.

- Payoff balance holds the payoff amount for the loan, which is the current balance (the billed loan amount), plus the principal balance (the unbilled loan amount) and any accrued interest charges.

- Current balance holds the amount the taxpayer owes in respect of the billed amount (the periodic payment amount).

Adjustment Type And Balances

When you create an adjustment, you must define its adjustment type. The adjustment type controls how payoff balance and current balance are affected by the adjustment amount.

You can only pick adjustment types that make sense for the obligation.

The various types of adjustments that may be linked to an obligation are controlled by the adjustment profiles defined on the obligation's obligation type.

Fastpath:

Refer to Adjustment Type Controls Everything for more information.

The Lifecycle Of An Adjustment

The following diagram shows the possible lifecycle of an adjustment.

Manually created adjustments are initially created in the Incomplete state. Adjustments in this state don't have a financial transaction. This means, you can change the amount at will.

Generate the adjustment from the maintenance page causes the adjustment to become Freezable. At this point a financial transaction is created for the adjustment. The financial transaction contains the adjustment's effect on the general ledger and on the taxpayer's payoff and current balances. If the adjustment amount is calculated the algorithm on the adjustment type's Generate Adjustment event controls how the adjustment's amount and calculation details are generated. If the adjustment is calculated, you must specify the calculation date, to use for calculations that are effective dated.

In the very rare situation when the system cannot generate the financial transaction because of inconsistent setup data, the adjustment is moved to the Error state. You may regenerate the financial transaction after correcting the source of the error. You may also delete such an adjustment.

Freezing the adjustment causes the adjustment and its financial transaction to be Frozen. While in this state only a few things about an adjustment may be changed:

- The effective date of the adjustment's FT.

- Whether the adjustment appears on a taxpayer's bill, if applicable.

- The accounting date used to derive the general ledger accounting period(s) to which the financial transaction is booked.

Note:

Automated adjustments may be created as frozen. If an adjustment is generated as a result of another process, such as form creation or penalty and interest calculation, the adjustment will be created in Frozen status.

Note:

Adjustments may require approval. If the adjustment type referenced on the adjustment has an approval profile, the user is not able to freeze an adjustment but rather must submit the adjustment for approval. Refer to The Big Picture of Adjustment Approvals for more information.

An adjustment may be Canceled to remove its financial effect from the system. Canceling an adjustment causes the generation of another financial transaction. This new financial transaction reverses the financial impact of the original adjustment. For bill oriented taxes, the impact of the cancellation may appear on the taxpayer's next bill. You may view both the original financial transaction and its cancellation on the Adjustment page.

Transfer Adjustments

A convenient mechanism exists to transfer moneys between two obligations. The net effect of such a request is the creation of two adjustments, each of which is linked to the other. Both adjustments are created together, frozen together, and posted to the GL together. This is useful because you can't create one side of the transfer and without the other. Refer to How To Create A Transfer Adjustment for more information.

Note:

Inter or Intra Account. It's important to be aware that the transfer can be inter or intra account (i.e., the accounts on the two adjustments may be different).

Adjustments and Penalty and Interest

If your organization calculates penalty and interest (P&I) on outstanding debt, creating adjustments will typically impact the penalty and interest calculations. Most such adjustments are created as part of another business process, such as posting a tax form, where bringing P&I up to date is part of the business process.

For various reasons, the base product does not provide functionality to bring P&I up to date when an adjustment is created manually via the adjustment page. If your organization requires the ability to create a manual adjustment and bring P&I up to date, a special business process should be designed to orchestrate this.

Fastpath:

Refer to Adjustments and Updating P&I for more information.

Adjustment Amount

An adjustment's amount may be positive, negative or zero:

- A positive amount causes the taxpayer's balance(s) to increase.

- A negative amount causes the taxpayer's balance(s) to decrease.

- A zero amount will not affect the taxpayer's balance(s). A zero amount is odd, but necessary when you need to use an adjustment to correct the GL distribution. Refer to How To Use An Adjustment To Change Amounts Booked In Your GL for more information.

When creating a manual adjustment, the adjustment amount may default based on configuration on the adjustment type. When an amount is defaulted, it may be overridden by a user.

Some adjustment types may also be configured to take the base amount and calculate additional charges once the user clicks Generate.

Adjustment Type Controls Everything

When you create an adjustment, you must define its adjustment type. The adjustment type contains the business rules that govern how its adjustments are managed by the system. Refer to Adjustment Types Define Business Rules for more information.

Adjustment Approval

If a user creates an adjustment and the related adjustment type is configured to require one or more levels of approval, the initiating user must submit the adjustment for approval. When an adjustment is submitted for approval, the system determines the necessary approval levels and notifies the first approver. The system freezes the adjustment when last approver approves the adjustment (if the adjustment's adjustment type allows it to be frozen prior to the completion of the next bill).

Fastpath:

Refer to The Big Picture of Adjustment Approvals for more information.

Accounts Payable

If the adjustment type is configured with an A/P Request Type, when the adjustment is frozen, appropriate information needed for the accounts payable interface are captured on the adjustment including the name and address to which the check should be issued.

Note: The information is actually captured on a separate ‘staging’ record linked to the adjustment, but is visible on the adjustment page.

This name is derived from the account's primary taxpayer:

- If this person has an override mailing name, the first line of the override mailing name is used.

- If this person does not have an override mailing name, the person's primary name is used.

The address is retrieved as described in Determining Address.

An Adjustment May Affect More Than Just Taxpayer Balances

Fastpath:

When an adjustment is frozen or cancelled, a taxpayer's current and payoff balances are affected. However, several other objects may be affected when such events occur. Refer to Obscure Things That Can Happen for more information.

Maintaining Adjustments

An adjustment is used to change the amount of debt stored on an obligation. The topics in this section describe the pages on which adjustments are maintained.

Fastpath:

For more information about adjustments, refer to The Big Picture Of Adjustments.

Note:

This section describes the adjustment maintenance pages using the portal / zone technology where the exact user interface behavior is dictated by an appropriate business object. If your implementation has chosen to use the original adjustment user interface, refer to Maintaining Adjustments (Legacy) .

Next in This Section

- Adjustment Query

- Adjustment Portal

Adjustment Query

Use the query portal to search for an adjustment. Once an adjustment is selected, you are brought to the maintenance portal to view and maintain the selected record.

Adjustment Portal

This page appears when viewing the detail of a specific adjustment.

Next in This Section

- Adjustment - Main

- Adjustment - Log

Adjustment - Main

The topics in this section describe the base-package zones that appear on this tab.

Adjustment Zone

The Adjustment zone contains display-only information about the Adjustment.

The information displayed in the zone is dictated by the business object linked to the adjustment's adjustment type. However, it is expected to include main information about the adjustment, including approval information, if applicable.

Please see the zone's help text for specific information about the data displayed in the adjustment.

Financial Details Zone

This zone displays information about the financial transaction(s) related to the adjustment.

Calculation Lines Zone

This zone displays the calculation lines related to the adjustment, if applicable.

Related Adjustments Zone

This zone is visible if the adjustment being displayed is considered an assessment (its financial transaction's Group FT ID matches the financial transaction's ID). It displays any other adjustments that refer to this adjustment's FT as its group FT ID.

Adjustment - Log

Navigate to the Log tab to view various logs related to the adjustment.

Adjustment Log

This zone displays log records related to the adjustment.

Adjustment Approval Log

This zone only displays if the adjustment is related to an approval request and there are log records related to the adjustment approval request.

Multiple Miscellaneous Adjustments

This page allows a user to create multiple adjustments or cancel existing adjustments for adjustment types whose adjustment type category is Manual Adjustment. Open this page using Menu > Accounting > Multiple Miscellaneous Adjustments

The topics in this section describe the base-package zones that appear on this tab.

Multiple Adjustments Zone

Select the Account and Obligation and optionally the Assessment that you would like to review details about or add adjustments for.

Click Display Allocation to view the detailed balance for the chosen obligation / assessment.

Click Add Adjustment to view existing manual adjustments and to add one or more adjustments for this obligation / assessment.

Existing Adjustments

This section appears if the obligation or assessment chosen has any existing manual miscellaneous adjustments.

- If no assessment is chosen, all the existing manual miscellaneous adjustments for the obligation are displayed with information about the related assessment, if applicable.

- If an assessment is chosen, only the existing manual miscellaneous adjustments for the selected assessment are shown.

Refer to the zone specific help text for more information about the data displayed in this section.

A user may select one or more manual miscellaneous adjustments to cancel at this time.

Add Adjustments

This section is used to created one or more manual miscellaneous adjustments for the obligation or assessment chosen. Note that if no assessment is chosen, the user has the option of indicating the assessment to link the adjustment to .If no assessment is selected, the manual miscellaneous adjustment is created as a special stand-alone assessment.

Refer to the zone specific help text for more information about the data required to create an adjustment.

Note: Adjustments created from this page are assigned the business object defined on the selected adjustment type. However, the page is only populating standard adjustment fields supported by the base product business objects. If your implementation defines business objects that capture additional required data about these types of adjustments, you must use the adjustment maintenance portal to create these adjustments.

Multiple P&I Adjustments

This page allows a user to create multiple adjustments for adjustment types that refer to the Manual P&I adjustment type category. Open this page using Menu > Accounting > Multiple P&I Adjustments

The topics in this section describe the base-package zones that appear on this tab.

Multiple P&I Adjustments Zone

Select the Account and Obligation and optionally the Assessment that you would like to review details about or add adjustments for.

Click Display Allocation to view the detailed balance for the chosen obligation / assessment.

Click Add Penalty to view existing manual P&I adjustments and display the details needed to add one or more manual P&I adjustments for this obligation / assessment

Existing Penalties

This section appears if the obligation or assessment chosen has any existing manual P&I adjustments.

- If no assessment is chosen, all the existing manual P&I adjustments for the obligation are displayed with information about the related assessment, if applicable.

- If an assessment is chosen, only the existing manual P&I adjustments for the selected assessment are shown.

Refer to the zone specific help text for more information about the data displayed in this section.

A user may select one or more manual P&I adjustments to cancel at this time.

Add Penalties

This section is used to created one or more manual P&I adjustments for the obligation or assessment chosen. Note that if no assessment is chosen, the user has the option of indicating the assessment to link the adjustment to. If no assessment is selected, the manual penalty adjustment is created as a special stand-alone assessment.

Refer to the zone specific help text for more information about the data required to create an adjustment.

Note: Adjustments created from this page are assigned the business object defined on the selected adjustment type. However, the page is only populating standard adjustment fields supported by the base product business objects. If your implementation defines business objects that capture additional required data about these types of adjustments, you must use the adjustment maintenance portal to create these adjustments.

How and When To Use An Adjustment

The topics in this section describe how to perform common adjustment maintenance functions.

Next in This Section

- How To Create A Transfer Adjustment

- How To Create A Generated Adjustment

- How To Cancel An A/P Adjustment After It Has Been Selected By A/P

- How To Use An Adjustment To Change The GL Distribution

How To Create A Transfer Adjustment

The following steps describe how to create a transfer adjustment.

Note:

You cannot use an adjustment type with a calculated amount for transfer adjustments.

To create a transfer adjustment using the Adjustment Portal:

- Specify the "transfer from" Account and Obligation.

- Specify an appropriate transfer Adjustment Type and click OK.

- The appropriate maintenance map is displayed. Specify the Amount and if desired, the Creation Reason.

- Indicate the "transfer to" Obligation and click Save

Note: Your specific implementation may define additional information required for a transfer adjustment.

- After saving, the adjustment display portal is shown with the details entered so far. Click Generate. In the resulting page populate the data further:

- Specify an Accounting Date and Adjustment Date. You may also specify the Effective Date.

- Indicate the Debt Category to use on the debit side of the transfer or leave it blank to have it default from the adjustment type.

- Indicate the Debt Category Priority for the credit side of the transfer if this adjustment should override the default debt category priority from the obligation type.

- Check FT Header to indicate if the adjustment FT will be used as the assessment header, otherwise you may specify a Group FT ID if the Adjustment should be associated with a specific assessment.

- Click Calculate.

- After generating, click Freeze to freeze the adjustments' financial transactions.

The following steps highlight some differences in the process of creating a transfer adjustment if your implementation is using the legacy Adjustment page.

- The Add dialogue brings the user to the main adjustment tab where the "transfer from" account, obligation may be specified along with the adjustment type and amount.

- Creation Reason is not available.

- "Transfer to" obligation information is defined on a separate Transfer Adjustment tab.

- After specifying the transfer from and to information and the amount, click Generate to progress the adjustment.

How To Create A Generated Adjustment

The following steps describe how to create a generated adjustment.

To create a calculated adjustment using the Adjustment Portal:

- Specify the Account and Obligation.

- Specify an Adjustment Type that is configured to calculate the amount or build additional details and click OK.

- The appropriate maintenance map is displayed. Specify the Amount, if appropriate and if desired, the Creation Reason.

- Click Save

Note: Your specific implementation may define additional information required for the adjustment.

- After saving, the adjustment display portal is shown with the details entered so far. Click Generate. In the resulting page populate the data further:

- Specify an Accounting Date, Adjustment Date and Calculation Date. The Calculation Date that you supply is used by the generate adjustment algorithm for any calculations that are effective dated (e.g., rate version or rate factor value). You may also specify the Effective Date.

- If the adjustment is for a debit amount, indicate the Debt Category, or leave it blank to have it default from the adjustment type.

- If the adjustment is for a credit amount indicate the Debt Category Priority if this adjustment should override the default debt category priority from the obligation type.

- Check FT Header to indicate if the adjustment FT will be used as the assessment header, otherwise you may specify a Group FT ID if the Adjustment should be associated with a specific assessment.

- Click Calculate.

- Click Freeze to freeze the calculated transactions.

The following steps highlight some differences in the process of creating a transfer adjustment if your implementation is using the legacy Adjustment page.

- The Add dialogue brings the user to the main adjustment tab where the account, obligation may be specified along with the adjustment type and amount, if applicable.

- Creation Reason is not available.

- After specifying the basic adjustment information, click Generate to progress the adjustment.

How To Cancel An A/P Adjustment After It Has Been Selected By A/P

Adjustments that are interfaced to A/P (because A/P needs to cut a refund check) sometimes need to be canceled. You may cancel an A/P adjustment in the system while its A/P request is Not Selected. If the A/P request is Requested for Payment or Paid you must first cancel the payment in A/P. Canceling the payment in A/P changes the A/P request to Canceled. At this point, you can cancel the adjustment.

How To Use An Adjustment To Change The GL Distribution

Assume you have a frozen financial transaction that affected an incorrect GL distribution code. You have two ways to correct such a situation:

- You could cancel and recreate the original financial transaction (bill segment or adjustment), ensuring that the appropriate distribution code is affected by the new transaction.

- You could create an adjustment that does not impact the taxpayer's balance but does have a GL entry. This GL entry would reverse the effect of the original distribution code and have an offsetting entry to the correct distribution code. The following points explain how to do this:

- Choose an adjustment type that only impacts the GL (i.e., the adjustment's adjustment type has an FT algorithm that doesn't impact the taxpayer's current or payoff balance, it only impacts the GL).

- Enter an adjustment amount of zero.

- Generate the adjustment.

- Drill into the adjustment's financial transaction and enter two (or more) GL distribution rows that reflect the redistribution of the amounts.

- Return to the adjustment and freeze it.

Maintaining Adjustments Interfaced From External Sources

The topics in this section describe the pages provided in the system to view and maintain adjustments that are uploaded from an external source.

Fastpath: For technical information related to this topic, refer to Interfacing Adjustments from an External System.

Next in This Section

- Maintaining Adjustment Staging Control

- Maintaining Adjustment Upload Staging

Maintaining Adjustment Staging Control

Use this page to add, view or modify an adjustment staging control record. Open this page using Menu > Accounting > Adjustment Staging Control.

Description of Page

Adjustment Staging Control ID is the unique identifier of the adjustment staging control record.

Create Date/Time is when the adjustment staging control was created. This field is protected after the record is saved.

Number of Staging Records is the number of adjustment upload staging records that are linked to this adjustment staging control record.

Total Adjustment Amount is the total of adjustment amounts from the adjustment upload staging records that are linked to this adjustment staging control record.

Enter the Currency for the total adjustment amount on the adjustment staging control. This is also the currency of the adjustment amounts on the associated adjustment upload staging records.

Status shows the state of the adjustment staging control. Possible values are: Pending, In Progress, Complete, Error, and Held.

A Hold button appears adjacent to the status description if Status is Pending. Click this button to set the status to Held. The adjustment upload process will ignore staging controls in this state.

A Pend button appears adjacent to the status description if Status is either Held or Error. Click this button to set the status to Pending. An error message box also appears below the status description if Status is Error.

Use the Characteristics collection to capture miscellaneous information about an adjustment staging control.

Characteristic Type

The type of characteristic.

Characteristics Value

The value of the characteristic.

Note:

You can only choose characteristic types defined as permissible on an adjustment staging control. Refer to Setting Up Characteristic Types & Their Values for more information.

Maintaining Adjustment Upload Staging

Use this page to add, view or modify an adjustment upload staging record. Open this page using Menu > Accounting > Adjustment Upload Staging.

Description of Page

Adjustment Upload ID is the unique identifier of the adjustment upload staging record.

Adjustment Staging Control ID is the identifier of the adjustment staging control to which the adjustment upload staging is linked.

Indicate the Adjustment Type. This field is very important as it controls numerous aspects of the adjustment's impact on the taxpayer's balance and your general ledger.

Note:

You can only choose certain adjustment types. The obligation's obligation type has a collection of valid adjustment profiles. You may only reference adjustment types that are listed in one of the adjustment type profiles linked to the obligation type.

Enter an Adjustment Amount.

Creation Date is the date when the adjustment occurred. This will be the creation date on the uploaded adjustment. This field is protected after the record is saved.

Obligation indicates the obligation to which the adjustment was posted. If the adjustment is in suspense, the label shows Suspense Obligation instead.

Adjustment is a reference to the adjustment that got created from the upload.

Status shows the state of the adjustment upload staging. Possible values are: Pending, Complete, and Error.

If Status is Error, a Pend button appears adjacent to the status description. In addition, an error message box displays below the status description.

If the adjustment is in suspense, a message appears to indicate the condition and the Suspense Adjustment is shown. A different message appears when the suspense is resolved.

Use the Characteristics collection to keep miscellaneous information about an adjustment upload staging.

Characteristic Type

The type of characteristic.

Characteristics Value

The value of the characteristic.

Note:

Default Note. An adjustment upload staging's characteristics default from the adjustment type.

Maintaining Adjustments (Legacy)

This section describes the original adjustment maintenance pages provided with the product. They are only applicable for implementations that choose to use these pages rather than the current adjustment maintenance portal style pages and have run the appropriate script to re-enable these pages.

Next in This Section

- Adjustments - Main Information

- Adjustments - Characteristics

- Adjustments - Transfer Adjustment

- Adjustments - A/P Request

- Adjustments - Approval

- Financial - Adjustment Calculation Line Characteristics

Adjustments - Main Information

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How and When To Use An Adjustment for instructions describing how to perform common maintenance functions.

The Main page contains core adjustment information. Open this page using Menu > Accounting > Adjustment.

Description of Page

Adjustment Info contains a concatenation of important information about the adjustment.

Adjustment ID is the system-assigned, unique identifier of the adjustment.

Account ID is the account to which the adjustment is linked. The name of the main person on the account appears next to the account ID.

Use Obligation ID to define the obligation whose value needs to be adjusted. Basic information about the obligation appears adjacent.

Location is a display-only field that shows the location associated with the obligation, if any.

Indicate the Adjustment Type. This field is very important as it controls numerous aspects of the adjustment's impact on the taxpayer's balance and your general ledger. This field is gray after the adjustment is frozen.

Note:

You can only choose certain adjustment types. The obligation's obligation type has a collection of valid adjustment profiles. You may only reference adjustment types that are listed in one of the adjustment type profiles linked to the obligation type.

Enter the Amount of the adjustment. If the adjustment type is a generated adjustment, the Calculated Amount and Calculation Date are displayed. The values of the calculated amount and calculation date are displayed after the adjustment is generated. The calculated amount shows the result of the generate adjustment algorithm. The calculation date is specified when you click Generate for a generated adjustment type. It is used by the generate adjustment algorithm for any calculations that are effective dated (e.g., rate version or rate factor value).

Note:

Default note. The adjustment amount defaults based on the adjustment type. When you change the adjustment type, the amount changes accordingly. You may change the adjustment amount after it is defaulted.

You may not change an adjustment's Adjustment Status directly. Rather, you use the buttons in the Adjustment Actions area. Refer to The Lifecycle Of An Adjustment for the details.

If the status is Canceled, the Cancel Reason is displayed.

The Adjustment Date defines the date of the adjustment.

For adjustments that cover a period of time, the Through Date identifies the end of the adjustment period. For example, if penalty is calculated for a given month, the Adjustment Date and the Through Date are set to the start and end of the month, respectively.

Use the Comments to describe anything unusual about the adjustment.

If the adjustment is subject to approval, a message indicating such appears. Clicking this message navigates the user to the Approvals tab. Refer to The Big Picture of Adjustment Approvals for more information.

The financial transaction (FT) grid contains the financial transactions associated with the adjustment. It only contains information after the adjustment is frozen. If the adjustment is canceled, a second row appears showing the details of the cancellation FT.

- Financial Transaction ID is the system-assigned unique identifier of the FT. Click the go to button to transfer to the financial transaction. On this page you can change certain aspects of the FT in question.

- Effective Date is the date the FT starts aging.

- Accounting Date is the date the system uses to determine the FT's accounting period in your general ledger.

- Current Amount contains the FT's effect on the obligation's current balance.

- Payoff Amount contains the FT's effect on the obligation's payoff balance.

- Bill ID is the bill on which the FT appears (if it has been swept onto a bill). Click the adjacent go to button to transfer to the bill on which the FT appears. Note: an FT is linked to a bill the next time a bill is completed for the obligation's account.

- Group FT ID is the identifier of the main tax liability assessment's FT. Refer to Group Financial Transactions for more information.

The Calculation Lines grid contains the details of the calculations associated with a calculated adjustment. It only appears if the rate that calculated the adjustment amount created at least one calculation line. One row exists for every calculation involved in the process. This information is for audit purposes only and cannot be modified.

The following information is displayed in the grid:

- If at least one of the calculation lines has characteristics, Calc Line Char displays go to buttons, allowing you to go to characteristics that are linked to a specific adjustment calculation line. This column is only displayed if at least one of the calculation lines has characteristics.

- Sequence is the system-assigned unique identifier of the calculation detail row.

- Description on Bill is the information about the calculation line that appears on the taxpayer's bill.

- Calculated Amount is the calculated amount associated with the calculation line.

- The Print switch controls whether information about this line will print on the taxpayer's bill.

- The Appears in Summary switch defines if this line's amount also appears on a summary line. This switch plays a part at bill print time if this adjustment is included in a bill to the taxpayer. Those lines that appear in a summary print in the left dollar column, those that don't appear in a summary print in the right dollar column.

Calculation lines created by applying a rate have this switch turned on if the corresponding rate component is summarized on a summary rate component.

- Unit of Measure (UOM) is the unit of measure of the rate quantity priced on the calculation line.

- Time of Use (TOU) is the time-of-use code of the rate quantity priced on the calculation line.

- RQI is the rate quantity identifier of the rate quantity priced on the calculation line.

- Billable Rate Quantity is the rate quantity priced on the calculation line. This quantity differs from the measured consumption if there are RQ rules or register rules in effect.

- Base Amount is used by calculation lines (e.g. taxes) that are cross-referenced to other calculation lines and whose value(s), therefore, depend on the amounts calculated by those other lines. The Base Amount shows the total amount derived from the cross-referenced line(s) that the current line then used to calculate its billed amount.

- Rate Component Sequence refers to the sequence number of the rate component on the applicable rate version that was used to calculate the line.

- Measures Peak Qty is checked if the UOM priced on the calculation line is used to measure a peak quantity.

- Exempt Amount is not used at this time.

- Distribution Code is the distribution code associated with the calculation line. This distribution code is used to build the general ledger details on the bill segment's financial transaction.

- Description describes the characteristic value that was used when the line's amount was calculated. This information is only displayed if the line was calculated using a rate factor (because only rate factors use characteristic values). Refer to An Illustration Of A Rate Factor And Its Characteristics for more information.

Fastpath:

For more information, refer to Generated Adjustments.

The Adjustment Actions area contains buttons that you use to commit and cancel the adjustment's financial impact. The adjustment's status controls the button you can see and select. Refer to The Lifecycle Of An Adjustment for the details.

CAUTION:

Cancel may not be enabled. The cancel button is not enabled if the adjustment is linked to a bill that is written off.

Note:

Canceling An Accounts Payable (A/P) Adjustment. If you need to cancel an A/P adjustment (i.e. an adjustment of an adjustment type that has an A/P request type) that has already been extracted by A/P, refer to How To Cancel An A/P Adjustment After It's Been Selected By A/P.

Adjustments - Characteristics

You use this page to link additional information to the adjustment. Open using Menu > Accounting > Adjustment and navigate to the Characteristics tab.

Description of Page

The characteristics collection contains information that describes miscellaneous information about the adjustment.

Note:

Characteristic Types. You can only choose characteristic types defined on the adjustment's adjustment type.

The following fields display:

Characteristic Type

Indicate the type of characteristic.

Characteristic Value

Indicate the value of the characteristic.

Note:

Default Note. An adjustment's characteristics default from the adjustment type.

Adjustments - Transfer Adjustment

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How and When To Use An Adjustment for instructions describing how to perform common maintenance functions.

The Transfer Adjustment is used to define the reciprocal adjustment associated with a transfer adjustment (there are always two adjustments associated with a transfer). Open using Menu > Accounting > Adjustment and navigate to the Transfer Adjustment tab.

Description of Page

Adjustment Info contains a concatenation of the adjustment amount, adjustment type and status.

Adjustment ID is the system-assigned, unique identifier of the adjustment.

Account ID is the account to which the adjustment is linked. The name of the main person on the account appears next to the account ID.

Use Obligation ID to define the transfer to obligation. Basic information about the obligation appears adjacent.

Location is a display-only field that shows the location that associated with the obligation, if any.

The Adjustment Type and adjustment Amount from the first page are displayed. If you need to change either value, return to the first page.

Adjustment Status shows the status of the transfer to adjustment. If you need to change the adjustment's status, use the action buttons.

Use the Comments to describe anything unusual about the adjustment.

Transfer Adj ID is the system-assigned, unique identifier of the adjustment.

The Creation Date defines the date on which the adjustment was created.

The financial transaction grid contains the financial transactions associated with the adjustment. It only contains information after the adjustment is frozen. If the adjustment is canceled, a second row appears showing the details of the cancellation FT.

- Financial Transaction ID is the system-assigned unique identifier of the FT. Click the go to button to transfer to the financial transaction. On this page you can change certain aspects of the FT in question.

- Effective Date is the date the FT starts aging.

- Accounting Date is the date the system uses to determine the FT's accounting period in your general ledger.

- Current Amount contains the FT's effect on the obligation's current balance.

- Payoff Amount contains the FT's effect on the obligation's payoff balance.

- Bill ID is the bill on which the FT appears (if it has been swept onto a bill). Click the adjacent go to button to transfer to the bill on which the FT appears. Note: an FT is linked to a bill the next time a bill is completed for the account.

- Group FT ID is the identifier of the main tax liability assessment's FT. Refer to Group Financial Transactions for more information.

Adjustments - A/P Request

Fastpath: The Description of Page that appears below simply describes the fields on this page. Refer to How and When To Use An Adjustment for instructions describing how to perform common maintenance functions.

The A/P Request page contains information about adjustments used to refund money via an accounts payable (A/P) check request. This page is only relevant if:

- The adjustment's adjustment type references an A/P Request Type (i.e., it will be interfaced to your accounts payable system which will cut the check), and

- The adjustment is frozen.

Open this page using Menu > Accounting > Adjustment and navigate to the A/P Request tab.

Description of Page

Adjustment Info contains a concatenation of important information about the adjustment.

Adjustment ID is the system-assigned, unique identifier of the adjustment.

Account ID is the account to which the adjustment is linked.

Note: Adjustment type controls A/P check requests. The A/P Request information is populated when an adjustment used to refund money via an A/P check request is frozen. Whether or not an adjustment is interfaced to A/P is controlled by the adjustment's adjustment type. The adjustment type's A/P Request Type controls the payment date and the bank.

Name is the name printed on the check. Refer to Accounts Payable for information on how this is populated.

Payment Selection Status is the status of the check request. The values are:

- Not Selected for Payment before it's selected by A/P for payment

- Requested for Payment after it's selected by A/P

- Paid after it's paid by A/P

- Canceled if it's been canceled in A/P

- Hold if it's been held in A/P

Scheduled to Pay is the date on which the check is scheduled to be cut. This is equal to the adjustment date plus the Due Days on the adjustment type's A/P request type.

The following fields are provided in order to support a two-way interface with an A/P system. The delivered system does not have processes which update these fields.

- Payment Date is the date on which the check was cut in A/P. This field is only populated after A/P cuts the check.

- Paid Amount is the amount of the check. This field is only populated after A/P cuts the check.

- A/P Request ID is the system-assigned, unique identifier of the A/P check request.

- Payment Number is the system-assigned number of the payment in A/P (this number typically appears on the printed check). This field is only populated after A/P cuts the check.

The address information in the bottom frame is the address to which the check is mailed. After the adjustment is frozen, this information is automatically populated based on the address information for the person / account. Refer to Accounts Payable for information on how this is populated. This information is modifiable until the status is Paid.

Adjustments - Approval

This page only appears after an adjustment has started the approval process. Open this page using Menu > Accounting > Adjustment and navigate to the Approval tab.

Refer to The Big Picture of Adjustment Approvals for more information about the approval process.

The topics in this section describe the base-package zones that appear on the Approval Profile portal.

Adjustment Information

The Adjustment Information zone contains display-only information about the adjustment.

Approval Request

The Approval Request zone shows the current and future approvers of an adjustment. This zone only appears if the adjustment is in the approval process.

If the current user has approval authority, the following functions are available:

- Click the Approve button to approve the adjustment.

- Click the Reject button to reject the adjustment.

Approval Request Log

The Approval Request Log zone contains the history of the adjustment's approval.

Financial - Adjustment Calculation Line Characteristics

This page displays the characteristics that are linked to a specific adjustment calculation line. The information on this page is for audit purposes only and cannot be changed.

Open this page by clicking on the characteristics go to button on the calculation lines grid of the Adjustments - Main page.

Description of Page

Account is the account to which the adjustment is linked. The name of the main person on the account appears next to the account ID.

The Obligation is the obligation whose value needs to be adjusted. Basic information about the obligation appears adjacent.

Location shows the location that is associated with the obligation, if any.

The Adjustment Info displays information to identify the adjustment, including amount, type, and status.

Adjustment ID displays the identification of the adjustment, and Calc Line displays the calculation line with which the characteristics are associated.

The Description on Bill displays the description of the calculation line that appears on the taxpayer's bill.

The characteristics grid displays the Characteristic Type and the Characteristic Value records associated with the calculation line.

Fastpath:

For more information about characteristics, refer to Setting Up Characteristic Types and Their Values.

Financial Transactions

In this section, we describe the financial transactions generated as a result of your bills, payments and adjustments.

Next in This Section

- The Big Picture Of Financial Transactions

- Financial Transaction

- Account Financial History

- Account Bill / Payment History

- Obligation Financial History

- Obligation Cash Accounting Balance

- Balance Control

- Match Event

The Big Picture Of Financial Transactions

The topics in this section provide background information about a variety of financial transaction issues.

Fastpath:

We strongly recommend familiarizing yourself with the topics described in The Financial Big Picture to fully appreciate the system's financial architecture.

Next in This Section

- Bill Segment Financial Transactions

- Payment Segment Financial Transactions

- Adjustment Financial Transactions

- Financial Transactions and Effective Date

- Current Balance versus Payoff Balance

- The Source Of GL Accounts On Financial Transactions

- Obscure Things That Can Happen

Bill Segment Financial Transactions

A bill segment has a related financial transaction. The financial transaction contains the financial effects of the bill segment on the obligation's current and payoff balances and on the general ledger.

If a bill segment is cancelled, another financial transaction is created to reverse the original financial transaction. The cancellation financial transaction appears on the next bill produced for the account as a bill correction.

Fastpath:

For more information about bill segment financial transactions, refer to Bill Payment and Adjustment Details .

Payment Segment Financial Transactions

A payment segment has a related financial transaction. The financial transaction contains the financial effects of the payment segment on the obligation's current and payoff balances and on the general ledger.

If a payment segment is cancelled, another financial transaction is created to reverse the original financial transaction. The cancellation financial transaction appears on the next bill produced for the account as a negative payment.

Fastpath:

For more information about payment segment financial transactions, refer to Bill Payment and Adjustment Details .

Adjustment Financial Transactions

An adjustment has a related financial transaction. The financial transaction contains the financial effects of the adjustment on the obligation's debt and on the general ledger.

If the adjustment is eventually cancelled, another financial transaction will be linked to the adjustment to reverse its financial effect. The cancellation financial transaction appears on the next bill produced for the account as an adjustment.

Fastpath:

For more information about adjustment financial transactions, refer to Bills, Payments & Adjustments.

Financial Transactions and Effective Date

When a financial transaction's related bill segment / payment segment / adjustment is frozen, the financial transaction (FT) is also frozen. When an FT is frozen, it should be assigned an effective date. The effective date impacts the calculation of the obligation's detailed balance and subsequently it impacts penalty and interest.

Fastpath: Refer to Effective Date for more information.

Current Balance versus Payoff Balance

Fastpath:

For information about current and payoff balance in general, refer to Current Amount versus Payoff Amount.

The topics in this section describe when payoff amount differs from current amount for the various types of financial transactions.

Next in This Section

- Adjustments - Current Balance versus Payoff Balance

- Billing - Current Balance versus Payoff Balance

- Payment - Current Balance versus Payoff Balance

Adjustments - Current Balance versus Payoff Balance

Fastpath:

For information about current and payoff balance for adjustments, refer to Adjustments - Current Balance versus Payoff Balance.

Billing - Current Balance versus Payoff Balance

Fastpath:

For information about current and payoff balance for bill segments, refer to Billing - Current Balance versus Payoff Balance.

Payment - Current Balance versus Payoff Balance

Fastpath:

For information about current and payoff balance for payment segments, refer to Payment - Current Balance versus Payoff Balance.

The Source Of GL Accounts On Financial Transactions

Fastpath:

For information about the source of the distribution codes used to generate the GL accounts on the financial transactions, refer to The Source Of GL Accounts On Financial Transactions.

Obscure Things That Can Happen

The topics in this section provide information about obscure things that can happen when a financial transaction (FT) is frozen.

Next in This Section

- A Stopped Obligation May Be Closed

- A Closed Obligation May Be Reactivated

- A Reactivated Obligation May Be Closed

- One Or More Algorithms May Be Executed

A Stopped Obligation May Be Closed

If an FT causes a Stopped obligation's current and payoff balances to become zero, the system will attempt to close the obligation (i.e., change the obligation's status to Closed) when the obligation's account is next monitored for overdue debt.

Refer to When Is An Obligation Closed for more information.

A Closed Obligation May Be Reactivated

After an obligation is closed (i.e., after it's stopped and paid-in-full), it's possible for some types of financial transactions to be linked to the obligation. These financial transactions could cause the current and/or payoff balances to become non-zero. If this happens, the system reactivates the obligation (i.e., the obligation's status becomes reactivated).

In most circumstances, the creation of an new FT is a sufficient reason to reactivate an obligation. Some special obligation types may only be reactivated if additional conditions exist. The system provides a plug-in spot on the obligation type to evaluate those conditions and indicate if reactivation is required. Refer to Obligation Type - Algorithms for more details about the Close/Reactivate Criteria plug spot and the available algorithms.

When an obligation becomes reactivated, it becomes eligible for review by the overdue process monitor (when it next runs).

Financial events that can be linked to a closed obligation are:

- The cancellation of a bill segment

- The freezing of a payment segment

- The cancellation of a payment segment

- The freezing of an adjustment

- The cancellation of an adjustment

A Reactivated Obligation May Be Closed

After an obligation has been reactivated (refer to the previous section for how this happens), a financial transaction (or transactions) may be linked to it that will cause the current and payoff balance to return to zero. If this happens, the system will attempt to close the obligation (i.e., change the obligation's status to Closed) when the obligation's account is next monitored for overdue debt.

All types of financial transactions can be posted to a Reactivated obligation.

One Or More Algorithms May Be Executed

If the FT is linked to an obligation whose obligation type has Freeze Algorithms, these algorithms will be executed when the FT is frozen. In addition, FT freeze algorithms can also be defined on an account's account type.

Financial Transaction

Payment segments, adjustments and bill segment have a corresponding financial transaction. The financial transaction is created by the system when any of the source transactions is created. It contains the financial effects of its corresponding adjustment / bill segment / payment segment.

Fastpath:

For background information, refer to The Big Picture Of Financial Transactions.

The topics in the section describe the financial transaction page.

Next in This Section

- Financial Transaction - Main

- Financial Transaction - FT Process

- Financial Transaction - Characteristics

Financial Transaction - Main

Use Financial, Financial Transaction to update and maintain financial transaction information.

Note:

Navigating from source transactions. On the bill, payment, and adjustment maintenance pages, you can click the financial transaction go to button to transfer to this page.

Description of Page

Most of the attributes on this page are display-only. The following points describe the conditions under which certain fields may be modified:

- Accounting Date may be modified until the financial transaction (FT) is interfaced to the GL (i.e., until the GL Distribution Status is Distributed).

- New Charge may be modified unless the FT is linked to a bill.

- Show on Bill and Correction can be modified until the FT is frozen.

The remainder of this section defines each of the fields on the page.

FT Type is the type of financial transaction. Values are: Adjustment, Adjustment Cancellation, Bill Segment, Bill Segment Cancellation, Pay Segment, and Pay Segment Cancellation. Click the go to button to view the originating transaction on the adjustment, bill, or payment page.

FT ID is the system-assigned, unique identifier of the financial transaction.

Obligation ID is the system-assigned, unique identifier of the obligation to which the financial transaction is linked.

Bill ID is the system-assigned, unique identifier of the bill to which the financial transaction is linked. This field is only populated after the FT is swept onto a bill (and this happens when the next bill is completed for the FT's account).

Sibling ID is the system-assigned, unique identifier of the source transaction associated with the FT.

- If this FT is associated with a bill segment, Sibling ID contains the unique identifier of the bill segment.

- If this FT is associated with a payment segment, Sibling ID contains the unique identifier of the payment segment.

- If this FT is associated with an adjustment, Sibling ID contains the unique identifier of the adjustment.

Parent ID contains the following:

- If this FT is associated with a bill segment, Parent ID contains the unique identifier of the bill with which the bill segment is associated.

- If this FT is associated with a payment segment, Parent ID contains the unique identifier of the payment with which the payment segment is associated.

- If this FT is associated with an adjustment, Parent ID contains the adjustment type.

Group FT ID contains the unique identifier of the FT that represents the assessment header.

Create Date/Time are the date and time the FT was created.

Accounting Date is the accounting date that will be used by the general ledger to define the accounting period(s) into which the FT will be booked.

Division is the division associated with the FT. This comes from the division linked to the FT's obligation's obligation type.

GL Division is the GL division associated with the FT. This comes from the GL division linked to the FT's obligation's obligation type.

Show on Bill indicates if the FT will be shown on the taxpayer's bill. You should only turn this off for erroneous FTs that should not be shown to the taxpayer. For example, if you cancel / rebill a bill segment and you want to suppress the resultant FTs on the printed bill, turn this switch off.

New Charge indicates if the FT's charge only becomes effective when a subsequent process determines the FT's effective date and updates the record. This is only possible if your implementation has configured Effective Date to be optional using a feature configuration setting.

Not In Arrears indicates if the FT's financial impact has been canceled and therefore should not be considered for arrears purposes. This switch is turned on by the system when a FT's source transaction in canceled (both the original FT and the cancellation FT are marked as Not In Arrears).

Match Event ID is the system-assigned, unique identifier of the match event to which the financial transaction is linked. This field is only enabled for Open Item Accounts. Be aware that changing a financial transaction's match event can result in the balancing / unbalancing of the prior and newly referenced match events.

The Group FT ID is the identifier of the main tax liability assessment's FT. Refer to Group Financial Transactions for more information.

If this is a debit FT (an FT where the amount is greater than or equal to zero), the Debt Category identifies how this debit is categorized. If this is a credit FT, the debt category may be populated if the credit is associated with a certain category of debt. Refer to Debt Categories and their Priorities for more information about how this field is populated.

Note:

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.

Define a Debt Category Priority if this credit financial transaction has a special credit allocation rule that is different from the default rule defined on the obligation type. Refer to Debt Categories and their Priorities for more information.

Correction causes the FT to be summarized in the correction area of the bill-at-a-glance. This is set by the system automatically when a bill segment is cancelled / rebilled after its parent bill is completed (i.e., sent to the taxpayer).

Redundant indicates if the FT's financial impact is considered irrelevant. This only happens after an FT has reached an age that is no longer relevant for aging purposes (e.g., when the FT is older than 120 days - or whatever age has been set as the Oldest Bucket Age on the Installation Options) and when its balance is exactly equal to zero with respect to other redundant FTs of the obligation.

Transferred Out is not used.

The Frozen switch is turned on when the FT has been frozen (i.e., posted to the obligation's payoff and/or current balances). If this switch is on, both Freeze Date/Time and Frozen By are populated.

Effective Date is the date the FT's debt is effective. It is an important date for penalty and interest calculations. The date is required unless your implementation has configured it to be optional using a feature configuration setting. Leaving the effective date blank is only possible if the "New Charge" box is checked. The expectation is that a subsequent process determines the correct effective date for the FT and sets it accordingly (and unchecks the "New Charge" box.)

Current Amount contains the FT's impact on the obligation's current amount.

Payoff Amount contains the FT's impact on the obligation's payoff amount.

Fastpath:

For more information, refer to Current Balance versus Payoff Balance.

Currency Code is the currency code associated with the FT's account.

GL Distribution Status defines the status of the FT in respect of its interface to the general ledger. When an FT is first created, its status is Pending. When an FT is frozen, this value is set to Generated. If you modify the GL details, the status becomes Modified. After it has been marked for interface to the general ledger by the GLS process, the status becomes Distributed.

GL Extract Dates display the Scheduled date that the GL details will be marked for interface to the general ledger. Note that this date is typically only set to a future date for FTs associated with automatic payments. Actual displays the date that the GL details were actually posted to the general ledger.

The grid at the bottom shows the FT's debits and credits (i.e., the detail journal lines). Debits are shown as positive amounts, credits are negative amounts. The following points describe rules governing if and how the information in the grid can be modified:

- The FT GL details may not be modified if the FT is Pending or Distributed.

- All Amounts must sum to zero.

- Multiple FT GL details may be set to affect the Total Amount (although they are normally generated with one GL checked to affect total amount).

- All FT GL's checked to affect Total Amount must sum to the Payoff Amount of the FT.

The following information is displayed:

- Sequence number is the system-assigned, unique identifier of the journal line.

- Total Amount defines if the journal line contains the total of the other journal lines. For example, on a bill segment for property tax, this would be turned on for the receivable account because its amount equals the sum of the other payable and revenue GL accounts.

- Distribution Code is the distribution code from which the GL account constituents are derived.

- If the GL Account has been populated, the GL account number is displayed.

Fastpath:

Refer to GLASSIGN - Assign GL Account Numbers To GL Details for more information about how the GL account is populated.

- Amount defines the journal line's amount.

- Statistic Amount defines the statistical amount that will be posted to the GL. This value is only populated on distribution lines created for rate components designated as affecting GL statistical quantity.

- Characteristic Type and Characteristic Value describe the characteristic value that was used when the line's amount was calculated. This information is only displayed if the journal line was derived from bill calculation lines that were calculated using a rate factor (because only rate factor's use characteristic values). Refer to An Illustration Of A Rate Factor And Its Characteristics for more information.

Note:

Tax reporting. It is important to note that a journal line's characteristic value is NOT interfaced to the GL. We have included this attribute on the journal line so that tax reporting can be performed from this system (tax reporting typically necessitates showing each taxing authority - the characteristic value - that participated in a given tax payable GL account).

- If you have configured your installation options to indicate that fund accounting is practiced, the description of the Fund associated with this distribution code is displayed.

Financial Transaction - FT Process

Use Financial, Financial Transaction, FT Process to view those ancillary processes that may be triggered as a result of this financial transaction.

Note:

Algorithms cause financial transactions to be linked to batch processes. Financial transactions get associated with a given process / batch number when certain algorithms are executed. For example, when an external offset financial transaction is generated, it would be linked to a download process for the external division whose debt was collected. The external offset download process would use the linked batch process value to identify all financial transactions that were generated on behalf of the division.

Description of Page

This page shows the Batch Processes associated with a given Financial Transaction. Information on this page may not be modified. This information appears purely for audit purposes.

Financial Transaction - Characteristics

You use this page to link additional information to the financial transaction. Open using Menu > Accounting > Financial Transaction and navigate to the Characteristics tab.

Description of Page

The Characteristics page is a grid containing one row for each characteristic linked to the financial transaction.

Note:

You can only choose characteristic types defined as permissible on an FT record. Refer to Setting Up Characteristic Types and Their Values for more information.

Description of Page

Select a Characteristic Type, Sequence Number and Characteristic Value to be associated with this Financial Transaction.

Account Financial History

This page shows how an account's current and payoff balance have changed over time. Open using Menu > Accounting > Account Financial History.

Description of Page

This page is dedicated to a grid that shows an account's financial events.

You can use this grid to both view high-level information about these events and to transfer to the respective page in which an object is maintained. The following columns are displayed in the grid:

Effective Date

This is the effective date of the financial transaction.

Financial Transaction Type

This column indicates the type of financial event: Bill Segment, Pay Segment, Bill Segment Cancellation, Pay Segment Cancellation, Adjustment and Adjustment (Cancel). If the event is related to an adjustment, the adjustment type's description is displayed instead of "Adjustment".

Current Amount

This column shows the financial event's effect on the account's current balance.

Current Balance

This column shows the account's current balance after the financial event.

Payoff Amount

This column shows the financial event's effect on the account's payoff balance. The value is grayed out if it is the same as the current amount.

Payoff Balance

This column shows the account's payoff balance after the financial event. The value is grayed out if it is the same as the current balance.

Obligation Information

This column shows the information string for the obligation impacted by the financial transaction.

If you need to see more information about a specific financial transaction, click the go to button to transfer to the respective page in which the information is maintained.

Fastpath: For information about current and payoff balance, refer to Current Amount versus Payoff Amount.

Account Bill / Payment History

This page shows an account's bills and payments. Use Menu > Billing > Account Bill / Payment History to open this page.

CAUTION:

For balance-forward accounts, bill rows contain the balance presented on the respective bill, and payment rows contain the amount of the respective payment. However, for open-item accounts, this query behaves differently - see the description of page below for the details.

Description of Page

This page is dedicated to a grid that shows the account's bills, payments and payment cancellations. You can use this grid to both view high-level information about these objects and to transfer to the respective page on which an object is maintained.

The area beneath Account ID provides you with options that control which transactions appear in the grid. The following points describe the various options:

- Use Transaction Type Filter to restrict the type of transactions that appear in the grid. The following options are available:

- All. This option shows all transactions.

- Bill. This option shows all bills.

- Not Billed Yet. This option shows a single line with a summary of frozen financial transactions that have not appeared on a bill yet.

- Payment. This option shows all payments.

- Payment Cancellation. This option shows all payment cancellations.

- Use Match Event Status Filter to restrict the transactions based on the status of their match event. This filter only appears if the bill's account is an open-item taxpayer. The following options are available:

- All. This option shows all transactions regardless of the status of their match events.

- Balanced. This option shows all transactions with at least one balanced match event.

- Disputed. This option shows all transactions with at least one disputed match event.

- Unbalanced. This option shows all transactions with at least one unbalanced match event.

- Unmatched. This option shows all transactions with at least one financial transaction that is not linked to a match event.

- Use Date Range From and To to restrict the transactions based on effective date.

CAUTION:

Don't forget to click the search button after changing the filters or after selecting a new Account ID.

For balance-forward accounts, bill rows contain bill information including the balance presented on the respective bill, and payment rows contain the amount of the respective payment.

For open-item accounts, the grid behaves differently:

- The amount on bill rows is equal to the sum of the current charges, adjustments and corrections on the bill. Payment rows contain the amount of the respective payment.

- Each row contains an indication if all of its financial transactions are fully matched.

- A summary of the match status of its financial transactions is shown in the adjacent columns:

- Balanced contains the count and total amount of financial transactions linked to this activity that are linked to balanced match events.

- Unbalanced contains the count and total amount of financial transactions linked to this activity that are linked to unbalanced match events.

- Disputed contains the count and total amount of financial transactions linked to this activity that are linked to disputed match events.

- Unmatched contains the count and total amount of financial transactions linked to this activity that are not linked to any match event.

You can use the hyperlinks to view the detailed financial transactions that are summarized in each cell.

Obligation Financial History

This page is dedicated to a grid that shows the financial transactions linked to an obligation. Use Menu > Accounting > Obligation Financial History to open this page.

Description of Page

This page is dedicated to a grid that shows an obligation's financial transactions (FT). You can use this grid to both view high level information about these objects and to transfer to the respective page in which an object is maintained.

The following columns are displayed in the grid:

Effective Date

This is the date the FT starts aging. This column will be blank if the FT has not started aging yet.

Financial Transaction Type

This column indicates the type of financial event: Bill Segment, Pay Segment, Bill Cancellation, Pay Cancellation, Adjustment and Adjustment (Cancel) . If the event is related to an adjustment, the adjustment type's description is displayed instead of "Adjustment".

Current Amount

This column shows the FT's effect on the obligation's current balance.

Current Balance

This column shows the obligation's current balance after the financial event.

Payoff Amount

This column shows the FT's effect on the obligation's payoff balance. The value is grayed out if it is the same as the current amount.

Payoff Balance

This column shows the obligation's payoff balance after the financial event. The value is grayed out if it is the same as the current balance.

If you need to see more information about a specific financial transaction, click the go to button to transfer to the respective page in which the information is maintained.

Fastpath:

For information about current and payoff balance, refer to Current Amount versus Payoff Amount.

Obligation Cash Accounting Balance

Note:

Only relevant if you practice cash accounting. This transaction is only relevant if you practice cash accounting (e.g., you only pay the taxing authorities when the taxpayer pays you). Refer to Payables Cash Accounting for more information about cash accounting.

This page displays a grid that shows an obligation's cash accounting balance for each cash holding distribution code that's been booked to. Use Menu > Accounting > Obligation Cash Accounting Balance to open this page.

Description of Page

The following columns are displayed in the grid:

Cash Accounting Distribution Code

This is a general ledger distribution code used as the holding account for cash accounting. Each holding account that's been used by this obligation will appear here.

Payable Distribution Code

This is the general ledger distribution code to which the payable is (or will be) transferred when the cash event occurs.

Fastpath:

For more information on how the distribution codes are set up, refer to Setting Up Distribution Codes.

Payoff Balance

This column shows the obligation's balance for each cash holding account. If this amount is non-zero, it indicates that for this obligation we are still holding some payables back until payment is received by the taxpayer, at which time some or all of this amount will be transferred to the payable distribution code.

Fastpath:

For information about cash accounting, refer to Payables Cash Accounting.

Balance Control

This page is used to summarize the financial transactions that belong to a particular balance control group.

Fastpath:

Refer to The Big Picture of Balance Control for more information.

Note:

Balance Control information is current only as of the Create Date/Time listed. The information displayed on the page is captured when the balance control background process is run. Any financial activity subsequent to the create date and time will not be shown.

Use Menu > Accounting > Balance Control to open this page.

Description of Page

This page displays summarized financial information for a particular balance control group. It also details financial information for all obligation types that belong to the group.

The following fields are displayed on the page:

Group ID

This is a sequential value that uniquely identifies a particular balance control run. The Group ID is assigned and incremented automatically every time the Balance Control background process is run.

Status

This is the status of the balance control record: Pending , and Complete . The status of the balance control record will only be pending while the balance control background process is being executed. Balance control information is only reliable if the status is complete.

Create Date/Time

This is the date and time that the balance control record was created. Financial information displayed on this page will only contain information for financial transactions frozen before this date and time.

Current Amount

This is the sum of the current amounts of all FTs that belong to the balance control group.

Payoff Amount

This is the sum of the payoff amounts of all FTs that belong to the balance control group.

Current Balance

This is the sum of the current amounts of all FTs that belong to this balance control group plus all earlier balance control groups. Therefore this is the instantaneous current balance of the entire system as of the create date and time.

Payoff Balance

This is the sum of the payoff amounts of all FTs that belong to this balance control group plus all earlier balance control groups. Therefore this is the instantaneous payoff balance of the entire system as of the create date and time.

The number of FT information details the number of bill segments, pay segments, adjustments and their cancellations that belong to the balance control group.

Adjustment

The total number of adjustments that belong to this balance control group.

Adjustment Cancellation

The total number of adjustment cancellations that belong to this balance control group.

Bill Segment

The total number of bill segments that belong to this balance control group.

Bill Cancellation

The total number of bill cancellations that belong to this balance control group.

Pay Segment

The total number of pay segments that belong to this balance control group.

Pay Cancellation

The total number of pay cancellations that belong to this balance control group.

Theobligation type scroll summarizes the FTs that belong to a particular obligation type within the balance control group - otherwise all fields are defined as above. You can scroll through all obligation types that belong to the balance control group.

Obligation Type

The obligation type being summarized.

Match Event

CAUTION:

Match Events are only used if you practice Open Item Accounting.

Match events are used to match debit and credit financial transactions together. When financial transactions are linked to a balanced match event, they no longer affect the taxpayer's arrears.

You can use the match event page to do the following:

- Add, change, delete, and cancel match events.

- Add and remove financial transactions from / to a match event.

- Designate financial transactions as being "in dispute" (disputed financial transactions do not affect aged debt until they are resolved).

- View all unmatched financial transactions linked to an account.

Fastpath:

Refer to Match Events for a full description of the lifecycle of a match event and a description of how the system automatically creates match events.

Next in This Section

- Match Event - Main

- Match Event - FT Details

- Match Event - Subtotals

- How To Perform Common Match Event Functions

Match Event - Main

A typical match event matches a bill's financial transactions with a payment's financial transactions. The Main page allows you to define the bill(s) and payment(s) whose financial transactions are matched together. Use Menu > Payments > Match Event to open this page.

Note:

Debit must equal credits. Before a match event impacts a taxpayer's arrearage, its debits and credits must net to zero for every obligation referenced on the match event. Until that time, the financial transactions on a match event continue to affect arrearage. The only exception is the case of disputes.

Note:

You can match any debit and credit. While the above describes the matching of bills and payments, it's important to remember that a match event matches any type of debit with any type of credit. This means that a match event could match a payment with a payment cancellation.

Note:

You can match any number of payments under a match event. While most match events deal with a single bill and a single payment, there's no limitation to the number of payments on a match event. The only restriction is that the debits and credits must net to zero for all obligations.

Note:

It is better not to mix multiple bills on a single match event. For purposes of bill balance information, it is strongly recommended that you compose your match events with financial transactions limited to a single bill. If you mix financial transactions from multiple bills on a single match event you will not be able to determine the unpaid balance of a partially paid bill.

Note:

You can match specific financial transactions. While most match events deal with every financial transaction on a bill and payment, a match event can deal with individual financial transactions. For example, a match event could match a bill segment with a combination of a payment segment and a write-off adjustment. If you need to add or remove a specific financial transaction (i.e., a bill segment, payment segment, or adjustment), navigate to the FT Details tab. Perhaps a better way to differentiate between this page and the FT Details tab is to consider the example of a bill with 100 bill segments. When you link this bill to a match event, you are actually linking its 100 financial transactions. If you wanted to add only a subset of this bill's financial transactions to the match event, you'd use the FT Details tab.

Fastpath:

Refer to How To for instructions describing how to perform common match event maintenance functions.

Description of Page

This page is used to maintain the financial transactions (FTs) that are linked to a match event. The remainder of this section defines each of the fields on the page.

Match Event Info and Match Event ID only appear after the match event exists on the database. The ID is a system assigned random number that stays with the match event for life. Match Event Info is a concatenation of important details about the match event and its account.

The next section contains the sum of the Debit and Credit financial transactions linked to the match event. If the debits and credits do not sum to zero, the Difference is also shown.

Account ID defines the account whose financial transactions are matched under this match event. This field is gray after the match event is added to the database.

Match Event Status defines the state of the match event.

- Match events are initially created in the open state. Please note that you may delete an open match event.

- The system automatically changes an open event's status to balanced when the sum of the Debit(s) equals the sum of the Credit(s)for each obligation on the match event. It's worth stressing that a match event may contain financial transactions from many obligations and each obligation's financial transactions must sum to zero before the match event can become balanced.

- You may reopen a balanced event (by adding / removing items so that the match event becomes unbalanced).

- You can cancel a balanced or open match event by changing the Match Event Status to cancelled. You must also define a Cancel Reason if you cancel a match event. Refer to How Are Match Events Cancelled? for more information about cancellation.

Turn on Dispute if this match event exists to designate certain financial transactions as disputed. In addition,

- Describe the reason for the dispute in Remarks.

- Link the disputed financial transactions to the match event by selecting the bill(s) below. If only a subset of a bill is disputed:

- Click on the respective hyperlink in the Unmatched Debits column grid (this will transfer you to the next tab with these financial transactions displayed).

- Select the bill segments that you want to designate as disputed.

- Press the Link / Unlink button to link the selected bill segments to the match event.

Note:

Disputing items on a balanced event. The Dispute switch will be protected when the match event is Balanced or Cancelled. If the items on a balanced event are being disputed, you must add / remove items so that the match event becomes Open before you can turn on the Dispute switch.

The remainder of the page is dynamic depending on the Match Event Status:

- If the status is Balanced or Open, a grid appears containing a summary of the bills, payments, and payment cancellations that contribute financial transactions to the match event (note, we refer to these collectively as "contributing objects" in the following discussion). The following columns appear in this grid:

- Transaction Type defines whether the contributing object is a Bill, Payment or Payment Cancellation. In the rare situation when unbilled financial transactions are linked to the match event, a transaction type of Not Billed Yet appears. If the contributing object is a bill its bill id is also displayed.

- Matched Activity Information contains summary information about the contributing object. This column is blank if the transaction type is Not Billed Yet.

- The remaining columns contain the count and amount of each contributing object's financial transactions categorized as follows (note, you can drill down on the count or amount to see the specific financial transactions (FT's) on the next tab).

- Matched Debits summarizes the contributing object's debit FT's that are linked to this match event. A checkbox appears if the count is greater than zero. If you select the checkbox and press the Link / Unlink button, these debits will be removed from the match event.

- Matched Credits summarizes the contributing object's credit FT's that are linked to this match event. A checkbox appears if the count is greater than zero. If you select the checkbox and press the Link / Unlink button, these credits will be removed from the match event.

- Other Debits summarizes the contributing object's debit FT's that are NOT linked to this match event.

- Other Credits summarizes the contributing object's credit FT's that are NOT linked to this match event.

Note:

Adding more financial transactions to a balanced match event. When a match event is Balanced, the grid showing unmatched FT's is suppressed (and therefore you can't add additional FT's to the match event). To expose this grid, simply change the status of the match event to Open.

- If the status is Open, a second grid appears containing a summary of the bills, payments, and payment cancellations with at least one unmatched financial transaction (we refer to these collectively as "unmatched objects" in the following discussion). The following columns appear in this grid:

- Transaction Type defines whether the unmatched object is a Bill, Payment or Payment Cancellation. A transaction type of Not Billed Yet is used for unbilled financial transactions (e.g., adjustments generated between bills). If the unmatched object is a bill its bill id is also displayed.

- Unmatched Activity Information contains summary information about the unmatched object. This column is blank if the transaction type is Not Billed Yet.

- The remaining columns contain the count and amount of each unmatched object's financial transactions categorized as follows (note, you can drill down on the count or amount to see the specific financial transactions (FT's) on the next tab).

- Unmatched Debits summarizes the unmatched object's debit FT's that are not linked to any match event. A checkbox appears if the count is greater than zero. If you select the checkbox and press the Link / Unlink button, these debits will be added to the match event.

- Unmatched Credits summarizes the unmatched object's credit FT's that are not linked to any match event. A checkbox appears if the count is greater than zero. If you select the checkbox and press the Link / Unlink button, these credits will be added to the match event.

- Matched Debits summarizes the unmatched object's debit FT's that are linked to any match event.

- Matched Credits summarizes the unmatched object's credit FT's that are linked to any match event.

The last section contains the running total of the Debit and Credit financial transactions that have been selected / unselected in the above grids. If debits and credits do not sum to zero, the Difference is also shown. These values differ from the values on the top of the page as they are updated when a user selects / unselects an object (whereas the values at the top of the page are only updated when the database is changed).

The Link / Unlink button becomes enabled when you select an object in the grids. When you press this button, the financial transactions related to the object are added to / removed from the match event.

Match Event - FT Details

On the Main tab, you can add and remove bills, payments, and payment cancellations to / from a match event. When you do this, you are actually adding and removing all of the financial transactions linked to these objects. For example, when you link a bill with 100 bill segments to a match event, you are actually linking its 100 financial transactions.

You need only use the FT Details tab when you need to add or remove specific financial transactions. For example, you would use the FT Details tab if you need to remove 1 of a bill's 100 financial transactions from a match event.

To open this page, use Menu > Payments > Match Event and navigate to the FT Details tab.

Description of Page

This page is used to maintain the financial transactions (FTs) that are linked to a match event. The remainder of this section defines each of the fields on the page.

Match Event Info and Match Event ID only appear after the match event exists on the database. The ID is a system assigned random number that stays with a match event for life. The Match Event Info is a concatenation of important details about the match event and its account.

The next section contains the sum of the Debit and Credit financial transactions linked to the match event. If the debits and credits do not sum to zero, the Difference is also shown.

The following Filters work together to restrict the financial transactions that appear in the grid. The following points describe the various options (note, don't forget to press the search button after specifying the various filter options):

- Use Transaction Type Filter to restrict the type of transactions that appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict financial transactions based on their transaction type.

- Bill. This option allows you to view a specific bill's financial transactions. When this option is selected, an input field appears in which you identify the Bill ID.

- Credit Note. This option allows you to view a specific credit note's financial transactions. When this option is selected, an input field appears in which you identify the Bill ID (every credit note has a unique bill ID).

- Not Billed Yet. This option allows you to view financial transactions that haven't appeared on a bill yet (e.g., adjustments and corrections).

- Payment. This option allows you to view a specific payment's financial transactions. When this option is selected, an input field appears in which you identify the Payment ID.

- Payment Cancellations. This option allows you to view a specific canceled payment's financial transactions. When this option is selected, an input field appears in which you identify the Payment ID.

- Use Linkage Filter to restrict the transactions based on the match event to which they are linked. The following options are available:

- All. This option shows all financial transactions regardless of their match event.

- Linked to another Match Event. This option shows financial transactions linked to a different match event.

- Linked to any Match Event. This option shows financial transactions linked to any match event.

- Linked to this Match Event. This option shows financial transactions linked to this match event.

- Unmatched. This option shows financial transactions that are not linked to a match event.

This filter is protected and set to Linked to this Match Event if the Transaction Type Filter is All.

- Use Debit / Credit Filter to restrict the transactions based on whether they are debits or credits. The following options are available:

- All. This option shows all debit and credit financial transactions.

- Credit. This option shows all credit financial transactions.

- Debit. This option shows all debit financial transactions.

- Use the Obligation Filter to define the types of obligations whose financial transactions appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict financial transactions based on obligation attributes.

- Obligation ID. Use this option to restrict financial transactions to those linked to a specific obligation.

- Obligation Type. Use this option to restrict financial transactions to those whose obligations are linked to a given division and obligation type.

CAUTION:

Don't forget to click the search button after changing the filters.

The Select All / Unselect All buttons are used to select financial transactions to add to / remove from the match event (note, after selecting the desired financial transactions, you must also press the Link / Unlink button at the bottom of the page).

Note:

50 financial transactions at a time. Clicking Select All selects the first 50 bill segments in the grid. If more than 50 financial transactions exist, you must select them in batches.

The grid that follows contains the financial transactions (FT) that match your search criteria. The following information appears in the grid:

- Select box. Select the FT if you want to Link / Unlink it. You implicitly link FT's that are NOT already linked and you implicitly unlink FT's that are already linked. This field is protected if the FT is linked to another match event.

- FT Amount. This column contains the amount of the financial transaction.

- FT Type. This column indicates the type of financial transaction: Bill Segment, Bill Segment Cancellation, Pay Segment, Pay Segment Cancellation, AdjustmentandAdjustment Cancellation.

- Effective Date. This column contains the financial transaction's effective date.

- Obligation Information. This column contains a summary of the financial transaction's obligation.

- Remarks. This column highlights the financial transaction's match status: Linked to this match event, Not linked to a match event, Linked to another match event - match event status.

- Location Information. This column contains a summary of the location (if any) associated with the financial transaction's obligation.

The last section contains the running total of the Debit and Credit financial transactions that have been selected / unselected in the grid. If debits and credits do not sum to zero, the Difference is calculated. These values differ from the values on the top of the page as they are updated when a user selects / unselects an object (whereas the values at the top of the page are only updated with the database is changed).

The Link / Unlink button becomes enabled when you select a row in the grid. When you press this button, the financial transactions related to the object are added to / removed from the match event.

Match Event - Subtotals

Before a match event impacts a taxpayer's arrearage, its debits and credits must net to zero for every obligation referenced on the match event. This page shows the sum of the debits and credits for every obligation that contributes at least one financial transaction to the match event. To open this page, use Menu > Payments > Match Event and navigate to the Subtotals tab.

Description of Page

This page shows the sum of the debits and credits for every obligation that contributes at least one financial transaction to the match event.

Match Event Info and Match Event ID only appear after the match event exists on the database. The ID is a system assigned random number that stays with a match event for life. The Match Event Info is a concatenation of important details about the match event and its account.

The next section contains the sum of the Debit and Credit financial transactions linked to the match event. If the debits and credits do not sum to zero, the Difference is also shown.

The following Filters work together to restrict the obligations that appear in the grid. The following points describe the various options (note, don't forget to press the search button after specifying the various filter options):

- Use the Obligation Filter to define the types of obligations whose financial transactions appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict obligations.

- Obligation ID. Use this option to see a specific obligation.

- Obligation Type. Use this option to restrict obligations to those with a given division and obligation type.

- Use Status Filter to restrict the obligations based on whether the sum of the debits and credits they contribute to the match event. The following options are available:

- All. Use this option if you do not wish to restrict obligations based on this status.

- Balanced. This option shows only obligations where the sum of debit and credits nets to zero on this match event.

- Unbalanced. This option shows only obligations where the sum of debit and credits do not net to zero on this match event.

CAUTION:

Don't forget to click the search button after changing the filters.

The grid that follows contains the obligations that match your search criteria. The following information appears in the grid:

- Obligation Information. This column contains a summary of important information about the obligation.

- Difference. This column contains the difference between the Matched Debits and Match Credits. If this is non-zero, the value appears in red.

- Matched Debits. This column contains the sum of debit financial transactions that this obligation contributes to this match event.

- Matched Credits. This column contains the sum of credit financial transactions that this obligation contributes to this match event.

- Location Information. This column contains a summary of the location (if any) associated with the financial transaction's obligation.

How To Perform Common Match Event Functions

Next in This Section

- How To Find The Match Event Associated With A Financial Transaction

- How To Dispute An Item

- How To Match A Small Mismatch

How To Find The Match Event Associated With A Financial Transaction

If you need to find the match event on which a financial transaction (FT) was matched, display the FT in question on Financial Transaction - Main and then use the "go to" button adjacent to the Match Event to drill to the match event.

Note:

The easiest way to display a financial transaction is to find its corresponding bill, payment or adjustment and then drill down on the desired transaction.

How To Dispute An Item

Refer to Disputing Items for background information about disputes.

If a taxpayer wants to dispute an item:

- Create a match event for the account.

- Turn the match event's dispute switch on.

- Link the disputed financial transaction to the match event.

- Describe in the match event's comments the reason for the dispute.

How To Match A Small Mismatch

Assume the following scenario arises:

- A bill is produced for $2000

- The taxpayer pays $1993

- An unbalanced match event will result because the taxpayer didn't pay exactly what is owed

If you want to match this payment to the bill (and leave $7 for the next bill), do the following:

- Create a transfer adjustment of $7 where the transfer from / to obligation is the same. This results in a debit financial transaction (FT) of $7 and a credit FT of $7.

- Create a match event (or update the unbalanced match event) where the matched FTs are:

- The $1993 payment

- The credit side of the transfer adjustment ($7)

- And the $2000 bill

- Then, if the taxpayer pays their next bill in full, the $7 debit (associated with the transfer adjustment) will be swept onto it.

Note:

Automating small mismatches. The algorithm responsible for matching a payment to a specific bill can have a tolerance amount defined on it. If the payment is within the tolerance limit, this algorithm will do the above for you. In other words, you don't have to manually do the above if you populate the tolerance limit appropriately on this algorithm. Refer to DSOV BILL-ID for more information about this algorithm.

Overpayment Processing

We use the term overpayment to refer to an obligation that has a credit balance as a result of payments exceeding the liability. In this section we describe how to manage the overpayment process. The topics in this section describe details about overpayment processing functionality provided in the product.

Next in This Section

- Overpayment Overview

- Maintaining Overpayment Processes

- Common Overpayment Procedures

- Refund Control Overview

- Maintaining Refund Controls

- Common Refund Control Procedures

Overpayment Overview

The following topics provide an overview of overpayment processing functionality.

Overpayment Process Type

Each overpayment process has an associated overpayment process type. The overpayment process type defines the configuration information that is common to overpayment processes of a given type. The tax type governs the overpayment process types that are valid. When creating an overpayment process, the overpayment process type to use must be valid for the obligation’s tax type. Refer to The Big Picture of Overpayments for a description of the business rules that you control when you set up your overpayment process types.

Creating an Overpayment

An overpayment process occurs when the obligation has a credit balance as a result of the payment amount exceeding the liability from the assessment. Another common reason for overpayment is the recalculation of tax, penalty, interest or fee that results in a reduced liability.

An overpayment process can be created in various ways:

- As a result of posting a return. This is the most common scenario. The tax form is processed and results in a creation of an assessment. The calculated tax due is evaluated against the total payments made to determine if there is an overpayment.

- As a result of the balance of the obligation being reviewed by the account monitor.

- Implementations may find other system events that should automatically cause an overpayment to be created.

- It is also possible to manually create an overpayment process. For example, if an overpayment occurs and the tax authority chooses to keep the amount for applying to future debt, the taxpayer may ask for it to be returned.

Regardless of how the overpayment is created, the overpayment process is always associated with a specific obligation.

Overpayments may be On Hold

After an overpayment is created, an algorithm may detect a condition that causes it to transition the record to On Hold. An example of this is that an algorithm may detect that an active Suppression exists.

In this situation, the overpayment may be left in this state. A monitor algorithm should be periodically checking to see if the situation causing the record to go into On Hold has been resolved. When this occurs, the overpayment will be reinstated. Note that overpayment process may also be canceled when in this state, if appropriate.

Overpayments and Refund Control

The base overpayment functionality works with the refund control object as part of its lifecycle. A refund control is an object that groups together a list of overpayments that are ready for refunds to be issued. Refund control is mentioned throughout this section. More details about refund control are found in Refund Control Overview.

Maintaining Overpayment Processes

Use the Overpayment Process transaction to view and maintain pending or historic overpayment processes. Navigate using Menu > Accounting > Overpayment Process.

Next in This Section

- Overpayment Process Query

- Overpayment Process Portal

Overpayment Process Query

Use the query portal to search for an overpayment process. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.

Overpayment Process Portal

This portal appears when an overpayment process has been selected from the Overpayment Process Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Overpayment Process - Main

- Overpayment Process - Log

Overpayment Process - Main

This portal appears when an overpayment process has been selected from the Overpayment Process Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Overpayment Process

The Overpayment Process zone contains display-only information about the selected Overpayment Process.

Please see the zone's help text for information about this zone's fields.

Overpayment Approval

The Overpayment Approval zone contains display-only information about the current approver of the selected Overpayment Process.

Please see the zone's help text for information about this zone's fields.

Overpayment Process - Log

Navigate to the Log tab to view the logs for an overpayment process.

Common Overpayment Procedures

This section describes common overpayment procedures based on functionality provided in the base product.

Note: The functionality described in this section is based on the Standard Overpayment business object supplied by the base product. It is possible for your implementation to implement different business processes.

Manually Creating an Overpayment

Use this procedure to manually add an overpayment process.

- Use the menu navigation to launch the add an overpayment process dialogue.

- If there is already an account displayed in the dashboard, this account is defaulted. If no account is displayed or if the incorrect account is displayed, use the search to select the account. Once the account is selected, use the obligation dropdown to select the appropriate obligation.

- Once the obligation is selected, select the appropriate overpayment process type from the dropdown. Only those types that are valid for that obligation’s tax type are available.

- Fill in information about the refund method and Save the record.

At this point the system will immediately do various checks resulting in different possible states:

- Overpayment validation rules are checked. If there are any issues, the overpayment will be in the Issues Detected state. Refer to the Resolving Issues for an Overpayment Process section below for more information.

- If the system has found an active suppression that impacts this overpayment, the overpayment will be in the On Hold state.

- The overpayment may automatically transition to Complete if one of the following conditions is true:

- The system detects that the amount of the credit is below the minimum write off threshold. The amount will be written off, bringing the balance to zero and the process will complete.

- The system detects that no approval is necessary and subsequent algorithms use the credit for other purposes, such as offsetting other debt for the same account. If the balance is brought to zero, the process will complete.

- If the system has determined that approval is necessary, the overpayment will be in the Approval in Progress state. An appropriate user will need to approve the record before it proceeds.

Note: The user that creates the overpayment process cannot approve the it due to a separation of duties validation check.

- If the system has determined that no approval is necessary and a refund is required, the overpayment transitions to Refund Approval in Progress where it waits to be linked to a refund control for approval.

Resolving Issues for an Overpayment Process

An overpayment process is validated when it is initially created. In addition, once a refund is detected, validation specific to a refund amount (such as verifying bank details for a direct deposit method) is checked. If issues are found during either of these steps, the overpayment process will transition to the Issues Detected state and a To Do is created. Use this procedure to resolve issues for an overpayment process.

- Navigate to the overpayment process portal. If you are viewing the To Do entry, should can drill into the overpayment process from the To Do.

- An issues list will appear at the top of the overpayment process zone. If the problem is related to information on the overpayment process, you can Edit the overpayment process and correct the error. If the issue is related to a specific field, a 'go to' button will appear next to the issue. After saving the changes, you can then click Reprocess so that the system revalidates the updated overpayment process. At this point, the overpayment may transition to any of the states as described in the Manually Creating an Overpayment Process section above.

- The problem may be that related to the state of the overpayment’s obligation. For example, it may be that another pending direct deposit was detected. Or it may have detected that there are no valid bank details for the obligation’s main person. You may need to correct information elsewhere in the system before attempting to reprocess the overpayment. If you determine that the overpayment should not progress, click Reject and provide an appropriate reason.

Approving an Overpayment Process

If an overpayment requires approval and you are in the To Do role that is allowed to approve the overpayment, use this procedure to approve the overpayment:

Note: If you are the user that created the overpayment process or you are a previous approver (for an overpayment that requires multiple approvals) then you will not be able to approve the overpayment due to a separation of duties validation check.

- Navigate to the overpayment process portal. If you are viewing the To Do entry, should can drill into the overpayment process from the To Do.

- Review the overpayment process details. Note that if the obligation’s balance has changed since the last time the overpayment was updated, a message is visible to the user. If the balance is no longer a credit, or is zero, the overpayment is no longer needed. However, the user must still take an action to reject or approve the process. Approving an overpayment in this situation will cause it to immediately complete.

- To allow the overpayment to progress, click Approve. If additional approvals are required, the overpayment will remain in the Approval in Progress state. A To Do for the next approval level will be generated. If you are the last or only approver, the overpayment will transition to one of the following states based on various conditions:

- On Hold. This will occur if the system has found that an active suppression that impacts this overpayment has been created since triggering the approval step.

- Complete. This will occur if the balance of the obligation becomes zero or no longer a credit. This could occur if the balance had already changed prior to the approval as described above. It could also occur after approval if algorithms linked to the overpayment apply the credit to other debt or use it in some other manner.

- Issues Detected. This will occur if there is an amount to refund and the refund validation algorithms detect an issue. For example, there may be an issue with the taxpayer’s bank details. Refer to the Resolving Issues for an Overpayment Process section.

- Refund Approval in Progress. This will occur if there is an amount to refund and no issues are found. The overpayment must now wait to be included in a refund control for further processing.

- If there is a reason that the overpayment should not progress, click Reject and provide a rejection reason.

Canceling an Overpayment Process

Normally a user does not need to cancel an overpayment process. A process that initiated the overpayment may cancel it if the initiating process is canceled. For example, if the overpayment is created by a tax form, reversing the tax form may cause the overpayment to be canceled. An implementation may choose to allow users to cancel an overpayment process manually. Use this procedure to cancel an overpayment manually:

- Navigate to the overpayment process portal for the overpayment than needs to be canceled.

- Click Cancel and provide an appropriate cancel reason, if prompted.

Refund Control Overview

A refund control is an object that groups together a list of overpayments that are ready for refunds to be issued. The refund control allows an implementation to review the total amount for all the overpayments in the list and ensure that there are enough funds in the bank to cover the payments out to the taxpayers.

The following topics highlight refund control functionality.

Creating Refund Controls

Refund controls are created based on an implementation's business practice. The product provides support for the following ways of creating refund controls:

- Manual creation with criteria provided. An implementation may opt to let the refund control users create the appropriate refund controls each day, providing criteria such as tax type, overpayment process type and maximum amount. Once created, the user allows the record to be processed by the deferred monitor where an algorithm uses this criteria to select overpayments that match the criteria and link them to the refund control.

Fastpath: Refer to Common Refund Control Procedures for more information.

- Creation via an interface. An implementation may opt to use an external reporting or analysis tool to select an explicit list of overpayments. In this case, the implementation must configure an interface to create the refund control and link the overpayments. Once the refund control is created, the deferred monitor processes it in the background to validate the list of linked overpayments.

Overpayment Link Status

The overpayments that are ready to be refunded are in a status of Refund Control Approval in Progress and remain in that state until the refund control is approved. There is another status, referred to as the Link Status that identifies the status of a particular overpayment to a particular refund control. The following points highlight the status values.

- When an overpayment is initially linked it has a link status of Active. Only overpayments linked as active are considered eligible for refund.

- An overpayment's link status may change to Skipped by the validation if the algorithm detects that the overpayment is no longer the status Refund Control Approval in Progress . For example, maybe the status of the overpayment is now Rejected because a user has rejected the overpayment process. Note that this option is only possible for the case where IDs are provided from an external source. The "criteria provided" option selects the overpayments in the validation step and would only select overpayments in the correct status. The background process that issues the refunds for overpayments in an approved refund control may also detect this situation.

- An overpayment's link status may change to Removed at any time after it is linked. There are two ways that this can happen:

- A user may explicitly remove an overpayment when reviewing the refund control for approval. This may occur when it is determined that there are not enough funds to cover the total amount and some overpayments are removed to reduce the total amount to one that is appropriate. Refer to Common Refund Control Procedures for more information.

- A change could occur in an individual overpayment after it is linked to the refund control and the refund control is approved but before the amount is refunded. For example, perhaps a different financial transaction has occurred that brought the balance to zero or to a debit balance. This is checked at the time the overpayment attempts to transition itself.

Note: Skipped vs. Removed. If the refund control algorithms or background process detects that an overpayment is no longer in the status of Refund Control Approval in Progress the link status is set to skipped. The link status is set to removed when an individual overpayment is removed by a user or by an overpayment algorithm that detects that its refund needs re-evaluation.

Approving Refund Controls

Once the refund control and its list of overpayments are validated, the system determines if approval is required. If so, the record transitions to Approval in Progress and a To Do entry is created to alert the appropriate user(s). Note the following with respect to refund control approval:

- The refund control type defines appropriate user groups for approval based on the total of the refund amounts for all the active overpayments.

- The refund control type defines whether multiple levels of approval are required or if only a single approval is needed.

- The refund control validates that an approver cannot be the same user that created the record nor the same user that performed a previous approval (for multiple approval levels).

- When a refund control is found to have no overpayments linked as active, the refund control transitions to Approval in Progress even though there is nothing to approve. This allows a user to review the refund control to determine what happened to cause this situation. The user should then Reject the record.

Creating the Refunds

Once a user approves a refund control, a batch process processes the linked overpayments to issue the refunds for each individual overpayment. The following are some points to note about this step:

- The expectation is that this process is part of the nightly batch cycle because it creates financial transactions and subsequent background processes to interface the refund information to the accounts payable system or the bank interface are also required. As such there may be a delay from the time that a refund control is approved to the time its related overpayments are refunded.

- Because of the time delay, it is possible that one or more individual overpayments are no longer eligible for refund once they are processed. As mentioned in the Overpayment Link Status section above, these overpayments are marked as Removed.

Maintaining Refund Controls

Use the Refund Control transaction to view and maintain pending or historic refund controls. Navigate using Menu > Accounting > Refund Control.

Next in This Section

- Refund Control Query

- Refund Control Portal

Refund Control Query

Use the query portal to search for a refund control. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.

Refund Control Portal

This portal appears when an overpayment process has been selected from the Refund Control Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Refund Control Portal

- Refund Control - Log

Refund Control Portal

This portal appears when a refund control has been selected from the Refund Control Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Refund Control

The Refund Control zone contains display-only information about the selected refund control.

Please see the zone's help text for information about this zone's fields.

Refer to the Common Refund Control Procedures section for more information about common functions.

Linked Overpayments

This zone displays a list of the overpayments that are currently linked to the refund control along with the status of the link. Refer to Refund Control Overview for more information about the link status. The filter allows the user to select a subset of records to display based on information such as link status, overpayment amount and tax type.

Refund Control - Log

Navigate to the Log tab to view the logs for a refund control.

Common Refund Control Procedures

This section describes common refund control procedures based on functionality provided in the base product.

Manually Creating a Refund Control

A user would only create a refund control manually when an implementation supports defining criteria for creating a refund control and its overpayments. Implementations that use an interface to create the refund control and its overpayments can ignore this procedure. Use this procedure to manually add a refund control.

- Use the menu navigation to launch the add a refund control dialogue.

- Select the refund control type from the dropdown. The expectation is that only refund control types that are configured for providing criteria.

- Fill in the criteria to limit the selection of overpayments to link to the refund control. Note that if no criteria is provided, all overpayments in the Refund Control Approval in Progress state are selected.

- Save the record.

At this point the user can opt to click Validate causing the system to select the overpayments that match the criteria. However, the expectation is that the user allows the deferred monitor to pick up the record for processing.

Note: The user that creates the refund control cannot approve the refund control once the selection is made due to separation of duties validation checks.

Reviewing and Approving a Refund Control

Once a refund control is validated, if it requires approval based on the amount thresholds defined on the refund control type, a To Do entry is routed to the appropriate user group. When a user in that group reviews the refund control, this procedure should be followed:

- Drill into the refund control record from the To Do entry (or from the email, if the To Do is routed to an email).

- Review the summary counts of the linked overpayments and the total refund amount to see if the information is as expected. If desired, use the Linked Overpayments zone to spot check and even drill into any overpayments.

- If for any reason the total amount of overpayments should be reduced, use the Linked Overpayments zone to select one or more overpayments to remove from the list. Note that the overpayments remain in the list for audit purposes. But the link status is updated to Removed.

- Once the list of Active overpayments is acceptable, click Approve. This prepares the record to be processed in batch to issue the refunds for the individual overpayments.

- If anything about the refund control appears to be incorrect, the user can opt to click Reject to prevent further processing of this refund control. If prompted for a rejection reason, enter an appropriate reason.

Note: All the overpayments remain linked to the refund control for audit purposes. However, they are now eligible to be linked to another refund control.

Bank Event

Bank events are used to interface transactions to financial institutions.

The following sections describe how to maintain bank events.

Next in This Section

- Understanding Bank Events

- Maintaining Bank Events

Understanding Bank Events

The topics in this section provide background information on bank events.

Next in This Section

- About Bank Events

- Creating Bank Events

About Bank Events

A bank event is used to interface a transaction (e.g. direct deposit) to a financial institution.

Each bank event refers to a bank event type that controls the aspects of how a bank event is processed. These include the following:

- The lifecycle of the bank event.

- The background process responsible for extracting/downloading bank events.

- Control information for actions taken when bank events are accepted or rejected by the financial institution.

Refer to The Big Picture of Bank Events for a description of business rules that you control when you set up your bank event types.

Creating Bank Events

Most bank events are created behind the scenes by related processes that determine financial transactions to interface.

Bank Events can be used for different types of financial transactions that need to be interfaced to an external system. However, base functionality currently supports the use of bank events for direct deposit processing.

Refer to Direct Deposits Using Bank Events for more details.

Maintaining Bank Events

Use the Bank Event transaction to view and maintain bank events. Navigate using Menu > Accounting > Bank Event.

Next in This Section

- Bank Event Query

- Bank Event Portal

Bank Event Query

Use the query portal to search for an existing bank event. Once a bank event is selected, you are brought to the maintenance portal to view and maintain the selected record.

Bank Event Portal

This page appears when viewing the detail of a specific bank event.

The topics in this section describe the base-package zones that appear on this portal

Next in This Section

- Bank Event - Main

- Bank Event- Log

Bank Event - Main

This portal appears when a bank event has been selected from the Bank Event Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Bank Event

The Bank Event zone contains display-only information about the selected bank event.

Please see the zone's help text for information about this zone's fields.

Bank Event- Log

Navigate to the Log tab to view the logs for a bank event.

Rates

Rates may be used to do any number of calculations for a taxpayer, such as assessments for filing based tax types, real property taxes, complicated penalty and interest rules or interest calculations for overpayments.

CAUTION:

The rates functionality described here is supported for use in calculating penalty and interest and simple form calculations. The calculation engine is the recommended functionality for any new calculation configuration.

CAUTION:

Any references in this chapter to “billing” are referring to the classic billing functionality. This is not the recommended billing functionality for any new implementations. The rates engine is not used by the billing functionality.

CAUTION:

Any references in this chapter to “location” are referring to legacy address functionality. Rate and rate factor functionality do not support centralized address definitions for taxpayer location.

The rate controls:

- How charges are calculated.

- How the charges appear aesthetically on the taxpayer's bills, for billed obligation types.

- How the general ledger is affected by the charges.

In this section, we explain how to set up your organization's rates.

Fastpath: Refer to How Rates Affect The Information On A Bill for how billing uses the information in a rate to calculate a bill segment.

Note: Not all obligations reference a rate. It's important to understand that the system may not determine the applicable rate for a calculation solely from the obligation. For example, the rate used to calculate an assessment may be referenced on the tax form type. Whether or not an obligation uses a rate and the list of rates that can be specified on an obligation are controlled by the obligation's obligation type.

Next in This Section

- All Rates Share A Common Structure

- How To Create A New Rate

- Control Tables That Must Be Set Up Before Creating A Rate Schedule

- Setting Up A Rate Schedule

- Rate Schedule Merge

- Setting Up Rate Factors

- Defining Rate Versions

- Designing Rate Components

- Defining Rate Components

- Rate Version Merge

- Rate Check

- Effective Dates & Proration

- How To Add A New Rate Quantity Rule Algorithm

All Rates Share A Common Structure

All rates share a common structure as illustrated in the following sample rate:

This rate is constructed using the following components:

- Every rate has a single rate schedule that contains information about the rate that doesn't change over time. For example, the rate's description.

- A rate's effective-dated calculation algorithms are stored in a rate version. Every rate schedule has at least one rate version. Multiple rate versions exist when something about the algorithms changes and it's important to keep the prior version in order to recalculate historical bills. The rate shown above has 2 rate versions; one effective on 1-March-1997, the other effective on 1-April-1998.

- A rate version's calculation algorithms are stored in rate components. Every rate version will have at least one rate component. The number of rate components linked to a rate version is dependent on the complexity of the calculation rules. We have seen very simple calculation rules that need only a single rate component; we have seen others that require over 150 rate components. You will find the construction of rate components to be the most challenging task of the setup process.

- Rate factors are used to specify the amount to charge when the amount is the same for many rates. Notice that both of the above rate versions reference the prevailing "state tax" rate factor rather than specifying the specific tax percent. This allows the tax rate to be maintained in one place.

Note:

Rate factors have many uses. Rate factors have many uses in addition to specifying tax rates. Refer to An Overview Of Rate Factors for all the details.

The remainder of this chapter discusses the intricacies of setting up the rates and rate factors.

How To Create A New Rate

The following points describe steps you'll follow to set up a rate.

- Create a rate schedule for the rate. Refer to Setting Up A Rate Schedule for more information.

- Set up a rate version to establish the earliest effective date of the rate. Refer to Defining Rate Versions for more information. We recommend that you set the status of the rate version to In Progress while you're working on the rate.

- Set up rate components to define the rate version's calculation rules. Refer to Defining Rate Components and Rate Version Merge for more information.

- After all rate components have been setup, return to Rate Version - Main and change the rate version's status to Validated. At this point, you can use Rate Check to test the rate version.

- After you have checked the rate, return to the Rate Version - Main and change the status to Finished. This allows the rate to be used by billing.

- Define the various obligation types that can use the rate. You do this by referencing the rate on Obligation Type - Rate.

Control Tables That Must Be Set Up Before Creating A Rate Schedule

This section describes tables that must be set up before you can add a new rate schedule.

Next in This Section

- Defining Frequency Codes

- Setting Up Rate Quantity (RQ) Rules

- Defining Rate Quantity (RQ) Identifiers

- Setting Up Unit Of Measure Codes

- Setting Up Time-Of-Use Codes

Defining Frequency Codes

When you create a rate schedule, you must enter a code defining the frequency in which the charges are expressed, e.g., monthly, quarterly, biannual, etc. To set up frequency codes, open Admin > Frequency.

Description of Page

Enter a unique Frequency ID and Description for each frequency.

The remaining fields impact proration in your rates.

- Periods Per Year indicates how often the charge on the rate is calculated. This information is used to calculate the number of days in a given period by dividing the standard number of days in a year (365) by this number.

- Offset for Minimum Days indicates the number of days to subtract from the standard number of days to determine a low end of the proration range.

- Offset for Maximum Days indicates the number of days to add to the standard number of days to determine a high end of the proration range.

If the current period is outside of the calculated range, then the value is prorated.

Note: Overriding the system's standard proration logic. If the standard proration logic does not satisfy your requirements, you may plug in an override proration algorithm to calculate the proration factors as required by your implementation. For example, a company may treat a year as having 360 days rather than 365 days. Such a company would need to develop an override proration algorithm and plug it on the Installation record.

Where Used

Every Rate Schedule must have a frequency. Refer to Rate Schedule - Main for more information.

Setting Up Rate Quantity (RQ) Rules

To set up Rate Quantity (RQ) rules, choose Admin > Rate Quantity Rule .

Description of Page

Enter a unique RQ Rule ID and a Description for the RQ rule.

Enter a Long Description that describes, in detail, what the rule does.

Indicate the UOM, TOU and RQI to be output by the rule.

Note: Unit of Measure (UOM) and Time of Use (TOU) do not normally apply to tax-based calculations and will typically be left blank..

Every rate quantity supplied to a rate has two quantities - the quantity as it was initially captured, and the quantity that rate calculation will use. Most of the time, these two amounts will be the same. They will only differ when another RQ Rule has executed and caused the billable quantity to change (an RQ Rule NEVER changes initially captured quantities). Because these two amounts may differ, an RQ Rule needs to know if it should use the quantity as initially captured OR if it should use the quantity that rate calculation will use. You use the RQ Quantity to Use field to indicate such. Valid values are Use Initial Quantity and Use Billable Quantity.

Indicate whether the system should Create Billing Error if the RQ Rule is not able to execute successfully. For most RQ Rules you would turn this option on. However, if the rule is linked to a rate where the rule is only applicable to a subset of the taxpayer base using the rate, you may not want a billing error to be issued if the rule cannot execute.

Use RQ Rule Processing to indicate if the RQ rule is Always executed by rate application, even if the billable details on the original bill segment are to be used when the system recalculates a bill segment (refer to Rebill (Bill Segment)). If the RQ rule should not be executed when the billable details on the original bill segment are used, indicate that the RQ rule should only be executed on the Initial RQ Calculation. RQ rules that create a characteristic type / value (in the characteristic collection) used by one or more rate factors referenced in a rate component should typically be always executed. Refer to Base Package RQ Rules for examples of RQ rules that create a characteristic type / value.

Select the RQ Algorithm Type that controls how the system manipulates the quantity supplied to the rate. Define the Parameters to be used by the RQ algorithm.

Next in This Section

- Base Package RQ Rules

Base Package RQ Rules

The system provides a number of base package RQ rule algorithms. Click here to see algorithm types available for this entity.

Note:

If the base package algorithms are not sufficient for your rating requirements, you must write a new RQ rule algorithm. Refer to How To Add A New RQ Rule for how to do this.

For more information about defining algorithm types, refer to Setting Up Algorithm Types.

Where Used

A Rate Schedule may have zero or more RQ Rules. Refer to Rate Schedule - RQ Rules for more information.

Defining Rate Quantity (RQ) Identifiers

CAUTION:

RQIs exist to support calculations performed by rate components. This means that you must design your rate components before you can design your rate quantity identifiers. We strongly recommend that you design "on paper" how every rate's rate component looks before you attempt to set up your RQIs.

Note:

If you create an RQI, you must also have a corresponding RQ Rule to calculate the amount of the RQI to be charged by the rate. If not, it is impossible for the system to generate a bill line for the RQI because there will be no quantity associated with the RQI.

To define rate quantity identifiers, open Admin > Rate Quantity Identifier .

Description of Page

Enter a unique Rate Qty. Identifier and Description for every RQI.

Enter the appropriate number of Decimal Positions for each RQI. The rate application process uses this information to round the calculated rate quantity prior to applying appropriate rate components.

Where Used

An RQ Rule may use an RQ Identifier to describe what it generates. Refer to Setting Up Rate Quantity (RQ) Rules for more information.

A Rate Quantity Rate Component may use an RQ Identifier to describe what it is charging. In this situation, the rate must contain an RQ Rule that generates a quantity for this RQI; otherwise there will be a charge without a rate quantity. Refer to Rate Component - Main Information for more information.

Setting Up Unit Of Measure Codes

Many rates contain prices in respect of some number of something. We use three distinct codes to identify the "thing" being priced in a rate. Unit of measure (UOM) is one code provided to help identify something being priced in a rate.

To define unit of measure codes, open Admin > Unit of Measure .

Description of Page

The following fields display for each unit of measure:

UOM

The unique identifier of the unit of measure.

Description

The full description of the UOM.

Tax Type

The type of rate associated with this UOM. Refer to Setting Up Tax Types for more information.

Decimal Positions

The number of decimal positions that appear on bill lines.

Measures Peak

This setting is used to default the measures peak quantity setting for rate components that reference this unit of measure.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_UOM.

Setting Up Time-Of-Use Codes

Many rates contain prices in respect of some number of something. We use three distinct codes to identify the "thing" being priced in a rate. Time of Use (TOU) is one code provided to help identify something being priced in a rate.

To define time-of-use codes, open Admin > Time of Use .

Description of Page

Enter a unique Time of Use code and Description for every time of use code.

Where Used

Follow this link to open the data dictionary where you can view the tables that reference CI_TOU.

Setting Up A Rate Schedule

A rate schedule is setup for every rate used in calcualtions. Rate schedules are defined using the pages described in this section.

Note:

A rate schedule isn't complete without rate versions and rate components. Refer to All Rates Share A Common Structure for information about how you must also create rate versions and rate components for every rate schedule.

Next in This Section

- Rate Schedule - Main

- Rate Schedule - RQ Rules

- Rate Schedule - Bill Messages

Rate Schedule - Main

You start the rate definition process by selecting Menu, Rates, Rate Schedule. On this window you enter general information about the rate.

Description of Page

Enter a unique Rate Schedule ID to identify the rate. The value that you supply will typically correspond with the identity of the rate in your rate book.

Enter a Description for the rate schedule.

Select the Tax Type that describes the type of tax associated with this rate. When you maintain an existing rate schedule, this field will be gray if the rate is referenced on at least one obligation type. See Setting Up Tax Types for more information.

Select a Frequency to define the time period in which the rate's charges are expressed. See Defining Frequency Codes for more information.

Select a Currency Code to define the currency in which the rate's charges are expressed. See Defining Currency Codes for more information.

Note:

Currency note. All rate factors that are referenced on the rate's rate components must be denominated in the same currency as defined on the rate schedule. This is because rate factors are used when the charge is "soft" and all charges in a rate, be they hard or soft, must be in the same currency. Also note - all rates referenced on an account's obligations must be denominated in the same currency as defined on the account.

Turn on Allow RVs Proration if a change in the Rate Version during a bill period should be prorated. If changes should not be prorated, indicate the RV Selection Date to use when the system determines which rate version to use; available options are:

Accounting Date

The rate version effective on the bill's accounting date will be used.

Bill End Date

The rate version effective on the bill's end date will be used.

Bill Start Date

The rate version effective on the bill's start date will be used.

Rate Schedule Tree

The right half of this page is dedicated to a tree that shows the rate schedule's RQ Rules and Rate Versions. You can use this tree to view high-level information about these objects. You may also transfer to a given rate version by selecting that rate version.

Note:

The duplicate action in the action button bar enables you to copy another rate schedule and optionally, its rate versions. Refer to Duplicate Button in the system wide standards document for more information.

Rate Schedule - RQ Rules

When a rate schedule has RQ Rules, the system executes each rule's algorithm before it calculates the charges embodied in the rate's rate components. Open Menu > Rates > Rate Schedule and navigate to the RQ Rule tab to link RQ Rules to a rate.

Fastpath: For more information, refer to Setting Up Rate Quantity (RQ) Rules.

Note: The Rate Schedule Merge page enables you to build the RQ rule collection for your rate schedule by copying collections from existing rate schedules.

Description of Page

Enter a Rate Quantity Rule for every type of rate quantity manipulation required by the rate. The Sequence number is important when you have multiple rules linked to the rate, as it defines the order in which the rules will be executed.

Where Used

Classic Billing uses this information to create additional rate quantities at billing time.

Rate Schedule - Bill Messages

When a rate schedule has bill messages, the system will sweep these messages onto bills that use the rate.

Select Menu, Rates, Rate Schedule and navigate to the Bill Messages to link bill messages to a rate.

Note: Optional information. This tab is only visible if your implementation has not turned off the BI — Billing (Classic) module. The information is used only for classic billing functionality.

Fastpath:

For more information about bill messages, refer to The Source Of Bill Messages.

Note:

The Rate Schedule Merge page enables you to build the bill message collection for your rate schedule by copying collections from existing rate schedules.

Description of Page

Use the Bill Messages collection to define Bill Message codes that should appear on bills that use a given rate schedule. 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 bill messages on a bill during bill completion. Refer to The Source Of Bill Messages for more information.

Rate Schedule Merge

Use this page to modify an existing rate schedule by copying information from other rate schedules. This page may be used to copy records from the RQ rule, and bill message collections from one or more existing rate schedules to another. Some examples of when this page may be used are as follows:

- You wish to create a new rate schedule, which is similar to an existing rate schedule. Rather than copying all the information from the existing rate schedule and then removing the inapplicable components, this page may be used to selectively copy only the information applicable to the new rate schedule.

- Perhaps you have a tax calculation that contains many optional components. Rather than building a generic rate schedule used by many tax form types, and using other logic to determine which options are applicable to which tax form, you may choose to build a custom rate schedule for each form type, using only the components applicable to that tax form. In this scenario, you may choose to create special 'mini' rate schedules, one for each of the various calculation options. Then, you could use the rate schedule merge page to select the components applicable for the new custom rate schedule.

- Perhaps you are adding several new bill messages, which are applicable to multiple existing rate schedules. Once you have added the new messages to one rate schedule, you may find it easier to update the subsequent rate schedules by using the rate merge page to copy the messages across.

Note: The target rate schedule must exist prior to using this page. If you are creating a new rate, you must first go to the Rate Schedule page to add the new rate schedule and then navigate to the merge page to copy collection information.

Note: Duplicate versus Merge. The Rate Schedule page has Duplication capability. You would duplicate a rate schedule if you want to a) create a new rate schedule AND b) populate it with all the information from an existing rate schedule. You would use the rate schedule merge page if you want to build a rate schedule using pieces of one or more rate schedules.

Use Menu > Rates > Rate Schedule Merge to open this page.

Description of Page

Select the Original Rate Schedule that is the target for merging the rate schedule collection information.

Select the Merge From Rate Schedule that is your template rate schedule to copy the collections from.

Note: You may only copy information from one Merge From rate schedule at a time. If you wish to copy information from more than one rate schedule, select the first Merge From rate schedule, copy the desired records, Save, then select the next Merge From rate schedule.

The left portion of the page will display any existing records in the collections for the original rate schedule. The right portion of the page will display the existing records in the collections for the Merge From rate schedule.

You may use the Copy All button to copy all the records in all the collections from the Merge From rate to the Original rate. If you do not choose to copy all, you may copy records individually as described below.

The left portion of the RQ Rule collection initially displays existing RQ rule records linked to the original rate schedule. In the Merge Type, you will see the word Original, for any of these records. The Sequence number and RQ Rule description are displayed. In the right portion of the collection, the existing records in the merge from rate are displayed initially.

The left portion of the Bill Messages collection initially displays existing bill messages linked to the original rate schedule. In the Merge Type, you will see the word Original, for any of these records. The description of each Bill Message is displayed. In the right portion of the collection, the existing records in the merge from rate are displayed initially.

The topics in this section describe how to perform common maintenance tasks.

Next in This Section

- Removing A Row

- Adding A New Row

- Removing An Uncommitted Row

- Moving Rows Up and Down

Removing A Row

If you wish to remove a record linked to the Original rate schedule, press the "-" button to the left of the record.

Adding A New Row

You may move any of the records from the Merge From rate to the original rate 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.

Removing An Uncommitted Row

If you have copied a row across by mistake, you may remove it by clicking on the right arrow adjacent to the appropriate record.

Moving Rows Up and Down

The RQ Rule grids contain sequence numbers that indicate the order in which the rules should be executed. You may modify the execution order using the up and down arrows.

Fastpath:

Refer to Editable Grid in the system wide standards documentation for more information about adding records to a collection by selecting from a list and repositioning rows within a grid.

Setting Up Rate Factors

This section describes rate factors and how they are used to levy the many charges referenced in a rate.

CAUTION:

Rate factors were implemented in older technology and are not the recommended option for new implementations. The factor objects should be considered instead.

CAUTION:

Any references in this section to “billing” are referring to the classic billing functionality. This is not the recommended billing functionality for any new implementations. Rate factors are not used by the billing functionality.

CAUTION:

Any references in this chapter to “location” are referring to legacy address functionality. Rate factor functionality does not support centralized address definitions for taxpayer location.

CAUTION:

Most rate factors exist to support calculations performed by rate components. This means that you must design your rate components before you can design your rate factors. We strongly recommend that you design "on paper" how every rate's rate components looks before you attempt to set up rate factors.

Next in This Section

- An Overview Of Rate Factors

- The Structure Of A Rate Factor

- An Illustration Of A Rate Factor And Its Characteristics

- Deriving / Passing In Characteristic Values

- Defining Rate Factors

- Defining Rate Factor Values

An Overview Of Rate Factors

The primary reason why rate components exist is to define how to calculate values. When you create rate components, the following factors indicate how these values should be calculated or determined:

- Specify the value directly in the rate component.

- Tell the rate component to use the value defined in a rate factor.

- Tell the rate component to use the value calculated by a "for calculation purposes only" rate component.

- Tell the rate component to call an algorithm to calculate the value.

The remainder of this section describes the rate factor approach. The other methods are discussed in Designing Rate Components.

Rate factors are frequently used to specify a tax rate. For example, you could specify the current tax rate (say 6%) directly in every rate's rate components OR you could indicate every rate should levy the current state tax rate and have the system look up the applicable rate when it calculates bills. The latter approach involves using a rate factor to indicate that the amount to charge should be retrieved from someplace other than the rate component when a bill is calculated.

You can use rate factors to define any of the following types of charges:

- A flat amount. This would typically be used to define fixed charges such as fees.

- An amount for a given unit of measure.

- A percentage.

As a rule of thumb, you would use a rate factor (rather than specify the value in the rate component) when any of the following situations exist:

- The same charge exists in many rates.

- The amount being charged is dependent on some physical characteristic of the taxpayer's location.

- The amount being charged is dictated by some external organization and therefore can change independently from the rate. For example, city tax percentages are set by city taxing authorities and can be changed at any time (and you don't want to change the rate when these charges change).

- The amount being charged varies depending on WHERE the taxpayer lives.

- A charge is only levied for a subset of taxpayers for defined periods of time.

CAUTION:

As you can deduce, rate factors are extremely flexible. While the flexibility makes for a very powerful rating engine, it also presents you a dizzying array of options. We have discovered that to take advantage of the flexibility, you need to gain an overall understanding of the taxation provisions in ALL of your rates. Only then can you make logical and pragmatic decisions in respect of the number and type of rate factors.

The Structure Of A Rate Factor

All rate factors share a common structure as illustrated below:

The above example shows a standard rate factor made up of the following tables:

- A rate factor contains descriptive information and attributes that control how the rate factor may be used in the system.

- All rate factors have the capability of having different values depending on some characteristic of the location. For example, a rate factor used to levy a city tax would have a different tax rate depending on the city in which the taxpayer resides. A rate factor characteristic must exist for every city with a tax (cities without a tax will not be linked to the city tax rate factor). At billing time, if the system cannot find a rate factor characteristic that corresponds with the taxpayer's city of residence, the charge will be skipped.

- And finally, each rate factor characteristic may have many rate factor values over time. To continue with our city tax example, each city with a tax can have different tax rates over time. There are different ways in which a rate factor's values may be defined:

- For rate factors whose values are applicable to many taxpayers where only one value is effective on a given date, e.g., a city tax, the values are defined using rate factor values. Refer to Defining Rate Factor Values for more information.

- For rate factors whose values are applicable to many taxpayers where more than one value is effective on a given date.

An Illustration Of A Rate Factor And Its Characteristics

The following picture illustrates how a rate factor and its characteristics are used to retrieve the relevant city tax at billing time:

The following points describe the above:

- At billing time, the billing engine sends a request to a rate to calculate the appropriate city tax based on the known real property tax calculated for the county.

- The rate calculates charges without rate factors until it encounters the rate component used to levy city tax. This rate component references a rate factor. This means the rate must get the tax rate(s) in effect during the billing period from this rate factor.

- The city tax rate factor contains an attribute defining that the location's taxing city characteristic controls the rate factor value. The rate factor therefore extracts the taxing city from the location.

Note:

Deriving characteristic values. Rather than have the system extract the characteristic value from an entity, you can setup the system to derive the characteristic value when the rate is calculated. For example, if all of your taxpayers are located in a single city, you may not want to maintain the taxing city on every location. To do this, you could setup the rate to "hard code" a taxing city of say Sterling. This is an advanced topic, but it may prove useful for your implementation. Refer to Deriving / Passing In Characteristic Values for the details.

- The location returns the taxing city and the rate factor extracts the tax rate(s) in effect during the bill period and returns them to the rate.

- The rate applies the tax percents and returns the charges to billing.

Note:

Some rate factors don't need a characteristic. There are rate factors whose value does not differ based on a characteristic. For example, a rate factor that does not need a characteristic is a fee assessed for returned checks. These are typically flat fees that do not vary when applied. However, because of the relational design of the system, every rate factor value must reference both a rate factor and a characteristic value. Therefore, if you have rate factors whose value is not related to a characteristic, you must specify a characteristic type on the rate factor with a characteristic value that is exactly the same as the characteristic type.

Fastpath:

For more information about setting up characteristics, see Setting Up Characteristic Types & Their Values.

Deriving / Passing In Characteristic Values

CAUTION:

This is an advanced, technical concept.

In An Illustration Of A Rate Factor And Its Characteristics, we described how the system retrieves a characteristic value from a location when a rate factor is encountered that uses a location characteristic. This is a very common technique and is easy to understand. However, there are situations when an entity doesn't contain the appropriate characteristic value and therefore other techniques must be used. These techniques may not apply to your implementation, but they're worth understanding to help you form an intuitive understanding of rate application:

- Assume you have a charge that is based on the account's account type and the obligation's revenue class. This type of charge's characteristic value is not extractable from a single entity. Rather, the system must construct the characteristic value real-time by concatenating information from the account and obligation being billed. In this situation, you can use an RQ rule to derive this characteristic type and value. This RQ rule would create a characteristic type and value real time by concatenating the account's account type and the obligation's revenue class. This characteristic type and value only exists in memory while rate application executes. This is an example of the system deriving a characteristic value as opposed to it being passed in or retrieved from another object in the system.

When you setup a rate factor to use a characteristic whose value is derived or passed in, you need to define its characteristic source as Characteristics Collection. This source tells the system to extract the characteristic value from memory rather than extracting it from an object within the system.

Note: The various plug-in spots on a rate component have access to the Characteristics Collection. You might find this useful if you have a rate component that needs to calculate characteristic values for subsequent rate components.

Defining Rate Factors

You create a rate factor for every type of charge whose value is not specified directly in a rate component.

You use two windows to set up a rate factor. On the first, you define general information describing how the rate factor is used in the system. On the second, you define every characteristic value for which the rate factor has a value.

Next in This Section

- Defining General Rate Factor Information

- Setting Up Rate Factor Characteristics

Defining General Rate Factor Information

You begin to define a rate factor by selecting Menu, Rates, Rate Factor.

Description of Page

Enter a unique Rate Factor code and a Description for the rate factor.

Rate Factor Type is set to Regular.

Enter a Currency Code to define the currency in which the rate factor's charges are denominated. This field will be gray if the rate factor is referenced on a rate component.

Note: Rate factors referenced on a rate component must be denominated in the same currency as is the rate.

Select the Value Type to define the kind of value maintained by this rate factor. The Value Type options are:

Charge

The value maintained in this rate factor is a fixed amount (e.g., a flat charge).

Percentage

The value maintained in this rate factor is a percentage.

Unit Rate

The value maintained in the rate factor is a charge per rate quantity.

This field will be gray if the rate factor is already referenced on a rate component or if the rate factor already has values.

Turn on Error If No Value if the system should create a billing error when a rate factor value doesn't exist for the characteristic value linked to the taxpayer.

Tax Exemption, Value In Contract Term and Contract Rider Applicability are not currently used by the system.

The proration information tells the system how to handle changes to rate factor values that may occur during a taxpayer's bill period. Turn on Allow Proration if changes to the rate factor's value should be prorated. If changes should not be prorated, indicate the Rate Selection Date to use when the system retrieves rate factor values; available options are:

Accounting Date

The rate factor value effective on the bill segment's accounting date will be used.

Bill End Date

The rate factor value effective on the end date will be used.

Bill Start Date

The rate factor value effective on the bill segment's start date will be used.

Rate Factor Tree

The right half of this page is dedicated to a tree that shows the rate factors characteristics and their respective values. You can use this tree to both view high-level information about these objects and to transfer to the respective page in which an object is maintained by using the available Go To buttons.

Where Used

Many types of Rate Components may use a Rate Factor to define the amount being charged. Refer to Rate Component - Main Information for more information.

Setting Up Rate Factor Characteristics

After defining general information about a rate factor, open Menu > Rates > Rate Factor and navigate to the Rate Factor Characteristic tab to define characteristic values for which a charge is applicable. For example, a rate factor used to levy the applicable city tax would require the definition of every city that levies a tax.

Description of Page

Enter a Characteristic Type to indicate the type of characteristic that controls how the rate factor's value is defined. This field will be gray if Rate Factor Characteristics are specified in the following grid.

The Characteristic Source defines where the system retrieves the characteristic value at billing time. The Characteristic Source options are:

Account

The characteristic type's value will be retrieved from the obligation's account.

Characteristic Collection

Refer to Deriving / Passing In Characteristic Values for an explanation of this value.

Main Person

The characteristic type's value will be retrieved from the main person linked to the obligation's account.

N/A

The characteristic type's value is the same for all customers using the rate. If this option is used, you must still choose a Characteristic Type. This Characteristic Type should have a single Characteristic Value. The ID of the characteristic value must be identical to the ID of the characteristic type.

Obligation

The characteristic type's value will be retrieved from the obligation.

Location

The characteristic type's value will be retrieved from the obligation's characteristic location. This is only applicable to implementations that use legacy address functionality.

Fastpath:

For more information about characteristics, see Setting Up Characteristic Types & Their Values and An Illustration Of A Rate Factor And Its Characteristics.

Use the add and remove buttons to define the Characteristic Values that are relevant for the rate factor's Characteristic Type. For example, if the rate factor is used to levy a city tax, you would define the city's that have a city tax in the above collection.

Use the External ID if the values for this characteristic are interfaced to the system from an external source and you want to record an identifier for the source.

Note: If the rate factor's value is the same for all taxpayers, you still must link a "dummy" characteristic value to the rate factor. In other words, you'll have to create a characteristic type called "n/a" and define for it a characteristic value of "n/a". Then, on the rate factor, you reference the "n/a" characteristic type and on the above window, you indicate a characteristic value of "n/a".

Defining Rate Factor Values

After the rate factor and its characteristic values are defined, you define the charge / percent and GL distribution associated with each rate factor characteristic. The topics in this section describe the pages used to set up this information.

Next in This Section

- Rate Factor Value - Main

- Rate Factor Value - GL Distribution

Rate Factor Value - Main

After the rate factor and its characteristic values are defined, select Menu, Rates, Rate Factor Values to define the charge / percent applicable to each rate factor characteristic.

Description of Page

Enter the Effective Date and respective Value for the rate factor and characteristic value. The first date should be the earliest date on which the rate factor's charges are effective. Subsequent effective dates and values are required whenever the value changes.

Note: Default note. A value of 0 will be defaulted.

Rate Factor Value - GL Distribution

Select Menu, Rates, Rate Factor Value and navigate to the GL Distribution tab to define the GL account affected by the rate factor characteristic.

Note:

Important! If you do not specify this information for a rate factor characteristic, the distribution code defined on the rate component that references the rate factor will be used.

Description of Page

If the rate factor characteristic's charges are booked to a different GL account depending on the characteristic value, specify the appropriate Distribution Code for each Revenue Class.

Note:

Optional information. Specifying distribution codes on a rate factor is optional. You would only do this if the GL distribution code differs based on the characteristic value (e.g., the city tax payable GL account differs depending on the city). If you do not enter the above information, the distribution code specified in the rate component that references the rate factor will be used.

Defining Rate Versions

After defining general information about a rate on Rate Schedule Maintenance, you must link to it a rate version. The rate version defines the effective date of the calculation rules defined in its rate components. A rate schedule will have multiple rate versions if its calculation rules (i.e., its rate components) change over time.

Note:

A switch on the rate schedules controls what happens if multiple rate versions are effective during a bill period. When the system creates a bill segment for an obligation, it checks if multiple rate versions are in effect during the bill period. If so, it uses the rate schedule's Allow RVs Proration switch and RV Selection Date flag to determine if it should prorate the various rate versions or if it should pick one of the rate versions effective during the bill period.

After a rate version exists, you add rate components to it using Rate Component Maintenance and/or Rate Version Merge. After you have added all necessary rate components, don't forget to return to Rate Version - Main and change the state of the rate version to Finished (otherwise, it cannot be used by billing).

The topics in this section describe how to setup a rate version.

Next in This Section

- Lifecycle of a Rate Version

- Rate Version - Main

- Rate Version - Bill Print Info

Lifecycle of a Rate Version

The following diagram shows the possible lifecycle of a rate version (you'll notice that you can change a rate version from any state to any state).

A rate version is in the In Progress state while you build its rate components. While a rate version is in this state, the system does not perform cross validation between rate components as they are added / changed / deleted using Rate Component Maintenance and/or Rate Version Merge. However, the system will perform inter-field validation applicable to each type of rate component. Rate versions in this state may not be used by Rate Check, nor will they be used up by the billing process.

You transition a rate version to the Validated state when you're ready to check it using Rate Check, but you don't want billing to use it to calculate charges. When a rate version is transitioned to this state, the system performs cross validation between its rate components. If any validation errors are found, an error message is displayed and the status remains In Progress. If all validation checks are passed, the rate version status will become Validated. We'd like to stress that rate versions in this state may be used by Rate Check, but will not be used by billing.

You transition a rate version to the Finished state when it can be used by billing to calculate charges. All of the cross validation between rate components will be performed when transitioning to this state.

Note:

Finished and Validated states also affect rate component maintenance. If a rate version is Finished or Validated, the system performs internal consistency checks every time a rate component is added, changed or deleted using Rate Component Maintenance and/or Rate Version Merge. If you don't want these checks to be performed while you're working on a rate version's rate components, change its state to In Progress.

Rate Version - Main

Use Menu, Rates, Rate Version to maintain a rate version.

Description of Page

Rate Version contains basic information about the rate version. This information only appears after the rate version has been added to the database.

Rate Schedule defines the rate to which the rate version is linked. Effective Date defines the date on which the rate version's rate components become effective. These fields are the unique identifier of the rate version. Both fields become protected after the rate version is added to the database.

Note:

Multiple rate versions may be prorated. When the system creates a bill segment for an obligation, it checks if multiple rate versions are in effect during the bill period. If so, it uses the rate schedule's Allow RVs Proration switch and RV Selection Date flag to determine if it should prorate the various rate versions or if it should pick one of the rate versions effective during the bill period.

The Rate Version Status indicates the current state of the rate version. Refer to Lifecycle of a Rate Version for more information.

CAUTION:

Warning! Billing ignores rate versions that are not in the Finished status. This means that if you create a new rate version and forget to finish it, billing will use the prior rate version when it calculates the taxpayers' bills.

Specify the description of the rate version in Description on Bill. This description is saved on bill calculation details created using this rate version. The following table illustrates the substitution variable(s) that may be used to substitute variables into the description during billing:

Substitution Character

What It Does

%D

Replaces the substitution character with message 10101 from message category 4. This message is maintained in the standard message table.

We recommend this message be set to "(prorated for %1 of %2 days)" where %1 will be substituted with the number of days of prorated consumption charged on the bill line and %2 will be the "normal" days associated with the rate's charges. This message will only be substituted when the rate version is prorated.

The following is an example of the content of common Description on Bills along with how the line would look on the bill:

Description on Bill

How It Looks On A Bill

Interest %D

Interest (prorated for 10 of 30 days)

The tree that follows contains a summary of the rate version's rate components. You can use this tree to both view high-level information about these objects and to transfer to the respective page on which an object is maintained.

Note:

The duplicate action in the action button bar enables you to duplicate a rate version and its rate components. Refer to Duplicate Button in the system wide standards document for more information.

Rate Version - Bill Print Info

This page allows you to maintain the bill print information for all of the rate version's rate components. Note, you can also maintain this information for individual rate components on Rate Component - Main.

Description of Page

The grid contains an entry for each rate component linked to the rate version. The following information is displayed in the grid:

Sequence uniquely identifies the rate component. It also controls the order in which the rate component is processed when the rate version is processed by billing.

Description is the rate component's description.

Description on Bill is the verbiage that appears on the bill line generated for this rate component. You can dynamically substitute variables into this description (e.g., charge and quantity) when billing calculates the rate component's charges. Refer to How To Use Description on Bill for a discussion of the various substitution variables.

Turn on the Print switch if you want the bill line to appear on the taxpayer's bill.

Note:

Some bill lines don't print. You may wonder why we give you the ability to not print a bill line. The reason is because ALL bill lines are shown on Bill Segment - Calculation Details. However, only those lines marked as Print are presented to the taxpayer. This way, if you want to suppress some calculation details, you can, but still show the details to your own employees.

The Print If Zero switch is only enabled if the Print switch is turned on. It allows you to indicate if a bill line should print when the bill line's value is zero:

- Turn this switch on if the bill line should print when the calculated value is zero.

- Turn this switch off if the bill line should not print when the calculated value is zero.

Next in This Section

- How To Use Description on Bill

How To Use Description on Bill

Enter the verbiage to appear on the bill segment in the Description On Bill. Turn on Print if the verbiage should appear on the printed bill.

Note:

Suppressing calculation details on the printed bill. Only rate components used to calculate intermediate values are typically suppressed on a bill. For these types of rate components, we recommend using Description on Bill to show users how the line was calculated, but turn off the Print switch. This way, users will see the calculation details on the Bill Segment - Calc Lines window, but the taxpayer won't see it on the bill.

Many lines that appear on a bill do not contain static verbiage. Rather, the printed lines contain information from the calculation process. For example, the bill line for state tax would typically contain the tax percent.

You control exactly what is substituted in the bill line by entering one or more of the following substitution variables in the Description on Bill field:

Substitution Character

What It Does

%A

Replaces the substitution character with the amount of the bill line. Please be aware of the following:

- If the rate component isn't designated as being "for calculation purposes only" (FCPO), all trailing zeroes up to the decimal position of the rate's currency will be removed. If the rate component is designated as being "for calculation purposes only" (FCPO), the number of decimal places as defined in the rate component's precision will be shown.

- All leading zeroes will be removed unless the value is between 1 and -1 in which case a leading 0 will appear before the decimal place.

- The Symbol on the Currency control table will prefix the value.

- The position of the negative sign and currency symbol is dependent on the display profile of the user who generated the bill.

%D

Replaces the substitution character with message 10101 from message category 4. This message is maintained in the standard message table.

We recommend this message be set to "(prorated for %1 of %2 days)" where %1 will be substituted with the number of days of prorated consumption charged on the bill line and %2 will be the "normal" days associated with the rate's charges. This message will only be substituted when the rate component is prorated. Note, neither %1 nor %2 are required.

Either this character OR %F should be used when you desire to substitute the charge / percent into the bill line.

If the charge is proratable, %D should be using in conjunction with %R to print an appropriate message when the charges are prorated.

%F

Replaces the substitution character with message 10102 from message category 4. This message is maintained in the standard message table.

We recommend this message be set to "(prorated by %1)" where %1 will be substituted with the factor used to prorate the charge. This message will only be substituted when the rate component is prorated. Note, %1 is not required.

If the charge is proratable, %F should be used in conjunction with %I to print an appropriate message when the charges are prorated.

%I

Replaces the substitution character with the value specified in the rate component / rate factor.

If the value is a percent,

- all leading and trailing zeroes will be suppressed,

- and a "%" will be suffixed to the resultant value.

If the value is not a percent,

- all trailing zeroes up to the decimal position of the rate's currency will be removed,

- and all leading zeroes will be removed unless the value is between 1 and -1 in which case a leading 0 will appear before the decimal place,

- and note that the position of the negative sign and currency symbol is dependent on the display profile of the user who generated the bill.

Either this character OR %R should be used when you desire to substitute the charge / percent into the bill line. Using %I will cause the value as specified in the rate component to be substituted regardless of whether the charges are prorated.

If the charge is proratable, %I should be used in conjunction with %F to print an appropriate message when the charges are prorated.

%Q

Replaces the substitution character with the rate quantity being billed. Leading zeroes are suppressed. The decimal places shown are specified in a field on the Unit Of Measure control table.

%R

Replaces the substitution character with the value specified in the rate component / rate factor. Either this character OR %I should be used when you desire to substitute the charge / percent into the bill line. Using %R causes the prorated charge / percent to be printed in the bill line (%I causes the charge / percent as specified in the rate to be printed during proration situations).

If the charge is proratable, %R should be used in conjunction with %D to print an appropriate message when the charges are prorated.

%S

Replaces the substitution character with the summed amount. All trailing zeroes up to the decimal position of the rate's currency will be removed. All leading zeroes will be removed unless the value is between 1 and -1 in which case a leading 0 will appear before the decimal place. The Symbol on the Currency control table will prefix the value. If the value is negative, a "-" will prefix the value.

This character should only be used with Minimum, Apply To, and Summary rate components.

Lines that don't print

If the bill line is not printed (as defined by the Print switch), message 10104 from message category 4 will be appended to the bill line. This message is maintained in the standard message table.

We recommend this message be "NOT SEEN BY TAXPAYER!" This message appears in the bill line that appears in the billing windows but does not appear on the taxpayer's bill.

The following are examples of the content of common Description on Bills along with how the line would look on the taxpayer's bill:

Description on Bill On Rate Component

How It Looks On A Bill

County Tax at %R of %I: %A

County Tax at 1.0% of $70,160: $701.60

%O: %I %D

Homestead Exemption: $150.24 (prorated for 100 of 183 days)

First %Q of Income %R

First $45,000 of Income at 10%

State sales tax %R

State sales tax 6.25%

Minimum charge of %I %F

Minimum charge of $10.00 (prorated by .3333)

Subtotal of %S

Subtotal of $1,123.23

The prorated references will only appear if the rate component's charges are prorated due to a short or long bill period.

Designing Rate Components

Rate components are the fundamental building blocks of your rate calculation algorithms. All of the other rate and rate factor set up tasks are done in preparation of the creation of these records. This means that you must design your rate components before you can design rate factors, RQ rules, RQ identifiers, eligibility rules. We strongly recommend that you design "on paper" how every rate component looks on every rate schedule before you attempt to set up any of the rate control tables.

Fastpath:

All of the calculation details and financial information that appear on a bill segment are derived using information on rate components. If you want to see the results of what rate components do, refer to Bill Segment - Calc Lines.

CAUTION:

There are innumerable ways to design rate components for a given rate. Some designs will result in easy long-term maintenance; others will result in maintenance headaches. In this section, we provide information to help you understand the ramifications of the various options. Before you set up your production rate components, we encourage you to gain intuitive understanding of these options by using the system to prototype the alternatives.

The topics in this section provide background information that will facilitate the construction of your rate components.

Next in This Section

- Rate Component Design Methodology

- Rate Component Rounding

- The Big Picture Of Rate Component Eligibility Rules

Rate Component Design Methodology

Designing rate components is an iterative process. Over time, you will develop intuitive skills that will allow you to avoid some iterations. However, when you're starting out, we recommend you follow these steps to design your rate components:

- Obtain copies of existing bills that use the rate in question. If the rate is new, then write up EXACTLY how the information should appear on the taxpayers' printed bills. If the rate has optional charges (e.g., city taxes that are added if applicable or senior citizen discounts), make sure your examples encompass every possible scenario.

- Next, look at the bill lines and ask yourself what are the variables that cause each line's charges to be calculated the way they are. Consider the following examples:

- "County Tax at 1.0% of $70,160: $701.60". This charge is based on the tax rate and the base amount for the calculation. The variables involved are the tax rate, the base amount and the resulting tax amount.

- "Homestead Exemption: $150.24 (prorated for 100 of 183 days)". This line may appear on the bill if the taxpayer qualifies for this particular type of exemption. The variables involved are the exemption type, amount and proration (if applicable).

- "Minimum monthly charge of $100.00". This is a charge that only appears if the total of the prior lines is less than $100.00. The variables involved in this line are a little complicated because they must be calculated at billing time by adding up several other lines and comparing them to the minimum charge amount. This means the variables are the total of prior lines and the minimum charge amount.

- "1.25% County Surcharge". This charge is similar to the minimum charge in that it is calculated by adding up one or more prior lines and applying a percentage to the sum. This means the variables are the total of prior lines plus the tax percentage.

- After you've determined all of the potential bill lines you can start designing your rate components. Typically you create one rate component for every line that can appear on the taxpayer's bill. When you create a rate component, you will categorize it as one of the following types:

Flat Charge

This type of rate component is used to create bill lines that levy fixed charges and fees that aren't based on the taxpayer's income, asset value or other assessable amounts. The monthly charge shown above would be levied using this type of rate component.

Rate Quantity

This type of rate component is used to create bill lines that levy charges based on some type of input quantity.

Apply To

This type of rate component is used to create bill lines that levy charges based on the amount calculated on other bill lines.

Summary

This type of rate component is used to create a "subtotal" on the bill. It exists purely for aesthetic purposes.

Minimum Charge

This type of rate component is used to create bill lines that levy charges only when the sum of previously calculated lines is less than the minimum charge amount. The minimum monthly charge shown above would be levied using this type of rate component.

Note that if the values being compared are negative values, the comparison is NOT done on the absolute values, but rather on the actual values. For example, imagine you have a minimum discount of $ -2.00 and previous rate components have calculated a discount of $ -1.00. You want a rate component to create a bill line for $ -1.00 to apply a further discount. A minimum charge rate component will not work in this case because -1 is considered more than -2. For this business scenario you should use a maximum charge rate component.

Maximum Charge

This type of rate component is used to create bill lines that levy charges only when the sum of previously calculated lines is more than the maximum charge amount.

Note that if the values being compared are negative values, the comparison is NOT done on the absolute values, but rather on the actual values. For example, imagine you have a maximum discount of $ -2.00 and previous rate components have calculated a discount of $ -3.00. You want a rate component to create a bill line for $1.00 to reduce the discount. A maximum charge rate component will not work in this case because -3 is considered less than -2. For this business scenario you should use a minimum charge rate component.

Exact Charge

This type of rate component is used to force a bill to add up to a given amount (regardless of how much the bill would be based on earlier rate components).

Calculation Algorithm

This type of rate component enables you to produce bill calculation lines based on logic in an algorithm that you supply. Use this rate component when none of the other rate component functions will provide you with the logic you require.

- For each rate component, determine if the taxpayer must meet some form of eligibility criteria before the rate component is applied. For example, you may have a rate component that is calculated if a taxpayer is a senior citizen. This rate component may have eligibility criteria that requires the person to have a given characteristic value before the rate component is applied. Refer to The Big Picture of Rate Component Eligibility for more information.

- For each type of rate component (except summary), determine how you'll define its unit rate / percent / flat amount. You have four choices:

- Specify the value directly in the rate component.

- Tell the rate component to use the value defined in a rate factor.

- Tell the rate component to use the value calculated by a " for calculation purposes only" rate component.

- Tell the rate component to call an algorithm. The algorithm will return the value.

The following tables provide guidance in respect of which of the methods to use:

Specify value in the rate component

You'd specify the value in the rate component when the value in the rate is specific to that rate and is applied to all taxpayers regardless. For example, if you see a provision in the rate to add a trash fee of $45, you'd specify 45.00 directly in the rate.

Use a rate factor to define the value

The following paragraphs describe when you'd use a rate factor to define a unit rate / percent / flat amount.

The same charge exists in many rates.

The amount being charged varies depending on where the taxpayer lives. If you have a rate where the charge differs depending on where the taxpayer lives, you should use a rate factor to levy this type of charge.

A charge (or discount) is only levied for a subset of taxpayers for defined periods of time.

The charge differs per taxpayer.

Use a "for calculation purposes only" rate component

This is complicated to explain and is not used very often, but it is very powerful and handles some very complicated algorithms. It works like this - you calculate the charge / percent / flat charge on another rate component (marked as "for calculation purposes only" so it won't affect the bill amount), and then reference it on the "real" rate component.

Call an algorithm

This is complicated to explain and is not used very often, but it is very powerful and handles some very complicated examples. It works like this - you call an algorithm and it calculates the charge / percent / charge.

We supply an example of one such algorithm in the base package. If your rates require additional algorithms, you will have to develop additional algorithms. Refer to How to set up rate quantity rate components under Rate Component - Main Information for more information about this type of algorithm.

- After you've categorized the bill lines into the various types and know how the price is defined, you determine how each line's charges are reflected in your general ledger. You will need to work with your accounting department as they will tell you the exact revenue, expense, and liability accounts that will be affected by the charges.

- Finally, read the provisions of your rate (the legal wording) and make sure you haven't left out something. This may involve having to discuss confusing provisions with your legal department.

At this point, you're ready to start entering your rate components.

Rate Component Rounding

The topics in this section describe how to control how each rate component's final value is rounded.

Next in This Section

- Rounding Precision Is Defined On A Rate Component

- Rounding Method Is Defined On A Rate Component

- Rounding And FCPO Rate Components

- Interim Rounding For Apply To Rate Components

- Rounding At The End

Rounding Precision Is Defined On A Rate Component

A rate schedule references a currency code. A rate's currency code defines its maximum number of decimal places. These decimal places, in turn, control the smallest unit to which most rate components can be rounded (i.e., the rate component's precision). For example,

- If a rate's currency has 2 decimal places, the smallest rounding precision that most of its rate components can have is 0.01. In other words, the smallest unit to which most dollar-based rate components can be rounded is to the cent. Note, whether you round up / down / to the nearest is discussed below.

- If a rate's currency has no decimal places, the smallest rounding precision that most of its rate components can have is 1.00.

The system supports the notion of a rate component having a greater rounding precision than its currency. For example, a rate's currency may support 2 decimal places, but you can setup rate components to have a rounding precision of 0.05.

The reason that we underlined the word most in the previous paragraphs is that these rules do not apply to "for calculation purposes only" (FCPO) rate components. FCPO rate components don't contribute real amounts to a bill (they exist to calculate intermediate results that are used by later rate components) and therefore they can support a rounding precision of up to 0.0000001 (7 decimal places).

Rounding Method Is Defined On A Rate Component

When you setup a rate component you must define the rounding method. You are given the following choices:

- Always round up. This rounding method rounds a rate component up to the nearest value (as controlled by the rate component's precision). For example, if a rate component's precision is 0.01 and a value of 0.011 is calculated, the rate component's final value would be rounded up to 0.02.

- Always round down. This rounding method rounds a rate component down to the nearest value (as controlled by the rate component's precision). For example, if a rate component's precision is 0.01 and a value of 0.019 is calculated, the rate component's final value would be rounded down to 0.01.

- Round to the nearest value. This rounding method rounds a rate component to the nearest value (as controlled by the rate component's precision). For example, if a rate component's precision is 0.01 and a value of 0.019 is calculated, the rate component's final value would be rounded up to 0.02. Whereas, if a value of 0.012 is calculated, the rate component's final value would be rounded down to 0.01.

Rounding And FCPO Rate Components

As described above, for calculation purpose only (FCPO) rate components don't contribute real amounts to a bill. FCPO rate components exist to calculate intermediate results that are used by later rate components. We therefore allow FCPO rate components to have a rounding precision greater than the rate's currency code to a maximum of 0.0000001 (7 decimal places).

Please be aware of the following:

- As described under How To Use Description on Bill, you can indicate that the final amount of a bill line should be substituted into the bill line's description by using the %A substitution variable in the rate component's Description On Bill. If you do this for an FCPO rate component, the system will show the number of decimal places as dictated by the FCPO's precision.

- While rate application calculates bill lines, the system maintains each rate component's value in memory. For FCPO rate components, this means that precisions greater than .01 are available during rate application. For example, you could indicate an FCPO rate component has a precision of .0001 and the resultant value will be maintained in memory and is available to other rate components while rate application executes.

When rate application completes, the FCPO's value will be either saved in the bill line's amount or discarded as per the value of the rate component's FCPO retention rule. If you indicate that the FCPO amount should be retained on the bill line and its precision is greater than 2 decimal places, the FCPO amount will be rounded to two decimal places before it's saved on the database. Keep in mind that this could result in an inconsistency if you used the %A substitution variable in the rate component's Description On Bill as the value substituted into the bill line will have a greater precision.

Interim Rounding For Apply To Rate Components

The calculations for Apply To rate components involve several steps with interim values stored along the way. For every interim value that is stored, rounding rules are applied. The following steps describe the interim rounding rules:

- If the value type is not Unit Rate, the amounts for all the "cross-reference" rate components are added together and stored in the database as the Base Amount. The base amount is stored with a precision of .01 and it is rounded to the nearest value based on the currency's precision.

- The rate component calculates its charge and keeps the result in a temporary field with a precision of .00001.

- The temporary field is rounded based on the rate component's rounding rules to produce the final amount.

Rounding At The End

The following is an example of a simple bill segment with three bill lines.

The first two bill lines are calculated using simple rate components that have a precision of .01. The last bill line is special, it rounds the bill up to the next highest 0.05 (this is an example from a country that doesn't have cents, their smallest coin is 0.05). The following would be necessary to calculate the last bill line:

- The rate component would be an exact charge rate component

- Its value (i.e., the exact charge) would be calculated using a value calculation algorithm that sums the first two rate components and rounds them up to the nearest .05. Refer to RCVL-RNDXRF for a value calculation algorithm that can perform this function.

An alternative approach is to do the following:

- Use a summary rate component to calculate the exact charge. This rate component would require the following characteristics:

- FCPO

- Non printing

- Rounding type would be round up

- Precision would be 0.05

- Reference the summary rate component as the exact charge rate component's value

The Big Picture Of Rate Component Eligibility Rules

You can use eligibility rules to define the criteria when a rate component should be applied (or skipped). For example,

- For example, you may have a rate component that is calculated if a taxpayer is a senior citizen. This rate component may have eligibility criteria that require the person to have a given characteristic type and value (this assumes you use a person characteristic to capture the taxpayer's date of birth) before the rate component is applied.

- You may have a rate component that calculates a surcharge if the taxpayer uses 25% more than they used in the same period in prior year.

Note:

Eligibility rules are optional. If you put eligibility rules on a rate component, the rate component will be skipped or applied as per the instructions in the rules. If you don't put eligibility rules on a rate component, the rate component will be executed (i.e., rate components are eligible by default).

The topics in this section describe eligibility rules.

Next in This Section

- A Rate Component Is Eligible By Default

- Criteria Groups versus Eligibility Criteria

- Defining Logical Criteria

- Examples Of Rate Component Eligibility Rules

A Rate Component Is Eligible By Default

If you don't want to setup eligibility rules, you don't have to. If you don't specify eligibility rules on a rate component, it's eligible (i.e., it's going to be processed by rate application).

Criteria Groups versus Eligibility Criteria

Before we provide examples of eligibility criteria, we need to explain two concepts: Criteria Groups and Eligibility Criteria. A rate component's criteria groups control whether rate application executes a rate component. At a high level, it works like this:

- A criteria group has one or more eligibility criteria. A group's criteria control whether the group is considered True or False.

- When you create a group, you define what should happen if the group is True or False. You have the following choices:

- The rate component should be applied

- The rate component should be skipped

- The next group should be checked

We'll use the following example to help illustrate these points. Assume a rate component is only eligible if:

- The taxpayer is a low income taxpayer and has no overdue obligations.

- OR, the taxpayer isn't a low income taxpayer and has no more than one overdue obligation.

This rate component requires two eligibility groups because it has two distinct conditions:

- IF (Taxpayer is low income AND the taxpayer has no overdue obligations)

- IF (Taxpayer is NOT low income AND the taxpayer has no more than one overdue obligation)

If either condition is true, then the rate component is eligible.

You'd need to setup the following criteria groups in order to support this requirement:

Group

No.

Group Description

If Group is True

If Group is False

1

Taxpayer is a low income taxpayer and has no overdue obligations

Eligible

Check next group

2

Taxpayer is NOT a low income taxpayer and has no more than one overdue obligation

Eligible

Ineligible

The following criteria will be required for each of the above groups:

Group 1: Taxpayer is a low income taxpayer and has no overdue obligations

Seq

Logical Criteria

If Eligibility Criteria is True

If Eligibility Criteria is False

If Insufficient Data

10

Taxpayer is low income

Check next condition

Group is false

Group is false

20

Taxpayer has no overdue obligations

Group is true

Group is false

Group is false

Group 2: Taxpayer is NOT a low income taxpayer and has no more than one overdue obligation

Seq

Logical Criteria

If Eligibility Criteria is True

If Eligibility Criteria is False

If Insufficient Data

10

Taxpayer is NOT low income

Check next condition

Group is false

Group is false

20

Taxpayer has no more than one overdue obligation

Group is true

Group is false

Group is false

The next section describes how you'd setup the specific logical criteria in each of the groups.

Defining Logical Criteria

When you setup an eligibility criterion, you must define two things:

- The field to be compared

- The comparison method

You have the following choices in respect of identifying the field to be compared:

- You can retrieve a characteristic value linked to any of the following:

- The obligation being billed

- The obligation's account

- The main person linked to the obligation's account

- The characteristic location linked to the obligation

- The obligation's asset (not supported in this release)

- In addition, you can also use a characteristic value that is derived while the rate is being calculated (characteristic values can be created by RQ rules and many other rate component algorithms)

- You can retrieve the value of a given rate quantity

- You can retrieve the final value of an earlier rate component

- You can execute an algorithm to retrieve a field value from someplace else in the system. This is a very powerful feature, but it's not terribly intuitive. We'll present a few examples later in this section to illustrate the power of this approach.

You have the following choices in respect of identifying the comparison method:

- You can choose an operator (e.g., >, <, =, BETWEEN, IN, etc.) and a comparison value.

- You can execute an algorithm that performs the comparison (and returns True, False or INSUFFICIENT DATA). This is also a very powerful feature, but it's not terribly intuitive. We'll present a few examples later in this section to illustrate the power of this approach.

The Examples Of Rate Component Eligibility Rules provide examples to help you understand this design.

Examples Of Rate Component Eligibility Rules

The topics in this section provide examples about how to setup rate component eligibility rules.

Next in This Section

- A Rate Component With A Time Span Comparison

- A Rate Component With Tax Type Comparison

A Rate Component With A Time Span Comparison

A rate component that is only eligible for senior citizens has the following eligibility rule:

- Birth date equates to that of a senior citizen

This rule requires only one eligibility group on the rate component. It would look as follows:

Group

No.

Group Description

If Group is True

If Group is False

1

Taxpayer Is A Senior Citizen

Apply rate component

Skip rate component

The following criterion is required for this group:

Group 1: Residential, Calif, Senior

Seq

Field to Compare

Comparison Method

If True

If False

If Insufficient Data

10

Main person characteristic: Date of Birth

Algorithm: True if senior

Group is true

Group is false

Group is false

The criterion contains a time span comparison. Time span comparisons are used to compare a date to something. In our example, we have to determine the age of the taxpayer based on their birth date. If the resultant age is > 65, they are considered to be a senior citizen. To pull this off, you can take advantage of a comparison algorithm supplied with the base rate component as described below.

- Field to Compare. The person characteristic in which the taxpayer's birth date is held is selected.

- Comparison Method. We chose a comparison algorithm that returns a value of True if the related field value (the taxpayer's date of birth) is greater than 65 years (refer to RECC-TIMESPN for an example of this type of algorithm).

You'll notice that if a value of True is returned by the True if senior algorithm, the group is true (and we've setup the group to indicate a true group means the rate component is eligible).

Note:

The time span algorithm can be used to compare days, weeks, months, etc. Refer to RECC-TIMESPN for more information about this algorithm.

A Rate Component With Tax Type Comparison

Imagine a rate component that is only eligible if the current taxpayer has two tax types. This rate component would need the following eligibility rules:

- Taxpayer has real property taxes, and

- Taxpayer has personal property taxes.

These rules require only one eligibility group on the rate component. It would looks as follows:

Group

No.

Group Description

If Group is True

If Group is False

1

Has real property AND personal property taxes

Apply rate component

Skip rate component

The following criteria will be required for this group:

Group 1: Has real property AND personal property taxes

Seq

Field to Compare

Comparison Method

If True

If False

If Insufficient Data

10

Algorithm: check if taxpayer has real property taxes

= True

Check next condition

Group is false

Group is false

20

Algorithm: check if taxpayer has personal property taxes

= True

Group is true

Group is false

Group is false

Both criteria are similar - they call an algorithm that performs a logical comparison. These algorithms are a bit counter intuitive (but understanding them will provide you with another way to implement complex eligibility criteria):

Both criterion works as follows:

- Field to Compare. We chose a "field to compare" algorithm that checks if the current account has obligations that belong to a given set of tax types. It returns a value of True if the taxpayer has an active obligation that matches one of the tax types in the algorithm. In our example, the "check if taxpayer has real property taxes" algorithm returns a value of True if the taxpayer has at least one active obligation whose obligation type references the real property tax type. The "check if taxpayer has property taxes" algorithm is almost identical, only the tax type differs. Refer to RECF-SRVTY and RECF-AUTOPAY for examples of this type of algorithm.

- Comparison Method. We simply compare the value returned by the algorithm to True and indicate the appropriate response.

Note:

Bottom line. The "field to compare" algorithm isn't actually returning a specific field's value. Rather, it's returning a value of True or False. This value is, in turn, compared by the "comparison method" and the group is set to true, false or check next accordingly.

Defining Rate Components

CAUTION:

We strongly recommend that you familiarize yourself with the information under Designing Rate Components before using this transaction.

Rate components control exactly how your bill calculation lines are calculated. Every rate component exist in respect of a given rate version. This is because the rate version defines the date on which all of its rate components become effective.

Note:

Copying, delete and moving rate components. You can use the rate component maintenance transaction to duplicate, delete and move rate components. However, you may find these functions are easier to do using the Rate Version Merge transaction as this transaction can copy en masse and it also updates the relevant cross reference information if you move or delete a rate component.

The topics in this section describe how to maintain a rate component.

Note:

Don't forget to finish the rate version. After you have added all necessary rate components to a rate version, don't forget to return to Rate Version - Main and change the state of the rate version to Finished (otherwise, it cannot be used by billing).

Next in This Section

- Rate Component - Main Information

- Rate Component - Cross Reference

- Rate Component - GL Distribution

- Rate Component - Characteristics

- Rate Component - Eligibility

Rate Component - Main Information

Core information about a rate component is defined using Menu > Rates > Rate Component .

Description of Page

Rate Component contains a concatenation of basic information about the rate component. This information only appears after the rate component has been added to the database. The adjacent up and down arrows cause the rate component immediately before or after this rate component to be displayed.

Rate Version defines the rate version to which the rate component is linked. Sequence defines the relative position of this rate component in respect of the other rate components. The position is important because it defines the order in which the system calculates the charges AND the order in which the calculated charges appear on bills. Rate Version and Sequence form the unique identifier of the rate component. Both fields become protected after the rate component is added to the database.

Note:

Re-sequencing rate components. You must use the Rate Version Merge transaction to reposition a rate component. If you use the up / down arrows on the Rate Version Merge, the system will change the rate component's Sequence and change all rate components that reference the old Sequence accordingly.

Note:

Leave gaps in the sequence numbers. Make sure you leave space between sequence numbers so that you can add new rate components between existing ones in the future. If you run out of space between rate components, you can use the Rate Version Merge transaction to re-sequence a rate version's rate components.

Note:

Eligibility criteria are highlighted. If the rate component has eligibility criteria, an indication of such appears.

Select the Rate Component Type that corresponds with the rate component. The screen will display the appropriate fields, which correspond with the categories of rate components described in Designing Rate Components. This field will be gray when the rate component is referenced on other rate components.

CAUTION:

The Rate Component Type affects what you can enter on other parts of the window. The remainder of this section is devoted to those fields that can be entered regardless of RC Type. The subtopics that follow describe those fields whose entry is contingent on the RC Type.

Use Description to describe what the rate component does.

Rounding Type and Precision control how the system rounds the rate component's calculated value. Refer to Rate Component Rounding for a complete description.

Note:

Default note. Rounding Type defaults to Nearest and Precision defaults to a value consistent with the decimal positions defined on the rate schedule's currency code.

Turn on For Calculation Purposes Only (FCPO) if this rate component exists purely to calculate the percent / flat rate / unit rate used by another rate component. When this switch is on, the system does not include the calculated amount in the bill total.

When this switch is on:

- You must define what is calculated in Result Type; permissible values are Unit Rate, Charge, Step Multiplier and Percentage.

- Use Create a Bill Line to define if a bill line should be created for the rate component (if you don't need to show the results to the taxpayer or a user, there is no need to create a bill line).

- If a bill line is being created, use the FCPO Retention Rule to define if the FCPO amount should be set to zero on the bill line or whether the bill line's amount should be set equal to the FCPO amount.

For each rate component, you will need to select the Value Type and Value Source. Valid values for the Value Type are Charge, Percentage and Unit Rate. More information to help determine which value type to choose is described in the How To sections below. Based on the Value Source entered, the remainder of this row will change.

If the Value Source is Rate Factor, then a prompt to indicate the Rate Factor will appear.

If the Value Source is Other Rate Component, then a prompt to indicate the RC Sequence will appear.

If the Value Source is Value, then a prompt to indicate the Value directly on the rate component will appear.

If the Value Source is Value Algorithm, then a prompt to indicate the Value Algorithm will appear.

If you plan to use this method, you must set up this algorithm in the system. This can be done with the following options:

- Create a new algorithm (refer to Setting Up Algorithms).

- On this algorithm, reference an Algorithm Type that calculates a rate component's value. Click here to see the algorithm types available for this plug-in spot.

Fastpath:

For more information about which method to use, refer to Designing Rate Components.

If the charges associated with the rate component are only levied during a specific season, you must turn on the Seasonal options.

When Seasonal is turned on, you use Prorate Method to define how the system should prorate a seasonal charge when a bill segment's start and end dates are not entirely within the seasonal period (defined in Season). The following options are available:

- Accounting Date Dependent. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the accounting date associated with the bill segment is within the seasonal period.

- Bill End Date. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the bill segment end date is within the seasonal period.

- Bill Start Date. This option will not prorate the charge calculated by this rate component. Rather, it will only calculate the charge if the bill segment start date is within the seasonal period.

- Prorate. This option will prorate the charge calculated by this rate component based on the number of days in the adjacent season that is included in the bill period. For example, if a bill period is from 15-April through 15-May and the seasonal period is from 1-May through 31-October, the system will assume 15 / 30 of the charge should be levied.

- Prorate seasonal RQ. This option is only pertinent if you have:

- Seasonal rate quantity (RQ) charges, AND

- You have a bill that crosses seasonal boundaries, AND

- You have multiple rate versions effective across the bill period.

If this option is used, the system will prorate the charge calculated by a RQ rate component based on the number of days in the adjacent season that is included in the rate version's calculation period.

Note:

The Seasonal period is defined in the two adjacent fields. The first field contains the day and month when the season starts; the second field contains the day and month when the season ends. The day and month should be entered in the format defined in your display profile.

Note:

Override Seasonal Proration. If the seasonal functionality provided with the system does not work for your organization, you may override the logic using the Override Seasonal Proration plug-in spot on the installation record.

Description On Bill, Print, and Print If Zero all control if the rate component contributes a line to the taxpayer's bill. These fields can also be modified on Rate Version - Bill Print Info. You might find it easier to setup these fields on the rate version transaction as you can copy and paste descriptions between rate components. Refer to Rate Version - Bill Print Info for a description of these fields.

The other fields on this page are dependent on the type of rate component. See the "how to" subtopics below for more information.

Next in This Section

- How To

How To

The topics in this section describe how to set up certain types of rate components.

Next in This Section

- How To Set Up Flat Charge Rate Components

- How To Set Up Rate Quantity Rate Components

- How To Set Up Apply To Rate Components

- How To Set Up Maximum Charge Rate Components

- How To Set Up Minimum Charge Rate Components

- How To Set Up Exact Charge Rate Components

- How To Set Up Summary Rate Components

- How To Set Up Calculation Algorithm Rate Components

How To Set Up Flat Charge Rate Components

There are no special additional fields on this page available for setting up a Flat rate component. The following information will help you determine how to set up your Flat rate components.

The Value Type in this case would be Charge. This field will be gray when the rate component is referenced on another rate component.

Refer to Rate Component - Main Information for information about defining the Value Source.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the GL Distribution window to define how to book moneys associated with this rate component in the general ledger.

How To Set Up Rate Quantity Rate Components

When setting up an RQ rate component, additional fields become available for you to define.

The following information will help you to set up your RQ rate components.

Select a Value Type of Unit Rate if the type of charge is an amount per some unit/quantity. In the rare situation where the amount of the charge is flat for the first X units, use the Value Type of Charge. This field will be gray when the rate component is referenced on another rate component.

Refer to Rate Component - Main Information for information about defining the Value Source.

The amount that you specified using the rate factor / value field was a rate per some unit of some thing. This thing must be identified using the Unit Of Measure, Time Of Use, and Rate Qty. Identifier fields.

Turn on Measures Peak Qty if you do not want this rate component to prorate.

Note:

Default note. The value of Measures Peak Qty is defaulted from the UOM table (if a UOM is specified).

Turn on GL Statistical Quantity if GL journal lines generated for this rate component should also contain the rate quantity amount as a statistical quantity. You would use this option if you keep track of both dollar amounts and consumption units in your general ledger.

CAUTION:

When a bill segment is created, the system stores the statistical quantity on the journal line associated with the rate component's distribution code. If you book multiple UOM's to the same distribution code, you should only turn on GL Statistical Qty on one of the rate components. Otherwise, you will commingle different UOM's on a journal line's statistical quantity.

If the charge is only applicable to a quantity within some tier, indicate that the rate component is Stepped. When this option is turned on, you must indicate the Step Low Value and Step High Value that the charge is applicable to. When multiple tiers exist, the high value of the first tier is the low value of the second tier (and so on).

If the step boundaries are dynamic (i.e., they are calculated based on something that's only known at billing time), you can change the step boundaries using either of the following methods:

- Use Step RC Sequence to indicate the sequence number of the rate component whose value will be multiplied by the step's boundaries to calculate the step boundaries to use at billing time.

- Use Step Algorithm to indicate that an algorithm will be called to manipulate the step boundaries (note, this algorithm can manipulate the low and/or high boundaries). If you plan to use this method, you must set up this algorithm in the system. To do this:

- Create a new algorithm (refer to Setting Up Algorithms).

- On this algorithm, reference an Algorithm Type that manipulates a rate component's step boundaries. Click here to see the algorithm types available for this plug-in spot.

CAUTION:

If you dynamically calculate step boundaries and the resultant high AND low values become zero, this signals the system that the rate component should be skipped (i.e., no bill line will be produced for the rate component).

Turn on Error if No Value if a bill error should be generated if the UOM / TOU / RQI specified on the rate component was not supplied at billing time.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the GL Distribution window to define how to book moneys associated with this rate component in the general ledger.

How To Set Up Apply To Rate Components

There are no special additional fields on this page available for setting up an Apply To rate component. The following information will help you determine how to set up your Apply To rate components.

Select a Value Type of Percent if the type of charge is a percent of the dollar value of previously calculated rate components. If the amount being charged is an amount per some unit of quantity or measure, select the Value Type of Unit Rate. This field will be gray when the rate component references other rate components.

Refer to Rate Component - Main Information for information about defining the Value Source.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the Cross Reference window to define the rate components to which the charge will be applied.

Move to the GL Distribution window to define how to book moneys associated with this rate component in the general ledger.

How To Set Up Maximum Charge Rate Components

There are no special additional fields on this page available for setting up a Maximum rate component. The following information will help you determine how to set up your Maximum rate components.

Select a Value Type of Charge.

Refer to Rate Component - Main Information for information about defining the Value Source.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the Cross Reference page to define the rate components against which the maximum charge will be applied.

Move to the GL Distribution page to define how any additional revenue associated with the maximum charge should be booked in the general ledger.

How To Set Up Minimum Charge Rate Components

There are no special additional fields on this page available for setting up a Minimum rate component. The following information will help you determine how to set up your Minimum rate components.

Select a Value Type of Charge.

Refer to Rate Component - Main Information for information about defining the Value Source.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the Cross Reference window to define the rate components against which the minimum charge will be applied.

Move to the GL Distribution window to define how any additional revenue associated with the minimum charge should be booked in the general ledger.

How To Set Up Exact Charge Rate Components

There are no special additional fields on this page available for setting up an Exact Charge rate component. The following information will help you determine how to set up your Exact Charge rate components.

Select a Value Type of Charge.

Refer to Rate Component - Main Information for information about defining the Value Source.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the Cross Reference window to define the rate components against which the exact charge will be applied.

Move to the GL Distribution window to define how any additional revenue associated with the minimum charge should be booked in the general ledger.

How To Set Up Summary Rate Components

Summary rate components use no other fields on this page other than those defined above.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the Cross Reference window to define the rate components to summarize on this rate component.

How To Set Up Calculation Algorithm Rate Components

Calculation Algorithm rate components are used when none of the other rate components will provide you with the functionality you need.

First, you must select a Calc Algorithm. This calculation algorithm will have the responsibility of producing your bill lines. All rate component options become available when you use this rate component type, based on the assumption that it is generally capable of doing anything you might require.

If you plan to use this method, you must set up this algorithm in the system. This can be done with the following options:

- Create a new algorithm (refer to Setting Up Algorithms).

- On this algorithm, reference an Algorithm Type that calculates a rate component. Click here to see the algorithm types available for this plug-in spot.

Note:

Note. The calculation algorithm's main purpose is to create bill calculation lines. However, the algorithm may populate other information for the bill, for example, it may add to the RQ or it may overwrite the description on bill.

If you wish to provide your users with the ability to audit the bill lines created by a rate component of this type, you may indicate an Audit Algorithm.

All the other fields on the page are optional fields available to you for use by your calculation algorithm.

Turn on Error if No Value if a bill error should be generated if the UOM / TOU / RQI specified on the rate component was not supplied at billing time.

Turn on the Derive RQ switch when your calculation algorithm will be creating entries in the RQ array for the UOM / TOU / RQI defined on your rate component. In this case, the system will not attempt to locate an entry in the RQ collection matching the rate component's UOM / TOU / RQI before calling your calculation algorithm.

Enter the verbiage to appear on the taxpayer's bill in Description On Bill and turn on the Print switch. Refer to How To Use Description on Bill for more information about these fields.

Move to the GL Distribution window to define how any additional revenue associated with the minimum charge should be booked in the general ledger.

Rate Component - Cross Reference

Minimum charge, maximum charge, exact charge, apply-to, and summary rate components reference other rate components. For these types of rate components, open Menu > Rates > Rate Component and navigate to the Cross Reference tab define the other rate components to which it refers.

Description of Page

Rate Component contains a concatenation of basic information about the rate component. This information only appears after the rate component has been added to the database. The adjacent up and down arrows cause the rate component immediately before or after this rate component to be displayed.

Use the Apply this Rate Component to collection to specify the other rate component(s) on the Rate Version to which the rate component in question should refer. The list of rate components available for reference is displayed on the right. Use the left arrow to move the desired rate components into the grid. If a rate component appears in the 'apply to' list in error, use the left arrow to remove the rate component.

Fastpath:

Refer to Editable Grid in the system wide standards documentation for more information about adding records to a collection by selecting from a list.

Note:

An apply to rate component that has a charge type of unit rate can only reference RQ and calculation rate components. Apply to rate components with a charge type of percentage, along with summary, minimum charge, maximum charge and exact charge rate components can reference all types of rate components including summary.

The This RC is referenced by collection indicates what other rate components reference the rate component in question.

Rate Component - GL Distribution

Open Menu > Rates > Rate Component and navigate to the GL Distribution tab to define each rate component's effect on the general ledger. GL distribution information is required for all rate components except for FCPO and summary rate components.

Description of Page

Rate Component contains a concatenation of basic information about the rate component. This information only appears after the rate component has been added to the database. The adjacent up and down arrows cause the rate component immediately before or after this rate component to be displayed.

If the rate component's charges should be booked to a single GL account regardless of the obligation's obligation type's Revenue Class, enter a Distribution Code. If the rate component's charges are booked to a different GL account depending on the obligation's Revenue Class, turn on Use Revenue Class and insert the appropriate Revenue Class and Distribution Code for each that uses the rate.

Rate Component - Characteristics

Your algorithms and reports may need additional rate component fields that aren't supported in the base-package. If so, you can set up a rate component characteristic for each such field.

Note:

Snapshotting characteristics on bill calculation lines. The system will automatically copy a rate component's characteristics onto the resultant bill lines for those characteristic types that are usable on bill lines.

Open Menu > Rates > Rate Component and navigate to the Characteristics tab to define characteristic values for your rate component.

Description of Page

For each characteristic in the collection, indicate the appropriate Characteristic Type and Characteristic Value.

Note:

You can only choose characteristic types defined as permissible on the rate schedule record. Refer to Setting Up Characteristic Types & Their Values for more information.

Rate Component - Eligibility

This page is used to define the conditions under which a rate component will be applied. If you don't specify any Eligibility Criteria Groups, the system assumes the rate component should be applied (i.e., a rate component is eligible by default).

Fastpath:

Refer to The Big Picture Of Rate Component Eligibility for more information.

Open this page using Menu > Rates > Rate Component and navigate to the Eligibility tab.

Description of Page

Rate Component contains a concatenation of basic information about the rate component. This information only appears after the rate component has been added to the database. The adjacent up and down arrows cause the rate component immediately before or after this rate component to be displayed.

CAUTION:

The following information is not intuitive; we strongly recommend that you follow the guidelines under The Big Picture Of Rate Component Eligibility before attempting to enter this information.

The Eligibility Criteria Group scroll contains one entry for each group of eligibility criteria. The following fields may be defined for each group:

- Use Sort Sequence to control the relative order in which the group is executed when the system determines if the rate component should be applied (smaller numbers are executed before larger numbers).

- Use Description and Long Description to describe the criteria group.

- Use If Group is True to define what should happen if the eligibility criteria (defined in the following grid) return a value of True.

- Choose Apply Rate Component if this rate component should be executed.

- Choose Check Next Group if the next criteria group should be checked.

- Choose Skip Rate Component if this rate component should NOT be executed.

- Use If Group is False to define what should happen if the eligibility criteria (defined in the following grid) return a value of False.

- Choose Apply Rate Component if this rate component should be executed.

- Choose Check Next Group if the next criteria group should be checked.

- Choose Skip Rate Component if this rate component should NOT be executed.

The grid that follows contains the rate component's eligibility criteria. Think of each row as an "if statement" that can result in the related eligibility group being True or False. For example, you might have a row that indicates the taxpayer is eligible for the rate component if the taxpayer's birth date equates to that of a senior citizen. The following bullets provide a brief description of each field on an eligibility criterion. Please refer to Defining Logical Criteria for several examples of how this information can be used.

- Use Sequence to control the order in which the criteria are checked.

- Use Criteria Field to define the field to compare:

- Choose Characteristic if you want to compare a characteristic value that resides on any of the following to a given value (use the adjacent fields to define the object on which the characteristic resides and the characteristic type):

- The obligation being billed

- The obligation's account

- The main person linked to the obligation's account

- The characteristic location linked to the obligation

- The obligation's asset (not supported in this release)

- In addition, you can also use a characteristic value that is derived while the rate is being calculated (characteristic values can be created by RQ rules and many other rate component algorithms)

- Choose Rate Component Value if you want to compare the final value of an earlier rate component to a given value. Push the adjacent search button to select the rate component's sequence number.

- Choose Rate Quantity if you want to compare the final value of a rate quantity to a given value. Push the adjacent search button to select the rate quantity's UOM / TOU / RQI.

- Choose Algorithm if you want to compare anything other than the above options. Push the adjacent search button to select the algorithm that is responsible for retrieving the comparison value.

- Use Criteria Comparison to define the method of comparison:

- Choose Algorithm if you want an algorithm to perform the comparison and return a value of True, False or Insufficient Data.

- Choose any other option if you want to compare the Criteria Field using a logical operator. The following options are available:

- Use >, <, =, >=, <=, <> (not equal) to compare the Criteria Field using standard logical operators. Enter the comparison value in the adjacent field.

- Use IN to compare the Criteria Field to a list of values. Each value is separated by a comma. For example, if a field value must equal 1, 3 or 9, you would enter a comparison value of 1,3,9.

- Use BETWEEN to compare the Criteria Field to a range of values. For example, if a field value must be between 1 and 9, you would enter a comparison value of 1,9. Note, the comparison is inclusive of the low and high values.

- The next three fields control whether the related logical criteria cause the eligibility group to be considered True or False:

- Use If True to control what happens if the related logical criterion returns a value of True. You have the options of Group is true, Group is false, or Check next condition. If you indicate Group is true or Group is false, then the rate component will be Skipped or Applied based on the values defined above in If Group is False and If Group is True.

- Use If False to control what happens if the related logical criterion returns a value of False. You have the options of Group is true, Group is false, or Check next condition. If you indicate Group is true or Group is false, then the rate component will be Skipped or Applied based on the values defined above in If Group is False and If Group is True.

- Use If Insufficient Data to control what happens if the related logical criterion returns a value of "Insufficient Data". You have the options of Group is true, Group is false, or Check next condition. If you indicate Group is true or Group is false, then the rate component will be Skipped or Applied based on the values defined above in If Group is False and If Group is True.

Rate Version Merge

The following point summarize the many diverse functions available on this transaction:

- A rate version's rate components have unique sequence numbers. This number controls the order in which a rate component is processed. If you need to insert a rate component and there's no space between existing sequence numbers, you can use this transaction to renumber the rate version's rate components.

- You can use this transaction to move a rate component to a different position within a rate version. When a rate version is moved, all references to the rate component are changed to reflect the new sequence number.

- You can use this transaction to delete a rate component. When a rate component is deleted, all references to the rate component are deleted.

- You can use this transaction to copy rate components from other rate versions. For example,

- You may want to create a rate version that is similar to an existing rate version. Rather than copying all the information from the existing rate version and then removing the inapplicable components, this page may be used to selectively copy specific rate components from the existing rate version to the new rate version.

- You may have taxpayer-specific rates that are very similar, but still unique. You can use this transaction to build a taxpayer-specific rate. In this scenario, you may choose to create special 'mini' rate versions, one for each of the various options. Then, you could use the rate version merge page to select the components applicable for the new custom rate version.

Note: The target rate version must exist prior to using this page. If you are creating a new rate, you must first create the Rate Schedule and Rate Version and then navigate to the merge page to copy rate component information.

Note: Duplicate versus Merge. The Rate Version page itself has duplication capability. You would duplicate a rate version if you want to a) create a new rate version AND b) populate it with all the rate components from an existing rate version. The Rate Component Maintenance transaction also allows you to duplicate a rate component within a rate version.

Use Menu > Rates > Rate Version Merge to open this page.

Description of Page

Select the Original Rate Version, which is the target for merging the rate component information.

Note: Finished rate versions are protected. Only rate versions that are In Progress or Validated may be used as the target rate version in the merge functionality. If any changes are made to a Validated rate version on this page, the system will move the status back to In Progress. If a rate version with a status of Finished is selected, it will be displayed, but you will be unable to copy any information to it (and its description will appear in red). If you need to make changes to a Finished rate version, navigate to Rate Version - Main and change the rate version's status to In Progress. Refer to Lifecycle of a Rate Version for more information.

Select the Merge From Rate Version, which is your template rate version to copy the rate components from.

Note: You may only copy components from one Merge From rate version at a time. If you want to copy components from more than one rate version, select the first Merge From rate version, copy the desired records, Save, and then select the next Merge From rate version.

The left portion of the page displays any existing rate components for the Original Rate Version. The right portion of the page displays the existing rate components for the Merge From Rate Version.

You can use the Copy All button to copy all the rate components from the Merge From rate to the Original rate. If you use Copy All, please be aware that the rate components are added to the end of the Original rate version.

Each time you save the changes, the system renumbers the Original rate version using the Start From Sequence Number and Increment By.

The left portion of the page initially displays existing rate component records linked to the original rate version. In the Merge Type, you will see the word Original, for any of these records. The Sequence, RC Type and Description for each rate component are displayed. In the right portion of the page, the existing records in the merge from rate version are displayed initially.

The topics that follow describe how to perform common maintenance tasks:

Next in This Section

- Resequencing Rate Components

- Removing A Row From A Grid

- Adding A New Row To A Rate

- Removing An Uncommitted Row From A Rate

- Moving Positional Rows Up and Down

- Rate Component Cross Reference Information

Resequencing Rate Components

If there are no gaps between two rate components and you need to resequence the rate components:

- Make a change to the Start From Sequence Number or Increment By (so that the Save button becomes enabled).

- Click the Save button.

Removing A Row From A Grid

If you wish to remove a record linked to the Original rate version, press the "-" button to the left of the record.

Adding A New Row To A Rate

You may move any of the rate components from the Merge From rate version to the original rate version 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.

Removing An Uncommitted Row From A Rate

If you have copied a row across by mistake, you may remove it by clicking on the right arrow adjacent to the appropriate record.

Moving Positional Rows Up and Down

A rate component's sequence number controls the order in which the rate component should be applied. You may modify the order execution using the up and down arrows.

The sequences need to be renumbered in order to ensure the correct order. The fields Start from Sequence Number and Increment By are used to define the sequence number to assign to the first rate component and the subsequent values to assign to subsequent rate components.

Fastpath:

Refer to Editable Grid in the system wide standards documentation for more information about adding records to a collection by selecting from a list and repositioning rows within a grid.

Rate Component Cross Reference Information

All information related to a rate component, including general ledger information, characteristics and eligibility rules, will be copied.

Special logic exists for merged rate components that reference other rate components. This includes the cross reference collection and the eligibility criteria.

If any rate component refers to another rate component in the eligibility criteria, the sequence number of the eligibility criteria is also adjusted accordingly.

Note: You will be warned by the system when you copy a rate component that has cross-references to other rate components that are not being copied.

Rate Check

The Rate Check page allows you to test your rates under various scenarios. The topics in this section describe how to use this transaction.

Next in This Section

- Rate Check - Main

- Rate Check Results - Calc Lines

- Rate Check Results - RQ Details

- Rate Check Results - Calculation Details

- Rate Check Results - Characteristics

Rate Check - Main

Open Menu > Rates > Rate Check to enter the parameters required to check a rate.

Description of Page

Note: Easiest way to use rate check. The easiest way to populate the above parameters is to select an existing bill segment on Bill Segment - Calc Lines and then use the rate schedule context menu to navigate to this transaction. When you do this, the system populates the above fields from the values on the bill segment. After these fields are populated, you can override the defaulted values to check various scenarios.

Indicate the Rate Schedule that you want to test. The version(s) used will be those in effect during the start and end dates. Only validated and finished rate versions will be used.

Note: Default note. If Rate Schedule is blank and you enter an Obligation ID, the obligation's current rate will be defaulted.

While using an Obligation ID is not strictly required to check a rate, we strongly recommend finding a representative obligation to check a rate. Why? Because charges in a rate may be affected by values in an obligation. For example, a rate component may have RQ rules that use characteristics on obligation, account or the obligation's characteristic location.

Enter a Bill Seg ID if you want to test the rate with actual quantities for a given bill segment. This is useful if you want to compare the actual bill segment results with the results of the same calculation values under a different rate schedule. If you indicate a Bill Seg ID, rate check's Obligation ID will be populated with the bill segment's obligation ID (and Obligation ID will be protected).

Note:

Overriding quantities. If you enter a Bill Seg ID, the bill segment's quantities will be defaulted into the array that follows. You may override the quantities in this array to test various scenarios.

You must indicate a Revenue Class. This is needed for applying the appropriate GL distribution code for rate components where the GL account is based on the taxpayer's revenue class.

Enter the Start Date and End Date that you are testing. If a Bill Seg ID is entered, the start and end dates are taken from the bill segment's period, but can be overwritten.

Indicate the Accounting Date. If a Bill Seg ID is entered, the accounting date on the bill segment is used but can be overwritten.

Enter the quantities that you want to test in the quantity collection. For every UOM/ TOD/ RQI combination, enter a quantity.

The collection of Characteristic Types and Characteristic Values is used to apply the appropriate rate factor values. If these values are entered, these values will be used to apply the appropriate rate factors (even if you have specified an obligation from which characteristics can be derived). If these values are blank AND there is no obligation ID, then you will receive an error from the rate application indicating which values are needed.

Indicate the Bill Language to use for the resulting bill calc line descriptions.

When you have entered everything, click on the Check Rate button. This will cause your rate to be applied to the parameters entered above. If the system is successful, you will be transferred to the Calc Lines page on which the resulting calculation details can be viewed.

Rate Check Results - Calc Lines

After you have pressed the Check Rate button on the Main page, you will be transferred to the Calc Lines tab to view the lines that have been calculated by your rate.

Description of Page

The Rate Schedule and its description, the Revenue Class and its description and the Bill Period are displayed at the top.

More than one Rate Version may have been effective for the Rate Schedule during this bill period. If so, multiple collections of calculation lines will be produced. Use the Bill Seg Hdr scroll to view each collection of calculation lines.

For each Bill Seg Header, the following information will be displayed above the calculation line grid.

Sequence

This identifies which Bill Seg Header is being displayed.

Start Date, End Date

This is the period, within the bill period, that the rate version, which produced these lines, was effective.

Amount

This is the total amount calculated by this group of calculation lines.

Desc on Bill

The description on bill for the rate version that produced these lines.

Rate Version

The rate version that was used to produce these lines.

The grid, which displays the bill calculation lines for this rate version, shows one row exists for every calculation involved in this process. This information is very similar to what is displayed on the bill calculation lines page for a bill segment. The following information is displayed in the grid:

- Sequence is the system-assigned unique identifier of the calculation detail row.

- Description on Bill is the information about the bill line that appears on the taxpayer's bill.

- Calculated Amount is the calculated amount associated with the bill line.

- Calculated Value is the same value as the Calculated Amount except that it displays 5 decimals.

- The Print switch controls whether information about this line will print on the taxpayer's bill.

- The Appears in Summary switch defines if this line's amount also appears on a summary line. This switch is turned on if the corresponding rate component is summarized on a summary rate component.

- UOM is the unit of measure of the rate quantity on the calculation line.

- TOU is the time-of-use code of the rate quantity on the calculation line.

- RQI is the rate quantity identifier of the rate quantity on the calculation line.

- Billable Rate Quantity is the rate quantity on the calculation line.

- Base Amount is used by calculation lines (e.g. taxes) that are cross-referenced to other calculation lines and whose value(s), therefore, depend on the amounts calculated by those other lines. The Base Amount shows the total amount derived from the cross-referenced line(s) that the current line then used to calculate its billed amount.

- Sequence refers to the sequence number of the rate component on the applicable rate version that was used to calculate the line.

- Meas Peak Qty is checked if the UOM on the calculation line is used to measure a peak quantity.

- Exempt Amount is not used at this time.

- Distribution Code is the distribution code associated with the calculation line. This distribution code is used to build the general ledger details on the bill segment's financial transaction.

Rate Check Results - RQ Details

After you have pressed the Check Rate button on the Main page, you can navigate to the RQ Details tab to view the rate quantities that supplied to (or derived by) you rate. Please be aware that a rate can derive rate quantities if there are rate quantity rules rate components.

Description of Page

The Rate Schedule and its description, the Revenue Class and its description and the Bill Period are displayed at the top.

The RQ details grid is a snapshot of the rate quantities amassed from:

- The quantities input on the main page OR the quantities taken from the rate quantity collection for the bill segment, if it was input on the main page.

- The RQ rules defined on the input rate.

The following information is displayed in the grid:

- UOM is the unit of measure of the rate quantity.

- TOU is the time-of-use code of the rate quantity.

- RQI is the rate quantity identifier of the rate quantity.

- Initial Rate Quantity is the initial quantity amassed by the system before application of the rate's RQ rules.

- Billable Rate Quantity is the rate quantity that will be used by the obligation's rate.

Rate Check Results - Calculation Details

After you have pressed the Check Rate button on the Main page, you can navigate to the Register Read tab to view the final quantities (Final UOM, Final TOU and Final RQI) that were derived by your rate.

Description of Page

The Rate Schedule and its description, the Revenue Class and its description and the Bill Period are displayed at the top.

This page displays measured quantities from one of two places:

- From the values input on the main page of Rate Check

- From the quantities collection for the bill segment indicated on the main page of Rate Check

The following information is displayed in the grid:

- UOM is the unit of measure of the quantity.

- TOU is the time-of-use code of the quantity.

- RQI is the rate quantity identifier of the quantity.

- Quantity is the initial quantity amassed by the system before application of the rate's register rules.

- Final UOM is the unit of measure of the resultant billing quantity.

- Final TOU is the time-of-use code of the resultant billing quantity.

- Final RQI is the rate quantity identifier of the resultant billing quantity.

- Final Quantity is the resultant billing quantity.

Rate Check Results - Characteristics

After you have pressed the Check Rate button on the Main page, you can navigate to the Characteristics tab to view the final characteristics collection as manipulated by your rate's plug-ins.

Description of Page

The Rate Schedule and its description, the Revenue Class and its description and the Bill Period are displayed at the top.

The collection of Characteristic Types and Characteristic Values reflects any changes made to the initial characteristics collection (input on the main tab page) after applying the rate.

Effective Dates & Proration

In this section, we describe how proration applies to different types of rate components. Proration implies assessing charges proportionately.

The term "proration" describes two different issues:

- Prorating a charge whose value changes during a bill period. For example, if a tax rate changes during a bill period and you've indicated that such changes should be prorated, the system prorates the tax change (e.g., 20 days at 5% and 10 days at 6%).

- Prorating charges when the time period being billed is not in sync with the time period in which the charges were defined in the rate. For example, if a rate contains a flat monthly charge and the bill period spans two months, the flat charge must be prorated.

This is a complicated topic as it's possible for many proration issues to exist on a single bill. For example, on a single bill:

- The rate structure can change several times during the bill period (i.e., multiple rate versions are effective).

- The taxing authority changes the tax rate.

Next in This Section

- Types of Proration

- Proration Factors

- Overriding Proration Factors

- Rate Quantity Proration

- Rate Component Value Proration

- Rate Factor Value Proration

Types of Proration

The following section describes the types of proration performed by applying a rate.

Fastpath:

For more information on how prorated charges are presented on the printed bill, refer to How To Use Description On Bill.

Next in This Section

- Rate Calculation Period Proration

- Rate Factor Proration

- Obligation Rate Changes Are Not Prorated

Rate Calculation Period Proration

There can be multiple versions of a given rate over time. Each version has an effective date. When the system detects that a rate schedule has multiple versions of a rate in effect during a bill period, it may or may not prorate the charges. You control exactly how the system handles this situation using the rate schedule's proration parameters.

If multiple rate versions are effective during the period and the rate schedule is configured to prorate the rate versions, a given bill segment will contain a set of bill calculation lines for each rate version. You should consider quite carefully how to handle this situation on your printed bills as rate version proration can confuse a taxpayer.

Fastpath:

Refer to Defining Rate Versions for more information about rate versions.

Rate Factor Proration

A rate contains rate components. When you create rate components, you have two ways to indicate how much to charge:

- You can specify the value directly in a rate component.

- You can have the rate component use a rate factor that contains the value.

Rate factors are effective-dated (i.e., their values may change over time). When the system detects that a rate component's rate factor has multiple values in effect during a period, it may or may not prorate the charges. You control exactly how the system handles this situation using the rate factor's proration parameters.

Fastpath:

Refer to Defining Rate Factors and Rate Factor Value Proration for more information.

Obligation Rate Changes Are Not Prorated

An obligation's rate is effective-dated (i.e., it may change over time). When the system calculates an obligation's bill segment when multiple rates are effective during the bill period, it will use a single rate from the obligation's rate history. The system chooses the rate as per the obligation's obligation type's rate selection date.

Fastpath:

Refer to Obligation Type - Rate for more information.

Proration Factors

The purpose of rate components is to generate bill calculation lines. When rate application builds bill calculation lines, it may also prorate the charges.

There are multiple types of proration performed by rate application. Rate quantities, step boundaries, rate values, and rate factor values may all be prorated as part of applying a rate.

We need to establish some terms in order to understand the calculations.

Next in This Section

- Normal Days

- Calculation Period Factor

- RF Value Period Factor

Normal Days

As mentioned previously, the rate schedule references a frequency that specifies the number of times per year that obligations referencing the rate are expected to bill. The following formula dictates a rate frequency's normal days: 365 days / number of periods per year.

Example:

- For a monthly frequency (12 periods per year), 365 / 12 = 30 days.

- For a quarterly frequency (4 periods per year), 365 / 4 = 91 days.

Fastpath:

Refer to Defining Frequency Codes for more information.

Calculation Period Factor

The calculation period is the date range where a rate version is effective during the billable period. For each rate version that is effective during the billable period, a bill segment calculation period is created. A set of bill calculation lines is created for each calculation period.

A calculation period factor is determined for each calculation period. The calculation period factor is the ratio of calculation period days to normal days. If the billable period factor is 1 (not applicable), then the calculation period factor is the ratio of calculation period days to consumption period days.

RF Value Period Factor

The rate factor value period is the date range where a proratable rate factor value is effective during the calculation period.

When a rate factor value changes during the calculation period, the results is that multiple bill calculation lines are generated for the same rate component.

The ratio of the number of days within the calculation period that a distinct value is effective to the number of days in the calculation period determines the RF value period factor. When the rate factor is set up not to prorate, the RF value period factor is 1 (not applicable).

Example:

If the state tax rate changes from 6% to 6.5% on April 16 and the calculation period is April 1 to April 30, there are two rate factor value periods.

- Rate factor value period April 1 to April 15, RF value period factor = 15 days / 30 days = 0.5.

- Rate factor value period April 16 to April 30, RF value period factor = 15 days / 30 days = 0.5.

Fastpath:

Refer to Defining Rate Factors for more information on specifying whether the rate factor allows proration.

Overriding Proration Factors

If the system logic for determining proration factors does not satisfy your requirements, you may plug in an override proration algorithm to calculate the proration factors as required by your implementation. The override proration algorithm must be specified on the Installation record.

The system is delivered with an algorithm type that sets the proration factors to 1 (not applicable) when a predefined characteristic is specified on a rate component. Refer to OVPF-NOPROR for more information.

Rate Quantity Proration

Next in This Section

- Step Proration

- Step Multipliers

Step Proration

If a rate component's charges are based on stepped charges then the step boundaries are also prorated (as long as the rate component is not marked as measures peak). Step boundaries are multiplied by the calculation period factor to determine the adjusted steps boundaries.

Step Multipliers

If the rate component specifies that the steps be multiplied by the result value of another rate component, step proration is not performed. It is assumed that the result value from the referenced rate component has already been prorated, as the referenced step rate component is subject to Rate Component Value Proration.

Rate Component Value Proration

Except for summary type rate components (which are not prorated at all), a value is specified on the rate component. The value may be a unit rate, percentage or charge. The value may be specified directly on the rate component, derived from a rate factor, derived from another rate component or calculated by an algorithm.

Regardless of where the rate component value comes from, it will be multiplied by the calculation period factor when determining the charge on a bill calculation line. Exceptions to this rule are:

- Unit rate values where the rate component's measures peak attribute is not checked.

- Percentage values.

- Rate component values derived from another rate component.

Even though the rate component values are not prorated for unit rate and percentage value types, if these rate values change during the calculation period due to a rate factor value change, rate factor value proration still applies.

Values derived from another rate component are not subject to rate value proration, as rate component value proration was already performed on the referenced rate component. Again, if the rate factor value changed on the referenced rate component, rate factor value proration still applies.

Fastpath:

For more information on rate factor value proration, refer to Rate Factor Value Proration.

Rate Factor Value Proration

Rate factor value proration behaves the same way any time a rate factor value changes within a calculation period.

Multiple bill calculation lines are generated for a given rate component when a proratable rate factor value changes during the calculation period.

Example:

If the state tax rate changes from 6% to 6.5% on April 16, and the calculation period is April 1 to April 30.

- The first RF value factor period April 1 to April 15, so RF value period factor is 0.5.

- The value used in the first bill calculation line for state tax is 6% x 0.5 = 3%.

- The second rate factor value period is April 16 to April 30, so the RF value period factor is 0.5.

- The value used in the second bill calculation line for state tax is 6.5% x 0.5 = 3.25%.

How To Add A New Rate Quantity Rule Algorithm

If the RQ rule algorithms that are supplied with the base package are not sufficient for your rating requirements, you will have to write a new RQ rule algorithm. This section describes how to do this. After you have followed the steps outlined below, you can then set up the control tables necessary to invoke this algorithm as described under Setting Up Rate Quantity Rules.

Follow the following steps to define a new rate quantity (RQ) rule:

- Assign a two-character identifier to the RQ rule. This identifier should begin with an X or Y. For example, you could give your first RQ rule the identifier X1, the second X2, etc.

- Create an algorithm type for your new RQ rule. This algorithm type exists to define the types of parameters supplied to your RQ rule. Refer to Base Package RQ Rules for examples. This algorithm type must be identified by the two-digit identifier allocated above.

While RQ rules require an algorithm type, they do NOT require an algorithm. Why? Because you set up an RQ rule to define the values of the parameters passed to your program (and therefore you don't need an algorithm as algorithms exist to define the values of the parameters passed to a program).

- Go to Look Up Options and add a new lookup value for the field SQ_RULE_FLG. This should have a Field Value equal to the two-digit identifier allocated above.

- Write your new program.

Bankruptcy

The term bankruptcy refers to the entity that captures key information about a bankruptcy case. In this section, we describe how to manage the bankruptcy cases.

Next in This Section

- Understanding Bankruptcy

- Maintaining Bankruptcies

Understanding Bankruptcy

The topics in this section provide background information on bankruptcy.

Next in This Section

- About Bankruptcies

- Alerts

- A Person's Other Bankruptcies Are Highlighted

About Bankruptcies

Each bankruptcy references a bankruptcy type, which controls many aspects of how the bankruptcy is processed. These aspects may include the following:

- The lifecycle of the bankruptcy

- The rules for determining the taxpayer's obligations that can be included in the bankruptcy

- The applicability of suppression

- The applicability of payment plans

- The creation of proofs of claim

Refer to The Big Picture of Bankruptcies for a description of business rules that you control when you set up your bankruptcy types.

Alerts

The Alert Zone will highlight if the person in context has open bankruptcies if you plug in the appropriate algorithm on the installation record.

Refer to Setting Up An Alert For Highlighting Bankruptcies for information on configuring this algorithm.

A Person's Other Bankruptcies Are Highlighted

When viewing a bankruptcy on the maintenance portal, a context-sensitive dashboard zone will display other bankruptcies (if any) for the person in context.

Maintaining Bankruptcies

Use the Bankruptcy transaction to view and maintain pending or historic bankruptcies. Navigate using Menu > Case Management > Bankruptcy.

Next in This Section

- Bankruptcy Query

- Bankruptcy Portal

- Creating Proofs Of Claim

- Creating Pay Plans

Bankruptcy Query

Use the query portal to search for an existing bankruptcy. Once a bankruptcy is selected, you are brought to the maintenance portal to view and maintain the selected record.

Bankruptcy Portal

This page appears when viewing the detail of a specific bankruptcy.

Next in This Section

- Bankruptcy - Main

- Bankruptcy - Log

Bankruptcy - Main

This portal appears when a bankruptcy has been selected from the Bankruptcy Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Bankruptcy

The Bankruptcy zone contains display-only information about the selected bankruptcy. Aside from showing basic information about the bankruptcy, this zone also shows the persons related to the bankruptcy, the users responsible for the bankruptcy and suppression information, if applicable.

Please see the zone's help text for information about this zone's fields.

Eligible Obligations

This zone shows all obligations that can be added to the bankruptcy's covered obligations. The list of obligations is determined by an algorithm that is defined on the bankruptcy type. Click here to see the algorithm types available for this system event.

One or more obligations can be selected for adding at once.

Covered Obligations

This zone shows all obligations that are currently covered by the bankruptcy.

Pay Plans

This zone shows the pay plans that were created from the bankruptcy.

Proofs of Claims

This zone shows the proofs of claims that were created from the bankruptcy.

Bankruptcy - Log

Navigate to the Log tab to view the logs for a bankruptcy.

Creating Proofs Of Claim

Use this procedure to initiate proofs of claim for the bankruptcy.

You can only create proofs of claim if the bankruptcy's current status supports it. If the action is not supported, the Create Proof of Claim button will not be displayed.

- Navigate to the Bankruptcy portal and display the bankruptcy you want to create proofs of claim for.

- Click the Create Proof of Claim button in the Record Actions.

- Select the Contact Class and Contact Type.

- Change the Contact Date Time, if needed.

- Select the proof of claim recipients in the Send To grid.

- Click OK.

The newly created proof of claim will appear in the Proofs of Claim Zone. Click on the information link to see the details of the proof of claim (customer contact).

Creating Pay Plans

Use this procedure to initiate payment plans from the bankruptcy.

You can only create pay plans if the bankruptcy's current status supports it. If the action is not supported or pay plans already exist for the bankruptcy, the Create Pay Plan button will not be displayed.

- Navigate to the Bankruptcy portal and display the bankruptcy you want to create pay plans for.

- Click the Create Pay Plan button in the Record Actions.

- If the taxpayer has pay plans that preexist the bankruptcy and such pay plans cover other obligations that the bankruptcy does not include, an error will display and the user will have to review the existing pay plan and cancel it manually. On the other hand, if the existing pay plans cover exactly the same obligations as those included in the bankruptcy, a warning message will appear, indicating that pre-existing pay plans will be canceled or stopped, depending on the current status. Click OK on the warning message popup to confirm the action.

- If all obligations covered by the bankruptcy are for the same account, a pay plan is automatically created in background, using the pay plan obligation type specified on the bankruptcy type.

- If the obligations covered by the bankruptcy are for multiple accounts, specify the following additional inputs:

- Choose to create a single pay plan for the whole bankruptcy or to create a single pay plan for each unique account.

- If you opt to create one pay plan for the whole bankruptcy, designate the account that will be the primary account on the pay plan obligation. All bankruptcy-covered obligations are copied into the pay plan's covered obligations list.

- If you opt to create one pay plan per account, the bankruptcy-covered obligations for the specific account are copied into each pay plan.

- Click on the pay plan information in the Pay Plans Zone to navigate to the Pay Plan maintenance page.

- Complete the pay plan setup by specifying a payment schedule either via the Recommend button or by manual entry. Activate the pay plan when setup is complete.

Audit Case

The term audit case refers to the entity that captures key information about an audit case. In this section, we describe how to manage audit cases.

Next in This Section

- Understanding Audit Case

- Maintaining Audit Cases

Understanding Audit Case

This section describes concepts related to audit cases.

Next in This Section

- About Audit Cases

- Alerts

About Audit Cases

Each audit case references an audit case type, which controls most if not all aspects of how the audit case is processed. These may include the following:

- The lifecycle of the audit case

- The applicability of suppression

- The applicability of reviews and the review process controls (if reviews are applicable)

- The creation of letters

Refer to The Big Picture of Audit Cases for a description of business rules that you control when you set up your bankruptcy types.

Alerts

The Alert Zone will highlight if the person in context has open audit cases if you plug in the appropriate algorithm on the installation record.

Refer to Setting Up An Alert For Highlighting Audit Cases for information on configuring this algorithm.

Maintaining Audit Cases

Use the Audit Case transaction to view and maintain pending or historic audit cases. Navigate using Menu > Case Management > Audit Case.

Next in This Section

- Audit Case Query

- Audit Case Portal

- Sending Letters

- Creating Audit Case Reviews

Audit Case Query

Use the query portal to search for an audit case. Once an audit case is selected, you are brought to the maintenance portal to view and maintain the selected record.

Audit Case Portal

This page appears when viewing the detail of a specific audit case.

Next in This Section

- Audit Case - Main

- Audit Case - Log

Audit Case - Main

This portal appears when an audit case has been selected from the Audit Case Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Audit Case

The Audit Case zone contains display-only information about the selected audit case. Aside from showing basic information about the audit case, it also shows the audited obligations, persons related to the audit case, users responsible for the audit case, suppression information, if applicable, and review information, if applicable.

Please see the zone's help text for information about this zone's fields.

Audit Tax Forms

This zone shows the tax forms that were created from the audit case.

Audit Balances

This zone shows the detailed balance view for either a proposed audit assessment or an actual audit assessment.

Audit Case - Log

Navigate to the Log tab to view the logs for an audit case.

Sending Letters

Use this procedure to send letters from an audit case.

You can only send letters if the audit case's current status supports it. If the action is not supported, the Send Letter button will not be displayed.

- Click the Send Letter button in the display map.

- On the Send Letter dialog:

- Select the Customer Contact Class and Customer Contact Type.

- Change the default date/time, if needed.

- Select the person(s) to send letters to. The list will show all financially responsible people on the primary account, as well as the related persons on the audit case. A customer contact will be created for each selected person.

- Click OK.

- The most recent letter will display on Audit Case - Main. To see all other prior letters, go to the log. Click on the information link to see the details of each letter.

Creating Audit Case Reviews

Use this procedure to initiate reviews from an audit case.

You can only create reviews if the audit case's current status supports it. If the action is not supported, the Create Review button will not be displayed.

- Navigate to the Audit Case portal and display the audit case you want to create reviews for.

- Click the Create Review button in the display map.

- On the Select Review Type popup:

- The Review Type dropdown shows the next available step(s) based on the audit case type's review process control and on any prior reviews for the audit case. Select the Review Type to create.

- The Review Date is defaulted to the current process date. Set this date as needed.

- Click OK.

- The current review and any other prior reviews will display on Audit Case - Main. Click on the information link to take further action on a review.

Appeal

The term appeal refers to the entity that captures key information about an appeal case. In this section, we describe how to manage the appeal cases.

Next in This Section

- Understanding Appeals

- Maintaining Appeals

Understanding Appeals

The topics in this section provide background information on appeals.

Next in This Section

- Appeal Type

- Issues Detected

- Reviewing an Appeal

Appeal Type

Each appeal has an associated appeal type. The appeal type defines the configuration information that is common to appeal processes of a given type. These may include the following:

- The business object that defines the lifecycle of the appeal

- Rules for determining the review steps that are part of the appeal process

- The applicability of suppression

Refer to The Big Picture of Appeals for a description of the business rules that you control when you set up your appeal types.

Issues Detected

An appeal may be configured go through a number of automated checks or validations before it is processed. If any of the validations fail, the appeal will transition to an issues detected or error state.

An issues list will appear in the right-hand column of the appeal zone. The user can edit the appeal and correct any errors. After saving the changes, the user can then use the Validate action for the system to apply the validation rules on the updated appeal.

Users with the appropriate security access can bypass the Validate action to override the automated checks and transition the appeal directly to a ready for review state.

If the validations were carried out using an Oracle Policy Automation rulebase, a link to the decision report from the rule will be stored as log entry.

Reviewing an Appeal

Appeal processes involve a number of review steps that are managed as independent sub-processes. An appeal that has reached the review state remains in that state until a user indicates that the last review has been completed and a final decision has been made. Refer to Appeals Follow a Defined Review Process for more information on configuring appeal review processes.

Maintaining Appeals

Use the Appeal transaction to view and maintain pending or historic appeals. Navigate using Menu > Case Management > Appeal.

Next in This Section

- Appeal Query

- Appeal Portal

- Creating Appeal Reviews

Appeal Query

Use the query portal to search for an appeal. Once an appeal is selected, you are brought to the maintenance portal to view and maintain the selected record.

Appeal Portal

This page appears when viewing the detail of a specific appeal.

Next in This Section

- Appeal - Main

- Appeal - Log

Appeal - Main

This portal appears when an Appeal has been selected from the Appeal Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Appeal

The Appeal zone contains display-only information about the selected appeal, including the following:.

- Details of the most recent appeal review

- Suppression information, if applicable

- Obligations suppressed by the appeal

- Other objects related to the appeal

- Persons related to the appeal

- Appeal issues (if applicable)

- Users responsible for the appeal

- Reviews completed prior to the current review, if applicable

Please see the zone's help text for more information about this zone's fields.

Appeal - Log

Navigate to the Log tab to view the logs for an appeal.

Creating Appeal Reviews

Use this procedure to initiate or record review processes for an appeal.

You can only create reviews if the appeal's current status supports it and there is no review currently in progress for the appeal. If the action is not supported, the Create Review button will not be displayed.

- Navigate to the Appeal portal and display the appeal for which you want to create the review.

- Click the Create Review button in the display map.

- Select the appropriate review type from the drop-down list. The available review types will be governed by the applicable review process control and will include only the review types that have not yet been completed for the appeal or review types that can be repeated during the appeal process.

- Enter the review date and click Save . The portal zone will refresh, showing a link to the current review. Click on the link to navigate to the review.

- The review portal will be displayed allowing you to maintain the review details.

Review

Reviews are used to maintain pending or historic review steps as part of an appeal or audit case.

Next in This Section

- Understanding Reviews

- Maintaining Reviews

Understanding Reviews

Many of the processes followed by tax authorities can trigger one or more review steps. The reviews have an independent lifecycle and often have a number of key details in common, such as scheduled dates and response types. The review entity provides the ability to manage multiple reviews of different types as sub-processes of a primary process, such as an appeal or audit case.

Next in This Section

- Review Types and Review Process Controls

- Navigating to a Review

Review Types and Review Process Controls

Each review process has an associated review process type. Review types are linked to review process controls which define a sequence of review types that may be applicable to a specific case management process. Refer to Defining Review Options for more information.

Navigating to a Review

A review is a subordinate process, initiated from another process such as an appeal or audit case. Reviews are maintained in their own stand-alone portal and are accessed by navigating from the process that created the review. The appeal and audit case query portal provide options to search for the initiating process using review information.

Maintaining Reviews

Navigating to a review from the related process brings the user to the maintenance portal to view and maintain review details.

Next in This Section

- Review Portal

Review Portal

This page appears when viewing the detail of a specific review.

Next in This Section

- Review - Main

- Review - Log

Review - Main

The topics in this section describe the base-package zones that appear on this tab.

Please see each zone's help text for specific information about the data displayed in the zone.

Review Zone

The Review zone contains display-only information about the selected review.

Review - Log

Navigate to the Log tab to view the logs for a review.

Pay Plans

Pay plans are typically used to satisfy obligations in which the taxpayer cannot satisfy the total obligation with one lump payment. Payments received are used to satisfy tax, penalty, and interest. Pay plans are typically negotiated between the tax authority and taxpayer. The negotiated payment amount and specific date intervals of the pay plan include such factors as total obligation amount and the taxpayer's ability to pay. Examples in which a payment plan should be used include:

- After an audit of income, it is determined that the taxpayer incorrectly calculated their tax and owes additional tax to the tax authority. If they do not have enough money to satisfy the obligation at the time of the audit decision, they can arrange a series of payments to the tax authority to satisfy their obligation.

- Property values rose by an unexpected rate. This increased property taxes and if a taxpayer could not pay the tax bill on the new assessed value of their house they could set up a pay plan to pay off the amount they owe over a six-month period.

Pay plans can cover one or more obligations linked to any account of the taxpayer. You can have multiple active pay plans for an account, but any given obligation can only be covered by a single pay plan at any point in time.

Next in This Section

- The Big Picture Of Pay Plans

- Maintaining Pay Plans

- How To

The Big Picture Of Pay Plans

The topics in this section provide background information about pay plans.

Next in This Section

- Pay Plans Are Obligations

- Which Obligations Are Covered By A Pay Plan?

- Recommending Scheduled Payments

Pay Plans Are Obligations

Pay plans are initiated by creating a 'pay plan' type of obligation for a taxpayer. The pay plan and its obligation type maintain the details of the pay plan, such as recommendation rules, covered obligations, and scheduled payments.

Pay plans are just like other obligations in that collections activity may be used to encourage the taxpayer to pay.

Pay plans differ from other obligations in the following ways:

- Pay plans have a special role of Pay Plan.

- Pay plans have scheduled payments.

- Pay plans maintain a list of covered obligations.

- Pay plans are started and maintained on a separate transaction (refer to Pay Plan - Main for more information).

Which Obligations Are Covered By A Pay Plan?

A pay plan can apply towards one or more of the taxpayer's obligations whose obligation type is flagged as Eligible (for Pay Plan). Obligations can be added to or removed from a pay plan at any time. Additionally, an obligation can be linked to more than one pay plan as long as the pay plans to which it is linked do not have overlapping start and end dates.

A list of the obligations covered by a pay plan is maintained with the pay plan. This list is used during payment distribution to determine the priority of distribution.

Recommending Scheduled Payments

When creating a pay plan, you must select a recommendation rule. The recommendation rule establishes the amount to be paid and the dates on which the payments are due. In other words, the recommendation rule creates a recommended payment schedule.

The recommendation rules that you can use are specific to your implementation. The recommendation rule that you select can have default values for its parameters. If your implementation allows, you can manually override one or more of these default values. For example, you may be able to specify the period covered by the pay plan and the day of the month on which the payments are due.

If your implementation allows, you can manually modify the recommended payment schedule to suit the needs of a particular taxpayer.

Fastpath: Refer to Designing Recommendation Rules for more information.

Maintaining Pay Plans

Pay plans are started and maintained on a different transaction than other obligations. The topics in this section explain how to start and maintain pay plans.

Next in This Section

- Pay Plan - Main

- Pay Plan - History

- Pay Plan - Characteristics

Pay Plan - Main

The Main page contains basic information about the pay plan. Open Menu > Case Management > Pay Plan to maintain this information.

Description of Page

Pay Plan information and Pay Plan ID are displayed on each page. These values only appear after the obligation is created. The Pay Plan ID is a system assigned random number that stays with the obligation for life. The Pay Plan information is a concatenation of important details about the obligation and its account.

The Primary Account ID is identification of the account that is financially responsible for the pay plan.

The Primary Taxpayer ID is identification of the taxpayer that is financially responsible for the pay plan.

Indicate the Division and Obligation Type. These fields control aspects of the pay plan's behavior, such as events that occur when a pay plan is activated or stopped. These fields are gray when the status is not Pending Start.

Fastpath: For more information about pay plan obligation types, refer to Defining Pay Plan Options.

Recommendation Rule is used to create a recommended payment amount and payment schedule. The obligation type controls which recommendation rules are allowed for the pay plan.

If Scheduled Payment Auto Pay is Included in Auto Pay and the account is set up for automatic payment, the scheduled payments are covered by auto pay. If Excluded from Auto Pay, the scheduled payments are excluded from auto pay if it is set up for the account.

The Start Date defines when the financial relationship begins. The End Date is a display only field that indicates when the financial relationship terminates.

The Recommendation Rule Parameter Values grid specifies the parameters and their values to use for the selected recommendation rule:

- Parameter is the name of the parameter from the recommendation rule algorithm type.

- Value is the value used for the parameter. If the recommendation rule allows, you can override the default values by specifying your own.

Note: The recommendation rule's controls the number and type of parameters. The recommendation rule controls the default values and whether they can be overridden.

The Covered Obligations grid lists the obligations that are covered by the pay plan. The list of covered obligations would depend on the business situation and the rules of the specific tax authority. Some tax authorities might allow for obligations across different tax types to be listed on the same pay plan while others may not. Rules regarding open cases (audit, bankruptcy) would also limit the eligibility of obligations. You must create the list of covered obligations before the recommendation rule can recommend a payment amount and list of scheduled payments. The grid displays the Obligation ID, Obligation Information, Account ID, Current Balance and Payoff Balance for covered obligations.

The Scheduled Payments grid displays the scheduled payments created by the recommendation rule (after you click the Recommend button). You can manually create or modify the Scheduled Date and or Scheduled Amount of any scheduled payment in the list. The Total of Scheduled Payments shows the total of all scheduled payments in the list. The Status of each scheduled payment is also displayed.

In the Action grid:

- Click Recommend to create a recommended payment schedule based on the recommendation rule.

- Click Renew to manually renew the pay plan. This executes any renewal algorithm(s) defined for the obligation type, and returns new renewal and expiration dates for the obligation.

- Click Break to manually stop the pay plan. This executes any break pay plan algorithm(s) defined for the obligation type, and changes the status of the obligation to pending stop.

- Click Activate to manually activate the pay plan. This executes any activation algorithm(s) defined for the obligation type, and changes the status of the obligation to active.

- Click Cancel to cancel the pay plan. This executes any cancel algorithm(s) defined for the obligation type, and changes the status of the obligation to canceled.

Pay Plan - History

The Financial History page displays the pay plan's historical financial transactions. Open Menu > Case Management > Pay Plan and navigate to the History tab to view this information.

Description of Page

Pay Plan information and Pay Plan ID are displayed on each page. These values only appear after the pay plan is created. The Pay Plan ID is a system assigned random number that stays with the obligation for life. The Pay Plan information is a concatenation of important details about the obligation and its account.

The Account identifies who is financially responsible for the obligation.

The grid shows the pay plan's financial history in reverse chronological order. The financial transactions included here are only ones that directly affect the balance of the pay plan obligation, such as fees. The following fields are displayed:

- The Effective Date is used to compute how many days old the debt is.

- Financial Transaction Type displays the type of financial transaction except for adjustments. For adjustments, the adjustment type's description is shown.

- Current Amount is the effect of the financial transaction on the obligation's current balance.

- Current Balance is the amount owed by the taxpayer at the time of the transaction.

Pay Plan - Characteristics

The characteristics page contains information that describes miscellaneous information about the pay plan obligation. Use Menu > Case Management > Pay Plan and navigate to the Characteristics tab to open this page.

Description of Page

Note: You can only choose characteristic types defined as permissible on the obligation record. Refer to Setting Up Characteristic Types & Their Values for more information.

The following fields display:

- Effective Date indicates the date on which the characteristic value becomes effective. Note, the effective date defaults to the pay plan start date.

- Characteristic Type indicates the type of characteristic.

- Characteristic Value indicates the value of the characteristic.

How To

The topics in this section describe how to perform common pay plan functions.

Next in This Section

- How To Create A Pay Plan

- How To Activate A Pay Plan

- How To Break Pay Plans

- How To Cancel Pay Plans

- How To Set Up Automatic Payment For A Pay Plan

How To Create A Pay Plan

To set up a new pay plan:

- Navigate to the Pay Plan maintenance page.

- If the account is not already specified, select the Account for which you want to create a pay plan

- Define the Division and Obligation Type to use for the pay plan.

- If necessary, change the Start Date (the current date is defaulted).

- Select the Recommendation Rule to use and modify any of the default parameters to meet the needs of the taxpayer.

- Verify the list of Covered Obligations.

- Click Recommend.

- On the pop-up dialog, specify the Schedule Start Date and click Recommend.

- Make any necessary changes to the scheduled payments grid and click Save.

How To Activate A Pay Plan

The pay plan is created in a pending start status. In order for the pay plan to become effective, it must be activated. Some tax agency's will require an approval or review before a pay plan can be activated. There are a couple of ways a pay plan can be activated:

- From the Pay Plan maintenance page:

- If the account with the pay plan you want to activate is not specified, select the Account of the pay plan

- If the account has more than one pay plan, select the pay plan you want to activate.

- From the pay plan context menu, navigate to the Obligation page.

- Click Activate.

- From the Obligation maintenance page:

- If the pay plan you want to activate is not specified, select the pay plan using the obligation search.

- Click Activate.

How To Break Pay Plans

An active pay plan may need to be stopped due to the taxpayer breaking the terms of the agreement. To stop a pay plan:

- Navigate to the Pay Plan maintenance page.

- If the account with the pay plan you want to stop is not specified, select the Account of the pay plan

- If the account has more than one pay plan, select the pay plan you want to stop.

- Click Break.

How To Cancel Pay Plans

A pay plan may need to be cancelled for various reasons: the pay plan was created in error or the taxpayer has indicated additional hardship and a new pay plan needs to be negotiated. A pending start, active, or pending stop pay plans may be cancelled. To cancel a pay plan:

- Navigate to the Pay Plan maintenance page.

- If the account with the pay plan you want to stop is not specified, select the Account of the pay plan

- If the account has more than one pay plan, select the pay plan you want to cancel.

- Click Cancel.

How To Set Up Automatic Payment For A Pay Plan

If a taxpayer wants to pay their pay plan scheduled payments automatically:

- Set up the account for automatic payment (as described under How To Set Up A Taxpayer To Pay Automatically).

- Navigate to the Pay Plan Maintenance page and select the pay plan for the account.

- Set the Scheduled Payment Auto Pay field to indicate that the scheduled payments are Included in Auto Pay.

Suppression

The term suppression refers to the entity that captures key information about a suppression process. In this section, we describe how to manage a suppression.

Next in This Section

- Understanding Suppressions

- Maintaining Suppressions

Understanding Suppressions

The topics in this section provide background information on suppression.

Next in This Section

- Suppression Type

- Releasing a Suppression

Suppression Type

Each suppression event has an associated suppression type. The suppression type defines the configuration information that is common to suppressions of a given type. These may include the following:

- The level at which suppression applies - person, account tax role or obligation

- The process types whose activity is affected by this type of suppression

- Whether a suppression of this type can be manually added

Refer to The Big Picture of Suppressions for a description of the business rules that you control when you set up your suppression types.

Releasing a Suppression

Suppressions can be released by setting the end date and allowing the monitoring process to transition it to the Released state or by manually transitioning via the Release action. Suppressions can be configured to be automatically released after a given period of time.

Maintaining Suppressions

Use the Suppression transaction to view and maintain pending or historic suppressions. Navigate using Menu > Case Management > Suppression.

Next in This Section

- Suppression Query

- Suppression Portal

Suppression Query

Use the query portal to search for a suppression. Once a suppression is selected, you are brought to the maintenance portal to view and maintain the selected record.

Suppression Portal

This page appears when viewing the detail of a specific suppression.

Next in This Section

- Suppression - Main

- Suppression - Log

Suppression - Main

The topics in this section describe the base-package zones that appear on this portal.

Please see each zone's help text for specific information about the data displayed in the zone.

Suppression

The Suppression zone contains display-only information about the selected suppression.

Suppression - Log

Navigate to the Log tab to view the logs for a suppression.

Work Management

This section describes functionality provided by the product to manage miscellaneous business processes.

Next in This Section

- Process Flows

- Entity Correction

- Case

Process Flows

We use the term process flow to refer to a generic entity that can be configured to represent custom entities and support automated workflow processes. The topics in this section provide background information about base functionality that supports process flows.

Next in This Section

- Background Topics

- Maintaining Process Flows

Background Topics

The topics in this section provide background information about process flows.

Next in This Section

- Process Flow Type

- Log Information

- Process Flow Monitor

Process Flow Type

Each process flow has an associated process flow type. The process flow type defines the configuration information that is common to process flows of a given type. Refer to Using Process Flow Type To Control Process Flows for details and guidelines on what process flow types can define.

Log Information

The process flow log contains an entry for every recorded event during the lifecycle of the process flow. There are three types of log entries:

- Automatic entries. The system automatically creates an entry in the log when the process flow is created or there is a status change. Users cannot modify or delete these log entries.

- Implementation specific entries. In addition to entries created when a process flow is created and changes status, an implementation can choose to add specific log entries to highlight specific activities that occur as a result of the process. For example, a log entry can be created if a customer contact is generated.

- Manual entries. Users can add manual entries to record significant events at their discretion.

Process Flow Monitor

The base product provides the following periodic monitor batch process for process flow objects.

Next in This Section

- C1-PFLM - Process Flow Monitor (Periodic)

C1-PFLM - Process Flow Monitor (Periodic)

This batch process invokes monitoring rules associated with the current state of process flows where the current state is not associated with a batch code.

Maintaining Process Flows

The base package provides a query portal and a maintenance portal that includes base action, display and log zones that can be used with a customized process flow object.

To maintain process flow records, select Menu > Work Management > Process Flow.

Next in This Section

- Process Flow Query

- Process Flow Portal

Process Flow Query

Use the query portal to search for an existing process flow. Once a process flow is selected, you are brought to the maintenance portal to view and maintain the selected record.

You can click the Add link on this portal to add a process flow.

Process Flow Portal

This portal appears when a process flow has been selected from the Process Flow Query portal or if this portal is opened via drill down from another page.

Next in This Section

- Process Flow - Main

- Process Flow - Log

Process Flow - Main

The topics in this section describe the base-package zones that appear on the Main tab.

Actions

This is a standard actions zone.

If the record is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

Process Flow

The Process Flow zone contains display-only information about the process flow.

Refer to the zone's help text for more details related to the fields on the zone.

Process Flow - Log

The topics in this section describe the base-package zones that appear on the Log tab.

Process Flow Log

This is a standard log zone.

Entity Correction

Entity correction is an object provided to perform an action on a group of records. The product provides base support for the following business use cases:

- Mass cancellation of tax forms.

- Mass cancellation of payment events.

- Mass cancellation / correction of overdue events for a group of overdue processes.

- Mass creation of suppressions for a group of taxpayers.

- Mass release of suppressions for a group of taxpayers.

- Mass retry for overpayment processes.

Implementations may follow the pattern to introduce additional business use cases. The topics in this section describe entity correction functionality.

Next in This Section

- Background Topics

- Maintaining Entity Corrections

Background Topics

The topics in this section provide background information about entity corrections.

Next in This Section

- Common Entity Correction Functionality

- Additional Information Required

- Use Cases

Common Entity Correction Functionality

The following topics highlight functionality common to all entity correction use cases.

Creating Entity Corrections

Entity corrections are created via an interface. The expectation is that analysis is performed using an appropriate reporting or analysis tool to determine the records that require a special action to be performed. The appropriate records for the use case in question are selected in that tool and interfaced to the system.

Entities Linked to the Entity Correction

The types of records (referred to as Entities here) linked to the entity correction depend on the type of entity correction. For example, an entity correction for mass cancellation of tax forms expects tax forms to be linked to the entity correction. An entity correction for mass suppressions of taxpayers expects person IDs to be linked.

Some types of records have an external reference. For example, a tax form has a DLN; a person has an ID number. If the algorithms for the particular use case support it, the external ID may be provided when creating the entity correction.

Entity Link Status

The Link Status refers to the status of a particular entity to a particular entity correction. The following points highlight the status values.

- When an entity is initially linked it has a link status of Active. Only entities linked as active are considered eligible for the mass action once the entity correction is approved.

- An entity's link status may change to Skipped by the validation if the algorithm detects that some condition related to the entity is not appropriate for the mass action. For example, if the action is to cancel a record but it is already canceled, the record will be skipped. Each type of entity correction would have different rules for what causes the link status to change to Skipped. When setting the link status to Skipped the algorithms should also indicate an appropriate Skipped Reason so that it is clear when reviewing the results why the records were skipped. Also note that the algorithm that attempts to perform the mass action should recheck for conditions that may change in the time between running the validation algorithm and the correction algorithm. For example, a tax form to be canceled may be in the Suspended state when running the validation algorithm but before running the correct entity algorithm someone may cancel the record. In this scenario, the correct entity algorithm will not do any action and will indicate that the record is skipped at that point.

- An entity's link status may change to Invalid by the validation if appropriate record cannot be found in the system. This may occur if internal IDs are provided or if external IDs are provided by the interface.

- An entity's link status may change to Duplicate if it is found that the record is listed twice in the list for a given entity correction.

Approving Entity Corrections

Once the entity correction and its list of entities are validated, the system transitions the record to Approval in Progress and a To Do entry is created to alert the appropriate user(s). At this point, the reviewing user may Approve or Reject the record.

Performing the Mass Action

Once a user approves an entity correction, a batch process processes the linked entities to perform the mass action. The action performed depends on the business use case.

The expectation is that this process is part of the nightly batch cycle. As such there may be a delay from the time that an entity correction is approved to the time its related entities are impacted by the action that is performed.

Additional Information Required

Entity corrections require information unique to the particular instance that is typically not provided by the interface. For example, the reason for the correction. Some types of entity corrections required even more specific details in order to produce the mass action. For example, the mass suppression entity correction type requires a suppression reason and suppressed entity to be defined. The product supports two different entity correction lifecycles based on whether or not the additional information is needed prior to the validation of the entities or not.

- For use cases where the addition information is not required for validation of the entities, the lifecycle follows the pattern of Pending > Validated > Approval in Progress. Assuming that an interface creates the pending record and a deferred monitor batch job picks up the record for validation, the appropriate user group is alerted when the record is in the Approval in Progress state at which time the additional data may be provided.

- For use cases where the addition information is required for validation of the entities, the lifecycle follows the pattern of Initial > Pending > Validated > Approval in Progress. A user need to get involved at two different steps.

- A user group is alerted as soon as the record is created in Initial state at which time the additional data may be provided. Once the user enters the data, the record may be transitioned to Pending allowing the deferred monitor to pick up the record for validation.

- Once the record is validated, a user group is alerted that the record is in the Approval in Progress state at which time the validation results can be reviewed and the record can be approved or rejected accordingly.

Use Cases

This section briefly describes the use cases the base product has supplied functionality to support.

Mass Cancellation of Tax Forms

The product provides algorithms to cater for an entity correction with a list of either Tax Form IDs or DLNs (document locator numbers) that should be canceled. The validation algorithm provided ensures that the Tax Form IDs or DLN values are valid. Once the process is approved, the tax forms are either canceled (if they were not yet posted) or they are reversed (if the status is posted). Rules plugged into the tax form type for cancelling or reversing may cause other tasks to occur.

When creating and approving an entity correction for this use case, no additional information needs to be provided by the user besides the correction reason.

Fastpath: Refer to Common Tax Form Procedures for more information on tax form cancellation and reversal.

Mass Cancellation of Payment Events

The product provides algorithms to cater for an entity correction with a list of payment event IDs that should be canceled. There is no external ID for a payment. The validation algorithm provided ensures that the payment event IDs are valid. Once the process is approved, the payment tenders and payments linked to each payment event are canceled.

When creating and approving an entity correction for this use case, no additional information needs to be provided by the user besides the correction reason.

Fastpath: Refer to Cancel a Tender for more information on payment cancellation.

Mass Correction of Overdue Processes

The product provides algorithms to cater for an entity correction with a list of overdue processes whose events should be canceled or reversed. There is no external ID for an overdue process. Additional information about how to perform the correction is required before validation. The validation algorithm provided ensures that the overdue processes are valid for the requested correction actions. Once the process is approved, events on the overdue process are canceled or reversed based on the input information. And if requested, some of the events are recreated to restart the process.

Fastpath: Refer to Overdue Correction for more information on this process.

Mass Suppression Creation for Taxpayers

The product provides algorithms to cater for an entity correction with a list of person ids for which to create suppression records. The person IDs supplied may be the internal Person ID or an ID in the person identifier collection. Additional information about how to create the suppression is required and can be supplied when approving the record. As such, a special business object is provided for this use case. The validation algorithm provided ensures that the person IDs are valid. Once the process is approved, suppression records are created for each person using input information on the entity correction.

Fastpath: Refer to Suppressions for more information on suppressions.

Mass Suppression Release for Taxpayers

The product provides algorithms to cater for an entity correction with a list of suppression ids that should be released. There is no external ID for a suppression. The user should supply the date that the suppression should be released and that information needs to be supplied before validation.

Fastpath: Refer to Suppressions for more information on suppressions.

Maintaining Entity Corrections

Use the Entity Correction transaction to view and maintain entity corrections. Navigate using Menu > Work Management > Entity Correction. The section describes the tab pages that appear on the Entity Correction portal.

Next in This Section

- Entity Correction Query

- Entity Correction Portal

- Common Entity Correction Procedures

Entity Correction Query

Use the query portal to search for an entity correction. Once an entity correction is selected, you are brought to the maintenance portal to view and maintain the selected record.

Entity Correction Portal

This portal appears when an entity correction has been selected from the Entity Correction Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Entity Correction - Main

- Entity Correction - Log

Entity Correction - Main

The topics in this section describe the base-package zones that appear on this tab.

Entity Correction

The Entity Correction zone contains display-only information about the Entity Correction.

Please see the zone's help text for additional information about the data displayed in the entity correction.

Refer to the Common Entity Correction Procedures section for more information about common functions.

Linked Entities

This zone displays a list of the entities that are currently linked to the entity correction along with the status of the link and the skipped reason for records that were skipped. Refer to Common Entity Correction Functionality for more information about the link status. The filter allows the user to select a subset of records to display based on information such as link status and ID ranges.

Entity Correction - Log

Navigate to the Log tab to view the logs for an entity correction.

Common Entity Correction Procedures

This section describes common entity correction procedures based on functionality provided in the base product.

Reviewing an Initial Entity Correction

For entity corrections that require additional information before validating the entities, a To Do entry is sent to appropriate users as soon as the record is created in Initial status. When a user in that group reviews the entity correction, this procedure should be followed:

- Drill into the entity correction record from the To Do entry (or from the email, if the To Do is routed to an email).

- Edit the record and provide the additional information needed for processing the record.

- Click Save.

- Click Batch Validation to transition the record to Pending so that it is picked up by the deferred monitor for validation.

Reviewing and Approving a Entity Correction

Once a entity correction is validated, if it requires review to determine if it should be approved or rejected. A To Do entry is sent to the appropriate group of users based on the To Do role configured on the entity correction type. When a user in that group reviews the entity correction, this procedure should be followed:

- Drill into the entity correction record from the To Do entry (or from the email, if the To Do is routed to an email).

- Review the summary counts of the linked entities to see if the information is as expected. If desired, use the Linked Entities zone to spot check and even drill into any related records.

- For entity correction types that did not require additional information prior to validation, Edit the record and provide the additional information at this time.

- Choose whether to Approve or Reject the record.

Case

Your organization can use case functionality to manage a variety of business processes that are not otherwise supported by the product.

CAUTION:

The case management functionality is legacy functionality that is not recommended for future use. It has been replaced by Process Flow or an implementation may create their own business object driven maintenance object to introduce support for business processes not otherwise supported by the product. The functionality remains in the product for upgrade purposes.

Note: Your implementation controls how your cases behave. Since virtually all aspects of case functionality are controlled by your implementation, you can use it to handle a myriad of business requirements. Refer to Defining Case Options for the details.

Next in This Section

- Background Topics

- Maintaining Cases

Background Topics

The topics in this section provide background information about case functionality.

Next in This Section

- Case Type

- Creating Cases

- Log Information

- Alerts

- To Do's and Cases

Case Type

A case is controlled by the case type that it references. Some aspects of the case that are controlled by the case type include:

- The lifecycle of the case

- The applicability of a person, account, and/or location on the case

- Which fields are required during the various stages of a case's life

- Which users can access cases of a given type

- Additional processing that should take place when a case enters or leaves a given state

Refer to Case Type Controls Everything for a description of the business rules that you control when you set up your case types.

Creating Cases

To create a case, open the case page in add mode, select the appropriate case type, fill in the other necessary fields, and click save. The product includes scripts that can help create cases. Refer to Scripts and Cases for more information.

You can also develop plug-ins, user exits, batch processes, etc so that the system will create cases when specific events take place. For example, you can set the system to create a case when an overpayment on an obligation is deemed refundable or when refund request cases need to be grouped into vouchers for approval.

Log Information

A case log contains an entry for every recorded event during the lifecycle of the case. There are two types of log entries:

- Automatic entries. The system automatically creates an entry in the log when a case is created or there is a status change. Users cannot modify or delete these log entries.

- Manual entries. Users can add manual entries to record significant events at their discretion.

Refer to Case - Main for the page used to view the log.

Alerts

The alert zone will highlight if the person / account / location in context have cases in a state that is configured as "alertable" if you plug-in the appropriate algorithm on the installation record. Refer to Alert Info Is Controlled By An Installation Plug-In for the details.

To Do's and Cases

You can configure the system to inform users of cases that require their attention. Refer to To Do's and Cases for the details.

Maintaining Cases

Note:

Since an implementation can configure virtually every aspect of a case, the look and feel of the case page are dynamic based on how case types have been configured.

Next in This Section

- Case - Main

- Case - Case Portal

- Case - Log

Case - Main

Open the case page by selecting Menu > Work Management > Case .

Main Information

Case Info contains a concatenation of important information about the case. Case ID is the system-assigned unique identifier of the case. These values only appear after the case is added to the database.

Case Type defines the type of case. This field is protected after the case has been added. Refer to Case Type Controls Everything for more information.

Status shows the current state of the case. Refer to Case Lifecycle for more information.

If the case has any To Do entries associated with it, a hyperlink will appear summarizing the number and status of the entries. You can select the link to view these entries. Refer to To Do's and Cases for more information.

Date / Time Opened shows when the case was created. If the case is in a final state, the Date / Time Closed will also be shown. Refer to One Initial State and Multiple Final States for more information.

Script references the business process assistant script that can help you work on the case. You can click on the hyperlink to execute this script. This field is hidden if no script is associated with this case's current Status. Refer to Scripts and Cases for more information.

The Actions section contains buttons you can use to action the case. This area is suppressed if no actions can be performed for the case given its current status. A button will be gray if you do not have security rights to the action. Refer to Buttons Are Used To Transition A Case for more information.

When the user adds a new case or changes the state of a case manually the system attempts to auto-transition the case to subsequent statuses as necessary. If auto-transition rules apply to the new state (and to subsequent ones) they would be executed right away. If the case has been automatically transitioned to its current state the following message area appears right after the action area. If an error is encountered in the process a corresponding error message is displayed. Refer to Automatic Transition Rules for more information.

Note:

This section only appears when a case has just been automatically transitioned to its current state online. It only remains visible until the data for the case is refreshed.

Use the Comment area to describe anything interesting or unusual about the case.

Person references the person associated with this case. This field is suppressed if the Case Type indicates that a person is not allowed on cases of this type. This field is protected if the case is closed (i.e., if its status is defined as being final). This value is defaulted to the Person currently displayed in the Dashboard.

Account references the account associated with this case. This field is suppressed if the Case Type indicates that an account is not allowed on cases of this type. This field is protected if the case is closed (i.e., if its status is defined as being final). This value is defaulted to the Account currently displayed in the Dashboard.

Location references the location associated with this case. This field is suppressed if the Case Type indicates that a location is not allowed on cases of this type. This field is protected if the case is closed (i.e., if its status is defined as being final). This value is defaulted to the Location currently displayed in the Dashboard.

Responsible User references the user who has overall responsibility for the case. This field is suppressed if the Case Type indicates that a responsible user is not allowed on cases of this type. This field is protected if the case is closed (i.e., if its status is defined as being final).

The Contact Information area is used to define how to contact the individual who initiated the case. These fields are suppressed if contact information is not allowed on cases of this type. The fields cannot be modified if the case is in a closed status. The following information can be defined.

- Contact Person references the person who should be contacted. This defaults to the Person defined above.

- Preferred Contact Method indicates how the person prefers to be contacted. The following options are available:

- Email. If this method is selected, the Contact Person's email address appears adjacent.

- Fax. If this method is selected, the Contact Person's fax number appears (the system knows which of a person's phone numbers is a fax number by the phone type).

- Not Applicable. If the person doesn't want to be contacted (or the contact method is unusual), use this option. You might want to consider describing the situation in the Contact Instructions.

- Phone. If this method is selected, the Contact Person's phone number appears.

- Postal. If this method is selected, the Contact Person's address appears.

Contact Instructionsindicates any special instructions indicated for when or how to return a call.

Callback Phone Type, Callback Phone Number, and Extension indicate the actual phone number and phone type that should be used to call.

Characteristics

The Characteristics grid contains fields that contain important information about the case. This grid is suppressed if the Case Type does not use characteristics. This grid is protected if the case is closed (i.e., if its status is defined as being final).

You can only choose Characteristic Types defined as permissible for this case type. Refer to Additional Information for more information. If you attempt to use an Action to transition a case into a status that requires additional information, a pop-up will prompt you for the additional fields. Refer to Required Fields Before A Case Enters A State for more information.

Case - Case Portal

To view additional information associated with a case, open Menu > Work Management > Case and navigate to the Case Portal tab.

General Information

Case ID is the system-assigned unique identifier of the case.

Case Info contains a concatenation of important information about the case.

Object Portal

When information associated with the case has been stored in the case Character Large Object (CLOB) field (such as the data associated with a collections case), the Object Portal displays this information as-is. You cannot modify the case CLOB field data from this page, but case type algorithms can be configured to work with this data. For information on mapping data into CLOB fields, refer to the Business Object tips document Schema Nodes and Attributes.

Case - Log

To view the log entries associated with a case, open by selecting Menu > Work Management > Case and navigate to the Log tab.

Description of Page

The Log grid displays log entries (in reverse chronological order) that audit the progress of the case. Please note the following about the entries in this grid:

- The system automatically creates log entries when a case is created, every time its status changes, or whenever an error occurs during the transition of a case. Algorithms plugged into a case type state can also be configured to create log entries. You cannot modify or delete the log entries.

- You can manually add a log entry by pressing the + button and enter the Details. You cannot modify or delete this information after saving it.

- The following information appears in the grid:

- Log Date/Time contains the date and time the log entry was created.

- Details contains user-specified or system-generated information about the log entry.

- Related Object is populated on log entries that were created to record the creation of some other object. For example, if a case plug-in creates a customer contact, the related object contains information about the customer contact. Please note that if the object description is shown in blue, you can click on the object's description to drill down to the object.

- Log User contains the user who caused the log entry to be created.

- Log Type indicates how the log entry was created. The possible values are:

- Created. Only one entry per case will be of this type. This entry is automatically created by the system when the case is created.

- User Details. A user creates this type of entry manually.

- Status Transition. This type of entry is created by the system each time the case's status is changed (as a result of pressing one of the Action buttons).

- System. An algorithm on the case type state may be designed/configured to create this type of entry when it does something auditable. For example, an algorithm that creates a customer contact could insert a log entry to show that it did this (it will also populate the FK to the customer contact, which will appear in the Related Object column).

- Transition Error. The background status transition process creates an entry of this type if an error occurs when automatically updating a case to a subsequent status (as directed by either an Enter Status algorithm or an Auto-Transition algorithm). An entry of this type lists the case states involved with the failed transition, and the algorithm in which the error was generated.

- Exception. The background status transition process creates an entry of this type under the same circumstances as a Transition Error. A log entry of this type indicates why the background transition failed.

Note:

The values for this field are customizable using the Lookup table. This field name is CASE_LOG_TYPE_FLG.

Overdue Financial Obligations

The system periodically monitors how much your taxpayers owe to ensure they haven't violated your overdue rules. When a violation is detected, the system creates an overdue process. The overdue process contains the events meant to prod the taxpayer to pay (e.g., letters, To Do entries, write-off outstanding debt, etc.). This section describes how to manage your overdue debt processing.

Next in This Section

- Overdue Processing Background Information

- Overdue Process Maintenance

- Maintaining Collection Cases

- How To Perform Common Overdue Process Functions

- Collection Referral

- Overdue Control

Overdue Processing Background Information

In the section, The Big Picture Of Overdue Processes, we describe how overdue processing works and how to set up the control tables that automate most functions. You will find that many of your questions regarding when and how overdue processes are created and canceled are described in this section.

Overdue Process Maintenance

An overdue process is a series of events (e.g., letters, ToDo entries) meant to encourage an account to pay its delinquent debt. The topics in this section describe the pages on which overdue processes are maintained.

Fastpath:

Refer to The Big Picture Of Overdue Processes for background information.

Next in This Section

- Overdue Process - Main

- Overdue Process - Events

- Overdue Process - Log

Overdue Process - Main

The Main page contains core overdue process information. Open this page using Menu > Case Management > Overdue Process.

Description of Page

Fastpath: Refer to How To Perform Common Overdue Process Functions for more instructions describing how to use this page.

Overdue Process displays a concatenation of important information about the process. Overdue Process ID is the system-assigned unique identifier of the process. These values only appear after the overdue process is added to the database.

Note: Summary information may be overridden. Refer to Overdue Process Information Is Overridable for how your implementation can override the summary information that appears throughout the system.

Account ID identifies the overdue process's account.

Note: Multiple overdue processes may be linked to an account. It's important to be aware that it's possible for multiple, active overdue processes to be linked to an account. The Alert zone will contain a summary of the account's overdue processes, assuming your implementation has configured the appropriate alerts.

Status defines the state of the overdue process. The following values may exist:

- Active, Events Pending. Overdue processes are initially created in this state. An overdue process remains in this state until there are no Pending or Waiting events.

- Inactive, Canceled by User. An overdue process will exist in this state when it's been manually canceled by a user. Navigate to the Log tab to see when this happened and who did it.

- Inactive, Canceled by System. An overdue process will exist in this state when it's been canceled by the system (typically because the overdue obligations were satisfied). Navigate to the Log tab to see when this happened.

- Inactive, Completed. An overdue process will exist in this state when the system completes its last event. Navigate to the Log tab to see when this happened.

The Cancel button appears if the overdue process is Active, Events Pending and the process's Overdue Process Template has a Cancel Logic plug-in. Click this button to cancel the process.

The Trigger Events button appears if the overdue process is Active, Events Pending. Click this button to activate all pending events that are ready for activation.

Note: If you can't wait for the Overdue Event Manager to run. The Overdue Event Manager is a background process that activates events on their trigger date. If you don't want to wait for this process to run, you can click the Trigger Events button on the Main tab to activate the process's events (that are ready for activation).

Overdue Process Template defines the template that was used to create the overdue process's events. You can override these events on the Events page. This field is unprotected when the process is Active and all events are in either the Pending or Canceled states.

Note: Changing the template. If you change the template, the system will delete the events and replace them with the new template's events.

Start Date/Time defines the start date/time of the overdue process. This field is protected after the overdue process is saved on the database. This field is used to derive the trigger date of some overdue events when the process is first created. Subsequent changes to the start date change the trigger dates on the events accordingly.

Inactive Date/Time is the date and time that the overdue process became Inactive. This field is hidden if the process is Active. You can see more details about when and how the inactivation occurred by navigating to the Log tab.

Enter any Comments about the overdue process. This field is protected when the overdue process is Inactive.

The Collecting On grid holds the overdue objects. For example, if this process manages overdue obligations, the grid contains a list of the obligations being collected on by this process. This grid is unprotected when the process is Active. The following points describe the columns that appear in the grid:

- Press the + button to add a new overdue object to the process.

- Press the - button to remove an overdue object from the process.

- The next column contains the unique identifier of the overdue object. For example, if this process manages overdue obligations, this column will contain the obligation ID. The type of object that's specified in this column is control by the overdue process template.

- Original Amount contains the original amount of the overdue object.

- Unpaid Amount contains the unpaid amount of the overdue object.

The Trees at the bottom of the page show a variety of information about the overdue process including its events. You can click on hyperlinked tree nodes to navigate to the page on which the related object is maintained.

Overdue Process - Events

This page contains the activities that are performed to persuade the taxpayer to pay the outstanding debt. Open this page using Menu > Case Management > Overdue Process and navigate to the Events tab.

Description of Page

Note: Refer to How To Perform Common Overdue Process Functions for more instructions describing how to use this page.

Refer to the first tab for a description of Overdue Process and Overdue Process ID.

The Overdue Events scroll contains the process's overdue events. Refer to Overdue Processes Are Created From Templates for information about how the system defaults a process's events from its template.

Note: All information in the scroll is protected if the event's Status is Complete or Canceled.

- Event Sequence is the unique identifier of the event.

- Status defines the state of the event.

- The Cancel button appears if the event is Pending or Waiting, and the event's Overdue Event Type has a Cancel Logic plug-in. Click this button to cancel the event. The user is prompted for an Overdue Event Cancel Reason and Cancellation Comments.

- Cancellation Comment is visible for a Canceled event.

- The Overdue Event Type defines the event's activity (e.g., Email sent, a To Do entry is generated, a letter is sent).

- The remaining fields work in unison:

- If Dependent on Other Events is turned on, the event can only be triggered after the events specified in the Event Dependencies grid are all Complete or Canceled. You use the Days After field to define when this event is activated. For example, if you enter 5, this event will be activated 5 days after all of the dependent events are completed / cancelled. If you enter 0, this event will be activated immediately after the dependent events are completed / cancelled. Refer to Calendar vs. Work Days for a descriptions of how days are counted.

If all dependent events are already Completed or Canceled, you cannot specify Days After. Rather, you must enter the desired activation date in the Trigger Date field.

- If Dependent on Other Events is turned off, enter the desired activation date in the Trigger Date field. If this field is off, the Days After field and the Event Dependencies grid are hidden.

Note: If you can't wait for the Overdue Event Manager to run. The Overdue Event Manager is a background process that activates events on their trigger date. If you don't want to wait for this process to run, you can click the Trigger Events button to activate the process's events (that are ready for activation).

Overdue Process - Log

This page contains log entries that highlight significant events in the process's life. Open this page using Menu > Case Management > Overdue Process and navigate to the Log tab.

Description of Page

Please note the following about the entries in this grid:

- The system automatically creates log entries when significant events occur. Refer to Overdue Log for more information.

- You can manually add a log entry to an Active process by pressing the + button and enter the Details. You cannot modify or delete this information after saving it.

- The following information appears in the grid:

- Date/Time contains the date and time the log entry was created.

- Details contain the user-specified or system-generated information about the log entry.

- Related Object is populated on log entries that were created to record the creation of some other object. For example, if an overdue event creates a customer contact, the related object contains information about the customer contact. Please note that if the object description is shown in blue, you can click on the object's description to drill down to the object.

- Related Process / Event appears if the log entry was created by an overdue event. It references the unique identifier of the event.

- Log User contains the user who caused the log entry to be created.

- Log Type indicates how the log entry was created. The possible values are:

- User. A user manually created this entry.

- System. This system created this entry.

Maintaining Collection Cases

Use the Collection Case transaction to view and maintain pending or historic collection cases. Navigate using Menu > Case Management > Collection Case .

Next in This Section

- Collection Case Query

- Collection Case Portal

Collection Case Query

Use the query portal to search for a collection case. Once a request is selected, you are brought to the maintenance portal to view and maintain the selected record.

Collection Case Portal

This portal appears when a collection case has been selected from the Collection Case Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Collection Case Actions

- Collection Case

- Collection Case Log

- Collection Case Overdue Processes

Collection Case Actions

This is a standard actions zone.

If the collection case is in a state that has valid next states, buttons to transition to each appropriate next state are displayed.

In addition to possible next states, a collection case would typically include special action buttons. The action buttons would normally launch a BPA script that handles the additional processing required for the action; for instance, navigating to the appropriate page to create a pay plan.

If the collection case is in a final state, the state transition and action buttons are not displayed.

Collection Case

The Collection Case zone contains display-only information about the selected Collection Case.

Please see the zone's help text for information about this zone's fields.

Collection Case Log

This is a standard log zone.

Collection Case Overdue Processes

The Collection Case Overdue Processes zone contains display-only information about the overdue processes linked to the collection case.

How To Perform Common Overdue Process Functions

The topics in this section describe how to perform common overdue process maintenance functions. Refer to The Big Picture Of Overdue Processes for high-level information about overdue processing.

Next in This Section

- How To Create An Overdue Process

- How To Change Overdue Events

- How To Cancel An Overdue Process

How To Create An Overdue Process

99.9% of all overdue processes are created by the Overdue Monitor and require no human intervention. The other 0.1% are created by users on-line / real time. The following points describe how to create the 0.1%.

- Find the account that requires a new overdue process.

- After the account is populated, choose the Overdue Process + option on the account context menu to transfer to the overdue process transaction in add mode for the account.

- After the Overdue Process - Main page appears, specify the appropriate Overdue Process Template. The template is used to default the process's events (the template also controls numerous business rules, for example, when it will be canceled, how it will be canceled, etc). Refer to How To Change Overdue Events for a description of how you can override these events.

- Enter the overdue object(s) in the Collecting On grid. You must define at least one object.

- Save the overdue process.

How To Change Overdue Events

When an overdue process is first created, it has one or more overdue events. The events are the activities that will be performed to persuade the taxpayer to pay the outstanding debt.

The number and type of events that are created when an overdue process is initiated are defined on the overdue process's overdue process template. The following points describe how to add / change / delete events on an overdue process if the defaulted events are not satisfactory.

- Find the account with the overdue process whose events need to be changed.

- After the account is populated, choose the Overdue Process option on the account context menu to transfer to the overdue process transaction in update mode for the account. Note that an account's Active overdue processes can be selected from the Alert zone, assuming your implementation has configured the appropriate alerts.

- To add a new event, transfer to the Overdue Process - Events tab and press the + button in the Overdue Events scroll. At this point, the event has not been added to the database; rather, it just exists in memory. Before you add the event to the database, you must specify the following information:

- Choose an Event Sequence so that the new event will be positioned properly in respect of the other events.

- Choose a Status of Pending.

- Choose the desired Overdue Event Type.

- If the activation of the new event is dependent on the successful completion of earlier events, turn on Dep on Other Event and then:

- specify the sequences of the dependent events in Event Dependencies and

- specify the how many days after the completion of the last dependent event that the new event should be triggered.

- If the activation of the new event is NOT dependent on the successful completion of earlier events, turn off Dep on Other Event and use Trigger Date to define the date on which the event should be activated (i.e., completed).

- To delete an existing event, click on the event in the tree on Overdue Process - Main. This will transfer you to the Events tab where you can click the - button to remove the event. At this point, the event has not been removed from the database; rather, it's been removed in memory.

- To change an existing event, click on the event in the tree on Overdue Process - Main. This will transfer you to the Events tab where you can make the desired changes.

- After all desired changes have been made, save the overdue process.

How To Cancel An Overdue Process

The system will cancel an overdue process when the cancel criteria defined on the overdue process are satisfied. The following points describe how to manually cancel an overdue process.

- Find the account with the overdue process to be cancelled.

- After the account is populated, choose the Overdue Process option on the account context menu to transfer to the overdue process transaction in update mode for the account. A list of all overdue processes associated with the account appears. If only one overdue process exists, it is automatically selected for you. Note, an account's Active overdue processes can be selected from the Alert zone, assuming your implementation has configured the appropriate alerts.

- On the Main tab, click Cancel and answer any prompts.

Collection Referral

The Collection Referrals page contains information about an account's debt that has been referred to a collection agency.

Fastpath: Refer to Collection Agency Referrals for more information about how the system creates and maintains collection agency referrals as part of overdue processing. In theory, you need only access this page if you need to override the automated processing.

Open Menu > Case Management > Collection Agency Referral to maintain this information.

Description of Page

The Agency Referrals scroll contains one entry for every collection agency referral associated with the account. The following information is defined for each referral.

Use Collection Agency to define the agency to which the referral is being sent.

Start Date is the date on which the referral was initially created.

Referral Status defines if the referral is Active or Closed.

Use Comments to describe anything unusual about the referral.

The grid contains the history of interactions with the collection agency. Each time an account's debt is referred to a collection agency, the system creates a referral history record.

You can communicate changes about the referral by inserting a new row in the collection. For example,

- If you need to change the referral amount, insert a row and indicate the Creation Date and a Referral History Reason of Change Referral.

- If you need to cancel the referral, insert a row and indicate a Referral History Reason of Referral Cancellation.

- If the customer pays, insert a row and indicate a Referral History Reason of Referral Paid.

- If you need to add a new referral, insert a row and indicate a Referral History Reason of Initial Referral.

Collection agency referral records are interfaced to the respective collection agency using the batch process defined on the collection agency control record (refer to Setting Up Collection Agencies). The Batch Control process and the respective Batch Number in which the records were interfaced to the collection agency are displayed adjacent to the referral history reason.

The System Generated switch is on for those collection agency referrals created by other system events. Refer to Collection Agency Referrals for more information.

Overdue Control

This section describes functionality that provides the ability to control the types and volumes of overdue events that are activated by the overdue event manager.

Next in This Section

- Overview

- Maintaining Overdue Controls

- Common Overdue Control Procedures

Overview

The Overdue Event Manager (C1-ODET) is configured to activate all events whose trigger date has arrived. However, there are some implementations that want to control volumes and types of overdue events that are activated. The product provides an object called Overdue Control that may be used by implementations that prefer to work this way. The topics in this section describe overdue control functionality.

Creating Overdue Controls

A user manually creates an overdue control and defines criteria for selecting overdue events to process.

Fastpath: Refer to Common Overdue Control Procedures for more information.

Activating the Overdue Events

After a user creates the overdue controls, there shouldn't be any additional work for a user to do. Background processes process the overdue control records in two steps. One step selects overdue processes with events that satisfy the selection criteria. The second step processes the selected overdue processes and activates them.

Maintaining Overdue Controls

Use the Overdue Control transaction to view and maintain overdue control records. Navigate using Menu > Case Management > Overdue Control.

Next in This Section

- Overdue Control Query

- Overdue Control Portal

Overdue Control Query

Use the query portal to search for an overdue control. Once an overdue control is selected, you are brought to the maintenance portal to view and maintain the selected record.

Overdue Control Portal

This portal appears when an overdue control has been selected from the Overdue Control Query portal.

The topics in this section describe the base-package zones that appear on this portal.

Next in This Section

- Overdue Control - Main Information

- Overdue Control - Log

Overdue Control - Main Information

The topics in this section describe the base-package zones that appear on this tab.

Overdue Control

The Overdue Control zone contains display-only information about the overdue control.

Please see the zone's help text for additional information about the data displayed in the overdue control.

Refer to the Common Overdue Control Procedures section for more information about common functions.

Overdue Control - Log

Navigate to the Log tab to view the logs for an overdue control.

Common Overdue Control Procedures

This section describes common overdue control procedures based on functionality provided in the base product.

Manually Creating an Overdue Control

Use this procedure to manually add a overdue control.

- Use the menu navigation to launch the add an overdue control dialogue.

- Select the overdue control type from the dropdown.

- Provide the overdue event type whose events should be activated. Fill in additional criteria to limit the selection of overdue events when desired. Note that if no criteria is provided, all pending overdue events with a trigger date on or before the current date are selected.

- Save the record.

At this point the user can opt to click Process causing the system to select the overdue events that match the criteria. However, the expectation is that the user allows the deferred monitor to pick up the record for processing.

Classic Billing

The topics in this section refer to classic, rate-based billing functionality.

Refer to Billing for information about calculation rule based billing.

Next in This Section

- The Big Picture of Billing

- Maintaining Bills

- Financial Transactions On A Bill

- Maintaining Bill Segments

- Multi Cancel/Rebill

- Obligation Billing History

- Bill Exception

- Bill Segment Exception

- Maintaining Billable Charges

- Uploading Billable Charges

The Big Picture of Billing

Billing is one method used to establish tax assessments for bill-based tax types. Most obligation types will not use billing functionality.

Fastpath:

Refer to Configuring Obligation Types for a description of the different obligation types.

The billing process is used when the tax authority has the information required to calculate and assess tax for a taxpayer, in contrast to tax types where the taxpayer must file a tax return.

Overdue processing is used to govern collections processing, including the sending of collections letters to taxpayers with past due obligations.

Fastpath:

Refer to Overdue Financial Obligations for more information on overdue processing.

The topics in this section provide background information about a variety of billing topics.

Next in This Section

- An Illustration Of A Simple Bill

- A High Level Overview Of The Bill Creation Process

- Bill Errors

- Cancel / Rebill Incorrect Bill Segments

- How Rates Affect The Information On Bill Segments

- Bill Frequency - Bill Cycle vs Bill Segment Duration

- Prorating Charges When a Rate is Applied

- Batch Billing

- Billing Financial Transaction Considerations

- The Source Of Bill Routing Information

- Bill Messages

- A Bill May Affect More Than Just Taxpayer Balances

- Using Billable Charges for Pass Through / Convergent Billing

- Printing Bills

- Idiosyncratic Manual Bill Cancellation

An Illustration Of A Simple Bill

The following diagram illustrates a simple bill:

The following concepts are illustrated above:

A bill is produced for an account

A bill is produced for an account. Over time, an account receives many bills.

A bill summarizes financial transactions

A bill contains information about the various financial transactions that have taken place since the last bill was produced (i.e., payments, adjustments, and bill corrections). The above illustration shows a bill with financial transactions for new charges, a payment, and an adjustment.

A bill is routed to persons

A copy of the bill is sent to every person linked to the account who requires a copy of the bill.

A bill contains messages

A bill may contain messages.

A bill typically contains bill segments

A bill typically contains one bill segment for every active billable obligation linked to its account.

A bill segment contains calculation details

A bill segment contains information showing how the segment was calculated and how it should be printed on the taxpayer's bill.

A High Level Overview Of The Bill Creation Process

When the system is asked to produce a bill for an account, it attempts to create one or more bill segments for every non-cancelled / non-closed billable obligation linked to the account. Whether or not an obligation contributes bill segment(s) to a bill is a complicated subject as the system supports a wide variety of bill segment creation methods.

The system determines the bill segment creation method to use from the bill segment type on the obligation's obligation type.

Some bill segment creation methods may apply the obligation's rate to a specific number / amount in order to calculate how much the taxpayer owes. The details of the calculations are captured in the bill calculation lines. For more information, refer to How Rates Affect The Information On Bill Segments for the details. Refer to Effective Dates & Proration for information about how the system prorates changes to rates and prices during a bill period.

If errors are detected during the bill segment creation process, the bill segment is saved with its error. The system then proceeds to the account's next obligation. This way, a user can see all problematic bill segments so they can be corrected en masse. Refer to Bill Errors for information about how to deal with bill errors.

When every segment on a bill is error free, the bill is ready to be completed. When a bill is completed, the system:

- Creates a bill routing for each person linked to the account who requires a copy of the bill. The routing information controls the format of the printed bill and how the bill is sent to the person. Refer to The Source Of Bill Routing Information for the details.

- Links all bill messages to the bill. A bill message can come from a variety of sources. Refer to The Source Of Bill Messages for the details.

- If the Freeze At Bill Completion installation option has been turned on:

- All freezable bill segments will be frozen.

- All freezable adjustments whose adjustment type indicates Freeze At Bill Completion will be frozen.

- Sweeps recent financial transactions that have been created since the last bill was completed.

- There are several other functions that happen at completion time. Refer to the description of the Complete button under Bill Lifecycle for the details.

And that's it; the bill can now be sent to the taxpayer.

The remaining topics in this section provide more information about the creation and completion of bills.

Note:

Batch and real-time bill creation. Anything the batch bill process does for whole sets of accounts, you can do to a specific account on-line / real time. Refer to How To Create A Bill For All Obligations Linked To An Account for information about how to create a bill on-line / real time. Refer to Batch Billing for more information about the batch bill creation process.

Bill Errors

The topics in this section describe errors that are detected when the system creates a bill.

Next in This Section

- Bill Segment Errors

- Bill Completion Errors

Bill Segment Errors

If you consider the huge number of variables involved in the creation of a bill segment, it probably won't surprise you to learn that occasionally, some bill segments are in error.

Errors tend to be caused by missing or inconsistent data. Some examples of classic errors:

- Missing master data. For example, if a bill is supposed to be routed to the account's mailing address and the account doesn't have such an address, an error is generated.

- Missing rate data. For example, if a rate contains a taxpayer specific charge and there is no value defined on the taxpayer's obligation, an error is generated.

The system saves bill segments that are in error just as it saves bill segments that are error-free. This is done because bill segments are nothing more than a snapshot of the data that was used to calculate the charges. By saving the snapshot, you can see the information the system used when it detected the error and therefore more effectively fix the cause of the error. The standard way to fix an error is to:

- Look at the bill segment to determine the cause of the error.

- Correct the cause of the error.

- Regenerate the bill segment. Regeneration simply deletes the offending segment and recreates a new segment using the corrected information.

For every bill segment in error, a record is written to the Bill Segment Exception table.

Fastpath:

Refer to How To Correct A Bill Segment That's In Error for instructions describing how to correct a bill segment.

It's obvious but worth stressing that a bill may contain some segments that are perfect and others that are in error. Once all segments that are in error are corrected, the bill can be completed (and sent to the taxpayer).

If the bill segment in error was created as part of the batch bill process, the system attempts to fix the offending segment(s) when cyclical billing runs again by regenerating it. Therefore, if the cause of the error is fixed during the day, the system will automatically regenerate the bill segment when batch billing next runs; you don't have to manually correct each bill. And once a bill is error-free, it will be completed and sent to the taxpayer.

Fastpath:

Refer to Batch Billing for more information.

Bill Completion Errors

In addition to errors on bill segments, there may also be errors detected when the system attempts to complete a bill. For example, if the system cannot find a mailing address, the bill will be in error (as opposed to one of its bill segments).

Errors tend to be caused by missing or inconsistent data. Some examples of classic errors:

- Missing mailing address. For example, if the system cannot find an address to which the bill can be routed, it generates an error.

- Bill segments are in error. If a bill contains bill segments that are in error, it cannot be completed and an error is generated.

The system saves bills that are in error just as it saves bills that are error-free. This is done because bills are nothing more than a snapshot of the data that was used to calculate the charges. By saving the snapshot, you can see the information the system used when it detected the error and therefore more effectively fix the cause of the error. The standard way to fix an error is to:

- Look at the bill to determine the cause of the error.

- Correct the cause of the error.

- Recomplete the bill.

For every bill in error, a record is written to the Bill Exception table.

Fastpath:

Refer to How To Correct A Bill That's In Error for more information.

If the bill completion error was created as part of the batch bill process, the system attempts to recomplete the bill at the next cyclical billing run. Therefore, if the cause of the error is fixed during the day, the system will automatically complete the bill when batch billing next runs; you don't have to manually complete each bill.

Fastpath:

Refer to Batch Billing for more information.

Cancel / Rebill Incorrect Bill Segments

Sometimes the error on a bill segment is not detected by the system. Such errors occur when the data used to calculate the bill is valid, but wrong. For example, the sales tax percent was entered incorrectly on a rate factor.

There is no way the system can detect such problems and therefore the system freezes the bill segment and routes the bill to the taxpayer. To correct such a bill segment, you must cancel the offending segment and create a new segment (after correcting the cause of the problem). We refer to this process as cancel / rebill.

Fastpath:

Refer to How To Cancel / Rebill A Bill Segment for more information about how to cancel / rebill a frozen bill segment.

You must use the cancel / rebill process to correct problems on frozen bill segments. This is because a frozen bill segment can be thought of as having been posted to your general ledger (even if the GL interface hasn't run). And once a financial transaction is posted to the general ledger, it can only be removed via a reversal. Contrast this to bill segments that are in error - they can be deleted because they were never posted to the general ledger.

Fastpath:

Refer to Bill Segment Lifecycle for more information about the differences between bill segments that are frozen and those that are in error.

Note:

Bill segments are canceled / rebilled. It's important to stress that bill segments are canceled and rebilled (as opposed to bills). If every bill segment on a bill is incorrect, you must cancel / rebill each individual bill segment.

Note:

Note. Using the cancel or cancel/rebill functionality will cause the cancel and rebill details to be swept on to the taxpayer's next bill.

How Rates Affect The Information On Bill Segments

After a billable quantity has been compiled, the system applies the obligation's rate to the quantity to determine how much to charge the taxpayer. We refer to this process as "rate application". Refer to Rates for detailed information about rates.

Note:

Not all obligations use a rate! The obligation's obligation type defines whether or not the obligation needs a rate. The bill calculation algorithm plugged-in on the bill segment type that's referenced on the obligation's obligation type controls whether or not the system calls the obligation's rate to calculate charges. Refer to Defining Bill Segment Types for a description of the various bill segment creation algorithms that are supported in the system.

Note:

Your proration choices impact what appears on a bill. A rate contains a variety of effective-dated information (e.g., the prices are effective-dated, the structure of the rate is effective-dated, etc.). If this effective-dated information changes during a bill period, the system may need to prorate the charges. For example, if the sales tax percentage changes mid-period, the system can prorate the tax change (e.g., 20 days at 6% and 11 days at 6.25%). When you setup a rate, you define exactly how the system handles changes that occur during a bill segment. For example, you can tell the system that sales tax changes should not be prorated. Rather, it should use the value effective at the start / end of the bill period (note, you have several other options). We mention this because your choices have a large impact on how a rate affects the information on bill segments. Refer to Effective Dates & Proration for more information.

Rate application is a very sophisticated process as it can affect every aspect of a bill segment. The following points describe how rate application works at a high-level:

- The calculation details that were amassed earlier are passed into rate application.

- Next, the rate schedule's rate quantity rules (if any) are executed. Rate quantity rules are used to calculate rate quantities (RQ) referenced in the rate that cannot be derived from the calculation details. For example, if you have a rate that has a charge based on the number of days in the bill period, a rate quantity rule would be necessary to calculate the number of days in the bill period.

- The system determines which of the rate's rate versions should be processed. Note, a flag on the rate schedule allows you to control what happens if multiple rate versions are detected during the bill period. A bill segment "calculation detail" is created for each such rate version. Each calculation detail contains the results of executing the rate version's rate components (where a separate bill line is created for each rate component). Each bill line contains:

- An audit of what was priced.

- How the printed bill line should look (if the bill lines is printed).

- How the amount of the bill line should be booked in the general ledger.

Note:

There are many plug-in spots available on a rate component. These plug-ins can manipulate virtually every aspect of the bill segment. This means if you require functionality that isn't support by the base package rate components, you can build additional rate component plug-ins to do whatever you need.

- After every rate version is processed, rate application returns the calculation details to the process that called it. This point is important as it means that rate application executes in memory (i.e., it does NOT insert the calculation details on the database, rather, it returns them to whatever process called rate application). Because rate application executes in memory, it can be used to perform billing calculations in many parts of the system. For example:

- Billing uses rate application to calculate the charges that are eventually saved on the bill's bill segments.

- The Rate Check transaction calls rate application when you want to check a rate real-time. When you use this transaction, you enter the quantities that are passed into rate application and then rate application shows you the calculation details that result.

Fastpath:

Refer to Rates for more information about how rates are constructed.

Bill Frequency - Bill Cycle vs Bill Segment Duration

An account's bill cycle defines when the system attempts to create bill segments for the account's billable obligations. The word "attempt" is stressed because an obligation may not have a bill segment on every bill created for its account.

Some examples will help make the point:

- An account may be on a monthly bill cycle (meaning we attempt to create a bill every month for the account) but contain only biannual obligations. However, this is not sensible. Why? Because the system would attempt to create a bill every month for the account's obligations, but only twice during the year would it succeed (because the obligations have a biannual duration).

- An account may be on a biweekly bill cycle (meaning we attempt to create a bill every 2 weeks for the account) and contain a mixture of biweekly, monthly, and quarterly obligations. In this scenario, every two weeks the system would create a bill that contains at least one bill segment (for the biweekly obligation). However, 12 times a year, the bill will contain an additional bill segment for the monthly obligation. And 4 times a year, the bill will contain one more bill segment (for a total of 3) for the quarterly obligation.

In sum, the account's bill cycle controls when the system attempts to create a bill for the account's obligations. Whether an obligation contributes a bill segment to the bill is a complicated subject. The topics in this section describe how the system knows it's time to create a bill segment for an obligation.

Note:

Important! An account's bill cycle should attempt to create bill segments at least as often as the shortest obligation duration. For example, if an account has both monthly and quarterly obligations, the account should be placed on a monthly bill cycle. Refer to How Does An Account Get Its Bill Cycle? for more information.

Next in This Section

- Ways To Control The Start Date Of A Bill Segment

- Ways To Control The End Date Of A Bill Segment

- Preventing Short Bill Segments

Ways To Control The Start Date Of A Bill Segment

Bill segments produced for an obligation have two time periods:

- The bill segment period. The bill segment period defines the entire period of time covered by a bill segment's charges.

- The billable period. The billable period defines the period of time used to calculate the number of days for daily charges.

The billable period almost always starts one day after the bill segment period. The billable period always ends on the bill segment's end date. For example, a bill segment period that spans 5-Jan-2002 through 6-Feb-2002 will almost always have a corresponding billable period of 6-Jan-2002 through 6-Feb-2002. The reason that the start dates don't match is because a bill segment's start date equals the end date of the prior bill segment (i.e., the start date was already counted in the previous bill segment's period and we don't want to count it twice).

Ways To Control The End Date Of A Bill Segment

The following points describe the different methods that can be used to define the end date on an obligation's bill segments:

- Bill Period Schedule. Obligations may have the end date of their bill segments defined on the user-maintained bill period calendar. 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).

- Anniversary. In addition to the Bill Period Calendar method, obligations may have their bill segment end date based on the obligation start date. For example, if an obligation started on the 16 th of some month, the ongoing bill segments will start on roughly the 16 th of each month.

- ASAP. For obligations that use neither the Bill Period Calendar nor Anniversary methods, the system assumes the end date of a bill segment is the current date.

- Billable Charge. For non-metered obligations that exist to levy billable charges, the start AND end dates are defined on the billable charge information that is entered by a user or interfaced from an external system.

The topics in this section discuss each of the above methods.

Next in This Section

- Using The Bill Period Schedule Method

- Using The Anniversary Method

- Using Billable Charges

Using The Bill Period Schedule Method

The bill period schedule method causes the bill segment end date to be calculated using a bill period schedule. The bill period's schedule defines when bill segments are produced and their respective end dates. This method is used when the bill segment needs to fall on strict calendar boundaries (e.g., quarterly bills that end on the last day of the quarter).

The obligation's obligation type indicates if the obligation uses this method. If so, the obligation type also specifies the bill period whose schedule defines the end dates.

Note:

Future and Past End Dates. It's important to be aware that a bill period schedule can be used to generate end dates that are in the future or in the past.

Using The Anniversary Method

The anniversary date method causes the bill segment end date to be calculated based on the first day of service. For example, if an obligation started on the 16 th of some month, the ongoing bill segments will start on roughly the 16 th of each month. When using this method, you also define the applicable billing frequency (i.e., monthly, bi-monthly, quarterly, etc.).

The following table contains the bill periods for an obligation's starting on 23-Feb-99 that uses a monthly frequency.

Start Date

End Date

Billing Days

23-Feb-99

25-Mar-99

30

25-Mar-99

25-Apr-99

31

25-Apr-99

25-May-99

30

25-May-99

25-Jun-99

31

25-Jun-99

25-Jul-99

30

25-Jul-99

25-Aug-99

31

25-Aug-99

24-Sep-99

30

24-Sep-99

24-Oct-99

30

24-Oct-99

24-Nov-99

31

24-Nov-99

24-Dec-99

30

24-Dec-99

24-Jan-00

31

24-Jan-00

23-Feb-00

30

23-Feb-00

25-Mar-00

31

Note:

Future and Past End Dates. It's important to be aware that anniversary billing can generate end dates that are in the future or in the past. The future-option generates the next anniversary date after the current date. The past-option generates the anniversary date that immediately precedes the current date.

The obligation's obligation type indicates if the obligation uses this method. If so, the obligation type also specifies the billing frequency that determines the amount of time between bill segments.

Fastpath:

For more information about the obligation type attributes that control this method, refer to Setting Up Obligation Types.

Using Billable Charges

Bill segments for billable charge obligations have both their start and end dates defined on the respective billable charge.

Fastpath:

For more information about billing billable charges, refer to How To Create An Ad-hoc Bill. For more information about creating a billable charge, refer to Maintaining Billable Charges. For more information about interfacing a billable charge from an external system, refer to Uploading Billable Charges.

The obligation type indicates if the obligation uses this method.

Fastpath:

For more information about the obligation type attributes that control this method, refer to Setting Up Obligation Types.

Preventing Short Bill Segments

Every billable obligation type contains an attribute defining the minimum number of days on a bill segment. Whenever the system attempts to create a bill segment other than the final bill segment, it checks if the number of days is at least as great as the minimum. If not, the bill segment will not be created as part of this bill run. Rather, the system waits until the number of days in the bill segment is at least as large as the minimum. This is true for all methods of bill duration calculation.

Prorating Charges When a Rate is Applied

It is possible for some of the prices that appear on a bill segment to change during the course of the bill period.

Fastpath:

Refer to Effective Dates & Proration for more information about how charges are prorated during rate application.

Batch Billing

If your implementation uses cyclical billing, most bills will be created by the batch bill process (known by the batch control ID of BILLING) and require no human intervention before they can be finalized and sent to a taxpayer. The others will be created by users on-line / real time. This section discusses several important concepts associated with batch billing.

Next in This Section

- Window Billing And The Bill Cycle Schedule

- Confirming A Batch Of Bills Before Completing Them

- Canceling A Batch Of Bills After They're Complete

- Reopening A Batch Of Bills After They're Complete

- Fixing Errors Detected In Batch Billing

- Completing Pending Bills

Window Billing And The Bill Cycle Schedule

Fastpath:

Refer to The Cyclical Billing Process & Window Billing for more information about how an account's bill cycle dictates when a taxpayer is billed.

Confirming A Batch Of Bills Before Completing Them

If you're implementing new rates or if something unusual is being introduced that affects billing and your implementation is using the cyclical billing process, you may want to turn off the bill cycle schedule's Freeze and Complete switch. If this switch is off, the system creates bills, it just doesn't freeze and complete them. You can then review the entire batch of bills to make sure they're clean.

- If you find the bills are wrong, correct the source of the error and rerun the bill cycle. The system will remove all incomplete bills and then reproduce them using the corrected information in the system.

- If you find the bills are correct, turn the Freeze and Complete switch on and rerun the cycle. The system will remove all incomplete bills and then reproduce them. Assuming nothing changed, the bill amounts will be the same.

Fastpath:

Refer to Setting Up Bill Cycles for more information.

Canceling A Batch Of Bills After They're Complete

If you need to cancel an entire batch of bills because they were created using faulty data (e.g., the wrong tax rate was defined in the rate), you can. A background process called MASSCNCL exists for this purpose.

This background process will cancel all the frozen bill segments for the latest run of a given bill cycle's schedule. Optionally, you can cancel bills for a given bill date within the bill cycle's schedule. The cancel reason used on the bill segment is the one marked as the bill cancel reason for mass cancel. Refer to Setting Up Bill (Segment) Cancellation Reasons for more information.

When the cycle is billed again, new bill segments will be created, and the original bill segments and the cancellations will automatically be hidden from the taxpayers.

Reopening A Batch Of Bills After They're Complete

If you need to reopen an entire batch of bills because they were completed prematurely, for instance if appraisal data did not get updated before billing ran, you can. A background process called MASSROBL exists for this purpose.

This background process will reopen all the bills for a given bill date for the latest run of a given bill cycle's schedule.

Fixing Errors Detected In Batch Billing

If an "error" bill segment is created by the batch billing process, the system attempts to fix the offending segment at the next cyclical billing run by regenerating it using the information that exists at that time. Therefore, if the cause of the error is fixed during the day, the system will automatically regenerate the bill segment when batch billing next runs; you don't have to manually correct each bill. And, once a bill is error-free, it will be completed and sent to the taxpayer.

Note:

Important! Automatic regeneration only works during the account's bill window. If an "error" bill segment is not successfully regenerated on the last night of the account's bill cycle, it will remain in error until the next time the account's cycle runs (unless a user corrects it real time). At that time, the system will generate another bill error indicating the prior bill segment is in error (and then there'll be two bill segments in error).

Completing Pending Bills

If you need to complete pending bills created by the batch billing process, you can. A background process called C1-BLCMP, exists for this purpose.

This background process will complete all pending bills on a given bill date for a given bill cycle's schedule. This process does not delete and regenerate freezable bill segments linked to pending bills.

Fastpath:

Refer to Bill Errors for more information.

Billing Financial Transaction Considerations

The topics in this section provide information about the financial impact of a bill segment.

Next in This Section

- Billing - Current Balance versus Payoff Balance

- The Source Of GL Accounts On A Bill Segment's Financial Transaction

Billing - Current Balance versus Payoff Balance

A bill segment's financial transaction affects an obligation's payoff balance and/or current balance. In this section, we describe these two balances.

CAUTION:

If you do not understand the difference between payoff balance and current balance, refer to Current Amount versus Payoff Amount.

Next in This Section

- When Current Balance Equals Payoff Balance

- When Current Balance Differs From Payoff Balance

- Bill Segment Type Controls Which Balance(s) Are Affected

When Current Balance Equals Payoff Balance

For most obligations, payoff balance and current balance are always the same (or in colloquial speech - the amount the taxpayer thinks they owe equals what they really owe). Let's run through a typical example. The values in the payoff balance and current balance columns reflect the amount due after the financial transaction has been applied (i.e., the running balance):

Date

Financial Transaction

Payoff Balance

Current Balance

1-Jan-99

Bill: $125

125

125

15-Jan-99

Payment: $150

-25

-25

2-Feb-99

Bill: $175

150

150

14-Feb-99

Payment: $150

0

0

3-Mar-99

Bill: $200

200

200

15-Mar-99

Payment: $150

50

50

2-Apr-99

Bill: $225

275

275

As you can see, payoff balance and current balance are always in sync.

When Current Balance Differs From Payoff Balance

For some obligations, payoff balance and current balance differ. In other words, the amount the taxpayer thinks they owe differs from what they would owe if they wanted to pay off their account.

Note: The base product does not currently support billable obligations types where the current balance would differ from payoff balance as described above.

Bill Segment Type Controls Which Balance(s) Are Affected

Every bill segment references a bill segment type (the bill segment type comes from its obligation's obligation type). The bill segment type controls how payoff balance and current balance are affected by the bill segment amount. It also controls the algorithm used by the system to calculate the bill segment's bill lines.

Fastpath:

Refer to Defining Bill Segment Types for more information about how bill segment type affects how a bill segment is produced and how its financial transaction is generated.

The Source Of GL Accounts On A Bill Segment's Financial Transaction

A bill segment's financial transaction also contains the double-sided accounting entry that defines how the bill segment affects the general ledger.

Fastpath:

Refer to The Source Of GL Accounts On Financial Transactions for a description of where the system extracts the distribution codes used to construct the GL accounts.

The Source Of Bill Routing Information

When a bill is completed, the system creates a bill routing for each person linked to the account who receives a copy of the bill. The bill routing record contains the information that controls how, where and to whom a bill is sent.

The following points describe how this works:

- Each person who receives a copy of an account's bill is listed on the account's person information.

- A bill routing is created for each such person when the bill is completed.

- The information that appears on the bill routing record is controlled by the bill route type specified on the respective account / person information:

- If the bill route type indicates the person's bills are routed via fax, the "address line 1" address constituent is populated with the person's fax number. The system knows which of a person's phone numbers is a fax number by the phone type. If the person has multiple fax numbers, one is selected at random.

- If the bill route type indicates the person's bills are routed via email, the "address line 1" address constituent is populated with the person's Email address.

- If the bill route type indicates the person's bills are routed via the postal service, the address constituents are populated with the address specified on the account / person's bill address source. Note, if the person has a seasonal address effective on the business date, the seasonal address will be used regardless of the value of bill address source.

Fastpath:

Refer to Printing Bills and How To Reprint A Bill (For The Original Recipients or For Someone New) for more information. Refer to Account - Person Information for information regarding how to control who receives a copy of a bill, where the bill is sent, and how the bill is formatted.

Bill Messages

The topics in this section describe how messages are linked to a bill and bill segment.

Next in This Section

- The Source Of Bill Messages

- Substituting Field Values Into A Message

The Source Of Bill Messages

When a bill is completed, the system sweeps bill messages from the following sources onto the bill.

Note:

Bill or Bill Segment Messages. Bill messages will be linked either to the bill or to one of its bill segments depending on the source of the bill message code. In other words, messages associated with an obligation (directly or indirectly) will be linked to the bill segment; messages associated with an account (directly or indirectly) will be linked to the bill.

- All permanent and temporary bill messages linked to an account are linked to the bill when it is completed. Refer to Account - Bill Messages for more information. Note well that all temporary bill messages are removed from the account when they are swept onto a bill (a temporary message is swept onto the next bill produced for the account).

- The system checks if the bill's account's account type has bill messages. If so, it links all such messages that are effective on the bill date to the bill when it is completed. Refer to Setting Up Account Type Bill Messages.

- All permanent and temporary bill messages linked to obligations that contributed bill segments to the bill are linked to their respective bill segment when the bill is completed. Refer to Obligation - Miscellaneous for more information. Note well that all temporary bill messages are removed from the obligation when they are swept onto a bill segment (a temporary message is swept onto the next bill segment produced for the obligation).

- The system checks if each bill segment's rate has bill messages. If so, it links all such messages that are effective on the bill segment's start date to the bill segment when the bill is completed. Refer to Rate Schedule - Bill Messages.

In addition, a user may manually add an ad hoc message to a bill.

And finally, you can develop your own background processes and algorithms that add bill messages to accounts, obligations, bills and/or bill segments. Refer to Substituting Field Values Into A Bill Message for examples.

Substituting Field Values Into A Message

Many bill messages contain static text (i.e., the message is the same on every bill). However, the system supports messages whose contents are dynamic. For example, consider the bill message Your 2007 taxes were reduced due to your homestead deduction of $6,000. This message contains two substitution values (the year and the amount) as is therefore considered dynamic.

Dynamic messages can be implemented as follows:

- Create a bill message code whose Message on Bill contains substitution values. For example, the bill message code to produce the message illustrated above would contain the following Message on Bill - Your %1 taxes were reduced due to your %2 of %3.

- Use either of the following methods to link the message code and its substitution parameters to the bill:

- Create a background process or algorithm to insert a permanent or temporary bill message on the appropriate accounts. Then, when an account's bill is next completed, the system will sweep the message (and its substitution parameters onto the bill).

In addition to inserting the appropriate bill message code, your background process / algorithm must also insert the appropriate substitution values. The name of the table in which account messages are inserted is CI_ACCT_MSG. The name of the table in which a message's substitution values are inserted is CI_ACCT_MSG_PRM (you will insert one row for each substitution field).

- Rather than adding the dynamic message to account (and then letting the bill completion logic transfer the account message to the bill), you could construct a bill completion algorithm that adds the message code and substitution values on the bill (during bill completion). The name of the table in which bill messages are inserted is CI_BILL_MSGS. The name of the table in which a message's substitution values are substituted is CI_BILL_MSG_PRM (you will insert one row for each substitution field).

A Bill May Affect More Than Just Taxpayer Balances

The topics in this section provide information about obscure things that may happen when a bill is created, frozen, or canceled.

Next in This Section

- FT Freeze Repercussions

FT Freeze Repercussions

Fastpath:

Refer to Obscure Things That Can Happen for more information about things that can happen when an FT is frozen (and FT's get frozen during billing).

Using Billable Charges for Pass Through / Convergent Billing

The term "pass through" billing is used to describe the practice of receiving charges calculated by third parties and presenting them on the taxpayer's bill along with your own charges. "Pass through" billing is implemented in the system using Billable Charges.

The following points provide information to help you decide the most appropriate way to implement "pass through" billing given your specific requirements:

- Taxpayers with pass through charges will need a separate obligation to hold the pass through charges. We refer to this type of obligation as a "billable charge" obligation.

Note:

An Obligation's obligation type controls whether an obligation can have billable charges linked to it. Specifically, the obligation type must have a "special role" of Billable Charge.

- A billable charge obligation holds the billable charges until the taxpayer is next billed. At that time, a separate bill segment will be created for each unbilled billable charge linked to the billable charge obligation.

- While it is not required, we recommend creating a separate billable charge obligation for each type of pass through charge.

- You can interface billable charges using the Billable Charge Interface. The interfaced charges can consist of any of the following:

- Pre-calculated bill lines that will be presented "as is" to the taxpayer.

- Rate quantities that are used by the system to calculate the charges on behalf of the third party.

- The bill lines on a billable charge can fit into any of the following categories:

- Memo-only (i.e., don't affect the general ledger). A bill line that is memo-only contains information that is purely informational.

- Show on the taxpayer bill. It is possible to create bill lines that affect the general ledger, but are not shown on the taxpayer's bill. This is an unusual practice, but it happens.

- Summary / detail. Each bill line has an indication of whether it is a summary or detail line. This only impacts bill presentation.

Note:

The above indicators can be defaulted onto a billable charge line by using Billable Charge Line Types when you interface the lines into the system.

- Characteristics (i.e., user-defined fields) can be associated with billable charge lines. You might populate this information if you are interfaced information that may be useful during bill presentation or for reporting purposes.

- If rate quantities are specified on a billable charge, they are saved on the bill segment created when the billable charge is billed.

- Cancel / rebill for billable charges is quite different than for normal bill segments. A billable charge bill segment can be cancelled, and this will reverse the financial effects of the billable charge. But without new information from the source, there is no way to rebill the taxpayer. Therefore, if the original charges were incorrect, the source system would send both a reversal of the charges and a newly revised set of information. These could be passed as two separate billable charges or they could be combined on a single billable charge.

- For most other functionality, the billable charge obligation supports the same functionality as normal obligations. This includes payment distribution, collections, current & payoff balances, etc.

Fastpath:

For more information about billing billable charges, refer to How To Create An Ad-hoc Bill. For more information about creating a billable charge, refer to Maintaining Billable Charges. For more information about interfacing a billable charge from an external system, refer to Uploading Billable Charges.

Printing Bills

The contents of this section describe the technical implementation of both an online and batch bill production.

Next in This Section

- Bill Routings Are Created For Each Recipient Of A Bill

- Bill Route Types Control The Information Merged Onto Bills

- Technical Implementation Of Online Bill Images

- Technical Implementation Of Printing Bills In Batch

- Reproducing The Bill Print Flat File

- How To Reprint A Specific Bill

- Who Gets A Copy Of A Bill?

- Final Bills and Bill Print

Bill Routings Are Created For Each Recipient Of A Bill

Refer to The Source Of Bill Routing Information for a description of how the system constructs the information used to route a bill to one or more recipients.

Bill Route Types Control The Information Merged Onto Bills

Every bill routing record references a Bill Route Type. The bill route type controls the following:

- It contains an algorithm that is responsible for extracting the information merged onto your bills. Algorithms of this type are called under the following scenarios:

- The background process that interacts with your bill print software calls these algorithms.

- If your bill print software has the ability to construct a real-time image of a bill, you can plug-in an Online Bill Display algorithm on the Installation Record. This type of algorithm will call the extract algorithm for an appropriate bill route type to extract the information that is merged onto the bill. Refer to Technical Implementation Of Online Bill Image for the details.

- It contains the ID of the background process responsible for interacting with your bill print software in batch.

Technical Implementation Of Online Bill Images

Users can view an image of any bill that is sent to a taxpayer on Bill - Main if you set up the following:

- Plug-in an Online Bill Display construction algorithm on the Installation Record.

- Plug-in the appropriate bill extract algorithm on each Bill Route Type.

The system provides algorithms that interact with bill print software that renders an image of the bill in a PDF. The following points describe what takes place when clicking Display Bill when these sample algorithms are used.

- The sample Online Bill Display algorithm ONLN-BL-DSP is executed.

- This algorithm calls the bill extract algorithm for an appropriate bill route type (as determined by the algorithm). The sample bill extract algorithm BLEX-EX constructs the information that appears on the bill and returns it to the Online Bill Display algorithm. This algorithm, in turn, passes it to your bill print software.

- Your bill print software renders an image of the bill in a PDF and returns it to the Online Bill Display algorithm.

- And finally, the system displays the PDF in a separate browser session. Note that the client must have Adobe Acrobat Reader installed to view PDF files.

Technical Implementation Of Printing Bills In Batch

The batch process that extracts bill information reads all bill routing records in a given run number that are marked with its batch control ID

The base package example of this process (known by the batch control ID of POSTROUT) simply calls the extract algorithm on the routing record's route type to format the information placed onto the flat file. Refer to Bill Route Types Control The Information On Bills for more information.

Note: If your software doesn't support online bill images. The algorithm that formats bill extract records that's plugged in on bill route type serves two purposes: 1) it interacts with the online bill display algorithm plugged into to the installation record to support online images of a bill, and 2) it interacts with the background process to support printing your bills in batch. If your bill print software does not support the rendering of bill images real time, there is no need to create an extract algorithm. Rather, you should simply develop your own download process that works with your bill print software to print bills in batch (and then specify this batch process on your bill route type).

Reproducing The Bill Print Flat File

You can reproduce the flat file at any time. Simply request the download process and specify the run number associated with the historic run.

How To Reprint A Specific Bill

Refer to How To Reprint A Bill (For The Original Recipients or For Someone New) for instructions describing how to reprint a specific bill.

Who Gets A Copy Of A Bill?

A copy of a bill is sent to every individual / business specified in the bill's routing details.

There are two ways in which a bill routing detail can be created:

- When a bill is completed, the system creates a routing detail for every person linked to the account that wants to receive a copy of the bill (as specified on Account - Person Information). Refer to The Source Of Bill Routing Information for more information.

- After a bill is completed, you may insert a bill routing record. Refer to How To Reprint A Bill (For The Original Recipients or For Someone New) for more information.

Final Bills and Bill Print

If a bill is produced for an account where all of the account's obligations are stopped, closed or cancelled; the bill is flagged as being the final bill on the flat file produced by the postal routing process.

If a bill is considered to be a final bill and the amount owing for the entire account is less than the final bill threshold amount on the installation record, the bill will be skipped (i.e., it won't appear on the flat file produced by the postal routing process). Note, this logic also suppresses bills from being produced when a payment is received AFTER the final bill and the account's balance falls beneath the installation record's final bill threshold amount. Refer to Installation Options - Billing for more information.

Idiosyncratic Manual Bill Cancellation

If a bill's account is associated with an account type that has a Cancel Bill algorithm, the system invokes this algorithm before the bill is displayed to determine if the bill is "cancellable". If the algorithm indicates the bill is cancellable, a button appears on Bill - Main. When clicked, the Cancel Bill algorithm is invoked again to cancel the bill. This functionality is meant to support unique cancellation needs required by some implementations; the sample base-package algorithm is empty.

Maintaining Bills

A bill is used to communicate changes in a taxpayer's financial obligations to the taxpayer. The topics in this section describe how to maintain bills.

It's important to be aware that there are very few fields that are directly modifiable by a user. To modify most fields on a bill, you have to change source information (e.g., obligation, rate) and then regenerate the bill. For example, if you want to change a bill's amount, you must cancel or add bill segments; you cannot change the bill's amount by modifying the bill amount field. Refer to How To for step-by-step instructions that explain how to perform common bill maintenance functions.

Next in This Section

- Bill Lifecycle

- Bill - Main Information

- Bill - Bill Segments

- Bill - Bill Routings

- Bill - Bill Messages

- Bill - Characteristics

- How To

Bill Lifecycle

The following diagram shows the possible lifecycle of a bill.

CAUTION:

This explanation only makes sense in the context of the page used to maintain bills. Refer to Bill - Main Information for the details.

A bill is initially saved in the Pending state. You may create one or more bill segments for the account's obligations at this point. Refer to How To for information about generating bill segments for the bill.

A bill becomes Complete when it is ready to be sent to the taxpayer. Completing a bill triggers many things to occur. Refer to the section below for information about what happens when a bill is completed.

When you complete a bill, several things may happen:

- Pre-completion algorithms associated with the account's account type are executed.

- The bill's due date is calculated. This is equal to the bill date plus the number of days defined on the account's account type. If the resultant date is not a workday, the due date is set to the next workday. Note, this due date can be overridden if an override algorithm exists on the account's account type.

- The bill's routing information is set up using Account - Person Information.

- If the Freeze At Bill Completion installation option has been turned on, freezable bill segments and adjustments linked to the account are frozen. Note, only freezable adjustments whose adjustment type indicates Freeze At Bill Completion will be frozen at this time.

- Post completion algorithms associated with the account's obligations' obligation types are executed. The system executes these algorithms first in the order of the billing processing sequence on each obligation's obligation type then in the order of the algorithm's sequence.

- Bill completion algorithms associated with the account's account type are executed.

- Bill messages are amalgamated from various sources and linked to the bill. Refer to The Source Of Bill Messages for more information.

- Other financial transactions that have been frozen since the last bill and are marked to show on bill are linked to the new bill

- For open-item account types adjustments and corrections are linked

- For all other situations, payments, adjustments and corrections are linked

- All financial transactions that don't already have a user-defined aging date will be dated with the current date. In other words, they start aging from the date the bill is completed.

- If the account's account type indicates the account is an open-item taxpayer, a match event is created. The bill's FTs and the automatic payment's FTs are linked to it. Refer to Payments and Match Events for more information about match events.

- If the account pays, the bill is stamped with the date when the automatic payment is to be created. Refer to the batch control descriptions for APAYCRET, the background process that creates the automatic payment and APAYDSFR, the background process that distributes and freezes the automatic payment.

- If the account's account type indicates the account is an open-item taxpayer, the system will create a match event if the new charges are offset by other financial transactions. Refer to Payments and Match Events for more information about match events.

- The bill's status becomes Complete.

- Post bill completion algorithms associated with the account's account type are executed.

If the system cannot complete the bill (for whatever reason), the bill remains Pending and an error message is shown on the main bill page. After correcting the cause of the problem, attempt to complete the bill again.

A complete bill may be changed back to pending using the Reopen button on Bill - Main Information. You would reopen a bill when

- Add more bill segments to a completed bill. Refer to the How To section for information about linking bill segments for a bill.

- Fine-tune the payments, adjustments, and corrections that were linked to a completed bill. Refer to the How To section for detailed instructions.

When you're happy with the bill, you can complete it again.

Note: Cannot reopen historical bills. You may only reopen an account's most recent bill because recompleting the bill causes the ending-balance to change, and we don't want this to happen to historical bills.

Note: Automatic payments. If an automatic payment was created when the bill was completed and it has already been interfaced to the financial institution, you cannot reopen the bill. If the automatic payment exists, but it has not yet been interfaced, the system will automatically cancel the payment when you reopen the bill.

You may delete a Pending bill from the database. You may not delete a pending bill if: a) there are frozen bill segments linked to the bill, or b) if financial transactions were linked to the bill (and this can only happen if the bill had been previously completed).

In addition to removing the bill, the system will also remove unfrozen bill segments linked to the bill.

Bill - Main Information

Open Menu > Billing (Classic) > Bill to maintain core bill information.

The follow discussion simply describes the fields on this page. Refer to How To for a description of how to perform common bill maintenance functions.

Description of Page

Bill Info contains a concatenation of important information about the bill (e.g., the bill date, its status, due date, ending balance, etc.).

Bill ID is the system-assigned unique identifier of the bill.

Account ID identifies the taxpayer who is responsible for the bill. The name of the main taxpayer on the account appears adjacent.

Bill Status is the bill's status. Refer to Bill Lifecycle for the potential values and how to handle a bill when it exists in a given state. Adjacent to the bill status is the Display Bill button, which will display an online image of the bill when clicked. Refer to How To Display A Bill On-line for more information.

Note:

You can only use the Display Bill button if your system has been configured to display an on-line image; otherwise, a message indicating that the service is not available will appear. This option can only be configured by your technical staff.

Due Date is the date on which the bill is due. A bill's due date is calculated as follows:

- Add the due days specified on the account's account type to the bill date.

- The resulting date is the due date unless it's not a workday. In this case, the due date is set to the next workday (workdays are defined in the installation options tables).

- If the account's account type has an override due date calculation algorithm, the due date may be overridden. Refer to Setting Up Account Types for more information.

Bill Date is the business date that was used when the bill was completed.

Create Date/Time is the date and time on which the bill was originally created.

Completion Date/Time is the date and time on which the bill was completed.

If the taxpayer pays automatically and the automatic payment has not yet been created, a brief message appears highlighting the date and amount of the future automatic payment. In addition, a button appears called Stop Auto Pay, that, when clicked, causes the associated automatic payment to stop. You might click this button if the taxpayer indicates that they will send in a payment. After you click the Stop Auto Pay button, a message appears highlighting the stoppage. Refer to How And When Are Automatic Payments Created for more information about how to setup the system to defer the creation of automatic payments until the future automatic payment extract date.

In the Message area, a brief error message appears if there's a problem with the bill. The message area is suppressed if there are no problems with the bill.

Click the magnifying button to view the long explanation. The long explanation will provide information about the cause of the error (and how to fix it).

Bill Summary summarizes the financial impact of the bill. The information that appears differs depending on whether the account is a balance-forward or open-item account. If the account is a balance-forward taxpayer, the following information appears:

- Previous Period's Balance is the balance from the account's last bill.

- Total Payments is the total amount of frozen or canceled payment segment financial transactions linked to this bill. Frozen payment segments appear as negative numbers (decreasing the amount owed by the taxpayer), while canceled payment segments appear as positive numbers (increasing the amount owed). You can drill down on this balance to view the financial transactions that contribute to this total. Refer to How To Remove Unwanted Payments From A Completed Bill for a description of how to perform common maintenance functions.

- Total Adjustments is the total amount of frozen or canceled adjustment financial transactions linked to this bill. You can drill down on the balance to view the financial transactions that contribute to this total. Refer to How To Remove Unwanted Adjustments From A Completed Bill for a description of how to perform common maintenance functions.

- Total Bill Corrections is the total amount of canceled and / or rebilled bill segment financial transactions linked to this bill. You can drill down on the balance to view the financial transactions that contribute to this total.

- Total Current Billing Charges is the total amount of frozen bill segment financial transactions linked to this bill. You can drill down on the balance to view the financial transactions that contribute to this total.

- Ending Balance For This Period is the sum of the five amounts above. It is the amount owed by the taxpayer as of the end of the bill period.

If the account is an open-item taxpayer, the following information appears under Bill Summary:

- New Charges is the total amount of frozen bill segment financial transactions linked to this bill. You can drill down on this value to view the financial transactions that contribute to this total.

- Adjustments is the total amount of frozen or canceled adjustment financial transactions linked to this bill. You can drill down on this value to view the financial transactions that contribute to this total. Refer to How To Remove Unwanted Adjustments From A Completed Bill for a description of how to perform common maintenance functions.

- Corrections is the total amount of canceled and / or rebilled bill segment financial transactions linked to this bill. You can drill down on this value to view the financial transactions that contribute to this total.

- Total is the sum of the above amounts. You can drill down on this value to view the financial transactions that contribute to this total.

If the account is an open-item taxpayer, the following information appears under Match Summary (note, this section is not displayed for balance-forward accounts):

- X Balanced Item(s) contains the count and total amount of financial transactions linked to this bill that are linked to balanced match events.

- X Unbalanced Item(s) contains the count and total amount of financial transactions linked to this bill that are linked to unbalanced match events.

- X Disputed Item(s) contains the count and total amount of financial transactions linked to this bill that are linked to disputed match events.

- X Unmatched Item(s) contains the count and total amount of financial transactions linked to this bill that are not linked to any match event.

Total Changes After Completion only appears if bill segments that appeared on the original bill have been subsequently canceled or rebilled. The amount displayed is the net effect of all cancels and rebills. Note, you can use the Remarks column in the bill segments grid (to the right) to see which bill segments have been cancelled / rebilled.

If 25 or fewer bill segments are linked to this bill, the grid in the lower right portion of the page contains one row for every bill segment linked to the bill.

The following points describe each column:

- The Bill Segment column contains a concatenation of each bill segment's division, obligation type, status and bill period. The division and obligation type come from the bill segment's obligation.

- The Current Amount column contains the bill segment's effect on the obligation's current balance.

- The Status column shows the bill segment's status. Refer to Bill Segment Lifecycle for the possible values.

- The Remarks highlight special situations. The following remarks may appear:

- Rebill after completion appears if the bill segment is a rebill that was created after the bill was sent to the taxpayer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the taxpayer.

- Rebill prior completion appears if the bill segment is a rebill that was created before the bill was sent to the taxpayer.

- Canceled after completion appears if the bill segment was canceled after the bill was sent to the taxpayer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the taxpayer.

- Canceled prior completion appears if the bill segment was canceled before the bill was sent to the taxpayer.

- If the bill segment's status is Error, this column also contains the error message.

If more than 25 bill segments are linked to this bill, the grid in the lower right portion of the page contains a summary of the various bill segments linked to the bill:

The following points describe each column:

- The Status column shows the bill segment's status. Refer to Bill Segment Lifecycle for the possible values. Click on the hyperlink to transfer to the Bill Segments tab where the associated bill segments can be viewed.

- The Total Bill Segments column contains the number of bill segments linked to the bill with this Status.

- The Total Amount column contains the sum of the current amount of these bill segments.

At the bottom of the scroll is shown the Total Generated Charge. This represents the total amount of the bill segments. This amount may differ from the Total Current Billing Charges when:

- The bill is not Complete. A bill segment's financial effect is not shown on the bill until the bill is completed.

- A bill segment has been canceled / rebilled since the bill was completed.

The topics that follow describe each of the actions that appear in the Bill Segment Action and Bill Action areas. Refer to How To for a description of typical business processes that use these buttons.

Next in This Section

- Generate

- Freeze

- Cancel Frozen

- Freeze / Complete

- Complete

- Delete

- Reopen

- Cancel Bill

Generate

The Generate button causes a bill segment to be created for each billable obligation linked to the account. The system generates bill segments in the order of the billing processing sequence on each obligation's obligation type.

This button is enabled when you are in add mode (i.e., you are not displaying an existing bill) and you have selected an Account ID.

When clicked, the Generate window opens.

You must specify the following parameters in the Generate window to generate the bill segments:

- Cut-off Date is the last possible day of the bill segment's bill period. The current date defaults when the window opens. Refer to Ways To Control The End Date Of A Bill Segment for more information.

- Accounting Date is used to define the financial period to which the new bill segment's financial transaction will be booked. The current date defaults when the window opens.

After specifying the parameters, click Calculate to create a new bill and new bill segments for the account. You see a summary of the bill segments in the lower right portion of the page.

Freeze

Clicking Freeze causes all freezable bill segments to become frozen. Refer to Bill Segment Lifecycle for more information about freezing.

This button is enabled if:

- the Freeze At Will Bill Segment Freeze Option on the installation option has been selected AND

- freezable bill segments exist AND

- there are no error, incomplete or pending cancel bill segments.

Note:

Freezing a day or more after generation. If, during freezing, bill segments in closed accounting periods are detected, a pop-up appears in which you can specify a new accounting date; this date is updated onto the offending bill segments. This only happens if the accounting period closes before you freeze the bill segments (the accounting date is stamped on a bill segment when it's generated).

If, after freezing, you're ready to send the bill to the taxpayer click Complete to finalize the bill.

Note:

If problems are detected after freezing. A bill segment may not be changed after it is frozen. All subsequent changes must occur by canceling the frozen bill segment and creating a new bill segment. Refer to How To Cancel A Bill Segment and How To Cancel / Rebill A Bill Segment for more information.

Cancel Frozen

Clicking Cancel Frozen causes all frozen bill segments to become canceled. Refer to Bill Segment Lifecycle for more information about cancellation. This button is disabled if the bill is written off.

Note:

Pending cancels are not affected. Clicking Cancel Frozen does not affect bill segments that are pending cancel. To make a pending cancel bill segment canceled, transfer to Bill Segment - Main and click Cancel.

If you need to cancel a specific bill segment, either transfer to the next tab and cancel the bill segment in question or follow the instructions under How To Cancel A Bill Segment.

This button is enabled if frozen bill segments are linked to the bill.

You must specify the following parameters in order to cancel the frozen bill segments:

- Cancel Reason defines why you are performing the cancellation.

- Accounting Date defines the financial period to which the canceled bill segments' financial transactions are booked. The current date defaults when the window opens.

After specifying the parameters, click Calculate to cancel the frozen bill segments.

Note:

There is no Undo. Unlike cancellations performed on Bill Segment - Main, there is no Undo action. This transaction moves the pending cancel bill segments to the cancel state immediately; whereas the bill segment transaction lets you examine the cancellation before you commit it. If you cancelled bill segments by mistake, you must generate and freeze new bill segments.

If the bill is pending, the cancellation causes the bill segments to be suppressed on the version of the bill sent to the taxpayer (but they remain in the database for audit and financial reporting purposes).

If the bill is complete and you do not Reopen the bill, the financial impact of the canceled bill segments appears on the next bill created for the account (under Bill Corrections).

If the bill is complete you may be able to Reopen the bill and then Complete it. By doing this, you can suppress a frozen bill segment on a previously completed bill. This means that if you catch a problem after completion you don't necessarily have to show the problem to the taxpayer. Rather, cancel the problem, reopen and then recomplete the bill (when you recomplete the bill the system marks the bill segment to be suppressed on the version sent to the taxpayer because its cancellation appears on the same bill as the original charges).

Freeze / Complete

The Freeze / Complete button performs a variety of functions:

- all freezable bill segments (including rebills) become frozen

- all pending cancel bill segments become canceled

- all freezable adjustments whose adjustment type indicates Freeze At Bill Completion become frozen

- the bill is finalized and marked for transmission to the taxpayer

Refer to Bill Lifecycle for information about what happens during bill completion. Refer to Bill Segment Lifecycle for more information about freezing.

This button is enabled if:

- the Freeze At Bill Completion Bill Segment Freeze Option on the installation option has been selected AND

- the bill is pending AND

- there are no bill segments or there are bill segments and all are freezable, pending cancel, frozen or canceled AND

- there are no error or incomplete bill segments.

If the User May Override Bill Date option has been enabled on the Installation Record, you may override the Bill Date prior to completion. Otherwise, the Bill Date is the current date and cannot be changed. The current date defaults when the window opens.

Note:

Freezing a day or more after generation. If, during freezing, bill segments in closed accounting periods are detected, a pop-up appears in which you can specify a new accounting date; this date is updated onto the offending bill segments. This will only happen if the accounting period closes before you freeze the bill segments (the accounting date is stamped on a bill segment when it's initially generated).

After specifying the parameter, click Calculate to freeze and complete the bill.

Complete

The Complete button causes a bill to be finalized and marked for transmission to the taxpayer. Refer to Bill Lifecycle for information about what happens during bill completion.

This button is enabled if:

- the Freeze At Will Bill Segment Freeze Option on the installation option has been selected AND

- the bill is pending AND

- there are no bill segments or there are bill segments and all are frozen or canceled.

If the User May Override Bill Date option has been enabled on the Installation Record, you may override the Bill Date prior to completion. Otherwise, the Bill Date is the current date and cannot be changed. The current date defaults when the window opens.

After specifying the above parameters, click Calculate to complete the bill.

Delete

The Delete button deletes a bill and its bill segments.

This button is enabled if:

- the bill is pending AND

- all bill segments are incomplete, freezable or in error.

Reopen

The Reopen button causes a bill to be reopened. Refer to Bill Lifecycle for information about why you would reopen a bill.

This button is enabled if:

- the bill is complete AND

- the bill is not written off AND

- this is the most recent bill produced for the account AND

- reopening hasn't been prohibited for the bill. Refer to Bill Lifecycle for information about conditions that can prevent a bill from reopening.

After reopening a bill, it returns to the pending state and you can make changes to the account's financial transactions (e.g., add payments, adjustments, and bill segments). After which, you click Complete or Freeze / Complete to finalize the bill. Only one of these buttons is shown - the specific one depends on how your organization has set the Bill Segment Freeze Option on the installation record.

Cancel Bill

Refer to Idiosyncratic Manual Bill Cancellation for a description of when the Cancel Bill button appears and what happens if the button is clicked.

Bill - Bill Segments

You can use this page to view all or selected bill segments linked to a bill. In addition, you can also perform certain maintenance functions on this page (see the details below).

Open Menu > Billing (Classic) > Bill and navigate to the Bill Segments tab to view this information.

Note:

If the bill has more than 25 bill segments and you don't use the hyperlinks in the bill segment grid on the Main tab to drill over to this information, the search criteria are intentionally left blank in order to avoid retrieving all bill segments (with the resultant slow response times). You must therefore use the Obligation Filter and the Status Filter to define the type of bill segments that should be retrieved. See the Description of page below for more information about this page's search criteria.

The Description of page that appears below simply describes the fields on this page. Refer to How To for a description of how to perform common maintenance functions.

Description of page

Bill Info contains a concatenation of important information about the bill (e.g., the bill date, its status, due date, ending balance, etc.).

Bill ID is the system-assigned unique identifier of the bill.

Note:

If the bill has more than 25 bill segments and you don't use the hyperlinks in the bill segment grid on the Main tab to drill over to this page, the Filters are intentionally left blank in order to avoid retrieving all bill segments (with the resultant slow response times). You must therefore use the Obligation Filter and the Status Filter to define the type of bill segments that should be retrieved.

The area beneath Bill Info provides you with options that control which bill segments appear in the grid. The following points describe the various options:

- Use the Obligation Filter to define the types of obligations whose bill segments appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict bill segments based on obligation attributes.

- Obligation Type. Use this option to restrict bill segments to those whose obligations are linked to a given division and obligation type.

- Use Status Filter to restrict the bill segments based on their status. The following options are available:

- All. This option shows all bill segments regardless of status.

- Refer to Bill Segment Lifecycle for the various status values.

Don't forget to click the search button after changing the filters.

The Select All / Clear All buttons are used to select bill segments if you plan on issuing any of the mass update actions at the bottom of the page. These buttons are enabled if either of the following conditions is true:

- All bill segments that appear in the grid are in the Error, Freezable and/or Incomplete states.

- All bill segments that appear in the grid are in the Frozen state

Refer to the description of the "mass update" actions below for more information.

Note:

100 bill segments at a time. Clicking Select All selects the first 100 bill segments in the grid. If more than 100 bill segments exist, you must select them in batches.

The grid that follows contains the bill segments that match your search criteria. The following information appears in the grid:

- Select box. See the mass update description immediately above for conditions under which this checkbox can be used to select bill segments for mass update actions.

- The Bill Segment column contains a concatenation of the bill segment's division, obligation type, status and bill period. The division and obligation type come from the bill segment's obligation. Click the hyperlink to transfer to Bill Segment - Main Information. On this page you can perform maintenance functions (e.g., cancel/rebill, delete, cancel, etc., depending on the segment's status) on the bill segment in question.

- The Current Amount column contains the bill segment's effect on the obligation's current balance.

- The Status shows the bill segment's status. Refer to Bill Segment Lifecycle for the possible values.

- The Remarks column highlights special circumstances associated with the bill segment.

- Rebill after completion appears if the bill segment is a rebill that was created after the bill was sent to the taxpayer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the taxpayer.

- Rebill prior completion appears if the bill segment is a rebill that was created before the bill was sent to the taxpayer.

- Canceled after completion appears if the bill segment was canceled after the bill was sent to the taxpayer. The financial impact of this bill segment appears as a "bill correction" on the next bill produced for the taxpayer.

- Canceled prior completion appears if the bill segment was canceled before the bill was sent to the taxpayer.

- If the bill segment's status is Error, this column also contains the error message.

- Rate Quantity and UOM columns are not used.

- The Bill Segment ID is the system-assigned unique identifier of the bill segment.

This transaction has sophisticated logic that can be used to perform "mass updates" to the bill segments that appear in the grid (using the buttons at the bottom of the page). The following points describe these mass update actions:

Next in This Section

- Generate (Bill - Bill Segments)

- Freeze (Bill - Bill Segments)

- Delete (Bill - Bill Segments)

- Cancel/Rebill/Freeze (Bill - Bill Segments)

- Cancel (Bill - Bill Segments)

Generate (Bill - Bill Segments)

The Generate button is used to delete and recreate one or more bill segments. This button is enabled if you select at least one row from the bill segments grid that's in the Error, Freezable and/or Incomplete state.

Note that you can only select a bill segment for regeneration if ALL bill segments in the grid are in the Error, Freezable and/or Incomplete states. Note, you can use the Status Filter to restrict the type of bill segments in the grid.

You must specify the following parameters in order to regenerate a new bill:

- Accounting Date defines the financial period to which the new bill segments' financial transactions will be booked. The current date defaults when the window opens.

- Choose Use Cut off Date as Billing Option.

After specifying the parameters, click Calculate to regenerate the selected bill segments. A summary of what the system does is presented next.

Freeze (Bill - Bill Segments)

The Freeze button is used to freeze one or more bill segments. This button is enabled if you select at least one row from the bill segments grid that's in the Freezable state AND the installation option indicates users are allowed to "freeze at will".

Note that you can only select a bill segment for freezing if ALL bill segments in the grid are in the Freezable state. Note, you can use the Status Filter to restrict the type of bill segments in the grid.

Accounting Date is used to define the financial period to which the frozen bill segments' financial transactions are booked. The current date defaults when the window opens.

After specifying the above parameters, click Freeze to freeze the selected bill segments. A summary of what the system does is presented next.

Delete (Bill - Bill Segments)

The Delete button is used to delete one or more bill segments. This button is enabled if you select at least one row from the bill segments grid that's in the Error, Freezable and/or Incomplete state.

Note that you can only select a bill segment for deletion if ALL bill segments in the grid are in the Error, Freezable and/or Incomplete states. Note, you can use the Status Filter to restrict the type of bill segments in the grid.

If the system is successful in deleting the selected bill segment(s), a confirmation window summarizes what the system just did (i.e., it shows the number of bill segments that were deleted).

Cancel/Rebill/Freeze (Bill - Bill Segments)

If problems are detected with a frozen bill segment, it should be canceled and a new bill segment should be created. We refer to this process as cancel / rebill. Refer to Cancel / Rebill Incorrect Bill Segments for more information.

Before you cancel / rebill, you'll probably need to fix the cause of the problem.

Note:

Multi-Cancel/Rebill Saves Time. If the cause of the problem impacts many bill segments related to an obligation, you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

The Cancel/Rebill/Freeze button is used to cancel, rebill and freeze one or more bill segments. This button is enabled if you select at least one row from the bill segments grid that's in the Frozen state AND the bill is not written off.

Note that you can only select a bill segment for cancel/rebill/freeze if ALL bill segments in the grid are in the Frozen state. Note, you can use the Status Filter to restrict the type of bill segments in the grid.

- Cancel Reason defines why the bill segment(s) are being canceled.

- Accounting Date defines the financial period to which the canceled and new bill segments' financial transactions are booked. The current date defaults when the window opens.

- Choose Use Cut off Date as Billing Option.

- If you prefer to have the system use the details used on the original bill segments, check Use Old RQ.

If the cause of the rebill is an incorrect rate and the new rate requires rate quantities that were not calculated when the bill was originally calculated, do not turn on Use Old RQ. Why? Because you want the system to derive new rate quantities during the rebill process.

After specifying the parameters, click Calculate to cancel, rebill and freeze the selected bill segments.

Note:

Errors. Bill segment errors may occur when you cancel / rebill the bill segments. For example, if you change the obligation's rate to a rate that is no longer effective on the bill segment period, a bill segment error is generated. If this occurs, you must go to Bill Segment - Main for the pending cancel bill segment and use the Undo action to remove the offending bill segment (and restore the original segment to the Frozen state). Alternatively, you can drill down on the Error bill segment and use the Regenerate action after correcting the cause of the problem.

Note:

There is no Undo. Unlike cancel / rebills performed on Bill Segment - Main, there is no Undo action. This is because this transaction freezes the newly created bill segments after it cancel/rebills; whereas the bill segment transaction lets you examine the new bill segment before you freeze it. If you made a mistake, simply correct the cause of the mistake and then cancel / rebill again. The erroneous financial transactions are automatically suppressed on the next bill produced for the taxpayer.

A confirmation window summarizes what the system just did (i.e., it shows the number of bill segments that were deleted / generated).

Cancel (Bill - Bill Segments)

The Cancel button is used to cancel one or more bill segments. This button is enabled if you select at least one row from the bill segments grid that's in the Frozen state AND the bill is not written off.

Note that you can only select a bill segment for cancellation if ALL bill segments in the grid are in the Frozen state. Note, you can use the Status Filter to restrict the type of bill segments in the grid.

- Cancel Reason defines why the bill segment(s) are being canceled.

- Accounting Date is used to define the financial period to which the canceled bill segments' financial transactions are booked. The current date defaults when the window opens.

After specifying the above parameters, click Calculate to cancel the selected bill segments.

Note:

There is no Undo. Unlike cancellations performed on Bill Segment - Main, there is no Undo action. This transaction moves the pending cancel bill segments to the cancel state immediately; whereas the bill segment transaction lets you examine the cancellation before you commit it. If you cancelled bill segments by mistake, you must generate and freeze new bill segments.

Bill - Bill Routings

This page is used to view the recipients of a bill. Refer to Printing Bills for a discussion of how this information is used to produce bill images.

This page is also used to request a new copy of a bill. Refer to How To Reprint A Bill (For The Original Recipients or For Someone New) for a description of how to do this.

Note:

No routing information until completion. A bill has no routing details until it is completed. At completion time, the system creates a routing detail for every person linked to the account that receives a copy of its bills. Refer to The Source Of Bill Routing Information for more information about how this information is constructed.

Use Menu > Billing (Classic) > Bill and navigate to the Bill Routings tab to open this page.

Description of Page

Bill Info contains a concatenation of important information about the bill (e.g., the bill date, its status, due date, ending balance).

Bill ID is the system-assigned unique identifier of the bill.

The Bill Routing Information scroll contains an entry for each recipient of the bill. This information is disabled after the bill has been routed to the recipient. The remainder of this discussion describes the fields that can be defined for each recipient of the bill.

Person ID identifies the person who was originally associated with the routing record. You may change the Person ID to any person in the system as this information is only used to default the recipient's name and address information, below.

The Bill Routing Parameters area contains information explaining how and when the bill is routed to the recipient. This information is gray when the rill routing information has been extracted or if a bill is reopened:

- Bill Route Type is the method used to transmit the bill to the taxpayer. If the Person ID is linked to the account, the bill route type defaults from the person's Account - Person Information.

- Sequence is the system-assigned identifier assigned to this bill routing.

- Batch Control is the identifier of the batch of bills in which the recipient's copy was downloaded. The batch process is defined on the Bill Route Type.

- Extract Date/Time is the date and time the bill was downloaded. This information only appears after the download has commenced.

- Format indicates if the taxpayer should receive a Detailed or a Summary bill. If the Person ID is linked to the account, this information defaults from Account - Person Information.

- Reprint is checked if a user created this routing. This switch is populated by the system and is always protected.

- Turn on Do Not Extract if the bill should not be routed to the individual for whatever reason.

- Copies indicates the number of copies of the bill the person receives. If the Person ID is linked to the account, this information defaults from Account - Person Information.

- PO ID is the purchase order Id the taxpayer wants printed on their copy of the bill. If the Person ID is linked to the account, this information defaults from Account - Person Information.

- Intercept is the user ID of the individual who wants to review the bill before it is sent to the taxpayer. This field is only populated when the account has a Bill Print Intercept specified. Intercept information is defined on Account - Main Information.

The Mailing Address Information area contains the recipient's name and address.

- If the recipient has an override mailing name, Name1, Name2 and Name3 contain the person's override mailing name. Otherwise, Name1 contains the recipient's primary name (this name might also include a prefix or suffix if the related Account - Person relationship has these fields defined).

- The remaining fields are the recipient's address. Refer to The Source Of Bill Routing Information for information about how the system constructs the recipient's address. Note:

- If the recipient's address is a mailing address (as opposed to fax or email), the Country associated with the address controls the fields that appear in the address. Refer to Defining Countries for more information on the address constituents.

- If a user manually adds a routing record, the mailing address information defaults from the information on the current routing record.

- If a user specifies a Person ID that is linked to the bill's account, the Bill Route Type defined on the Account - Person record is defaulted.

- If a user specifies a Person ID that is not linked to the bill's account, the Bill Route Type on the installation record is defaulted. Note, if the bill route indicates the bill is routed via the postal service, the system will only be able to default the person's address if the person has an override mailing address on their correspondence information.

- If the user changes the Bill Route Type after the initial default, the system populates the address information as described under The Source Of Bill Routing Information.

Bill - Bill Messages

The Messages page is a grid containing one row for every message that appears on the bill. Open Menu > Billing (Classic) > Bill and navigate to the Bill Messages tab to view this information.

Note:

No messages until completion. A bill has no messages until it is completed (unless you insert them manually). At completion time, the system assembles messages from the various message sources. Refer to The Source Of Bill Messages for information about these sources.

Note:

The bill segment(s) may also have messages. Be aware that only account-oriented messages are linked to a bill. There may also be obligation-oriented messages linked to the bill's bill segments. Refer to Bill - Bill Messages for information about the page on which obligation-oriented messages are displayed. Refer to The Source Of Bill Messages for information about the various message sources and whether each is linked to a bill or a bill segment.

Note:

Bill messages may contain dynamic information. Refer to Substituting Field Values Into A Bill Message for more information.

The Description of Page section that appears below simply describes the fields on this page. Refer to How To Add Ad Hoc Messages To A Bill for a description of how to perform common maintenance functions.

Description of Page

Bill Info contains a concatenation of important information about the bill (e.g., the bill date, its status, due date, ending balance).

Bill ID is the system-assigned unique identifier of the bill.

The following columns are displayed in the grid:

- Bill Message is the code that identifies the bill message.

- Message On Bill is the message associated with the code.

- Priority is the bill messages priority (on the printed bill).

- Insert Code defines if the bill message causes an insert in the envelope.

Bill - Characteristics

The Characteristics page is a grid containing one row for each characteristic linked to the bill. Bill characteristics are purely informational.

Note:

You can only choose characteristic types defined as permissible on a bill record. Refer to Setting Up Characteristic Types and Their Values for more information.

Description of Page

The following fields display on the grid:

- Characteristic Type must be a type of characteristic defined as permissible on a bill record.

- Characteristic Value indicates the value of the characteristic if the characteristic type is pre-defined or foreign key reference.

How To

The topics in this section describe how to perform common bill maintenance functions.

Next in This Section

- How To Create A Bill For All Obligations Linked To An Account

- How To Create A Bill For A Specific Obligation

- How To Create a Bill with no Bill Segments

- How To Create An Ad-hoc Bill

- How To Correct A Bill Segment That's In Error

- How To Correct A Bill That's In Error

- How To Cancel A Bill Segment

- How To Cancel / Rebill A Bill Segment

- How To Remove Unwanted Adjustments (or Payments) From A Completed Bill

- How To Add An Adjustment (or Payment) To A Completed Bill

- How To Reprint A Bill (For The Original Recipients or For Someone New)

- How To Add Ad Hoc Messages To A Bill

- How To Remove A Completed Bill

- How To Display A Bill On-line

How To Create A Bill For All Obligations Linked To An Account

99.9% of all bills are created by the batch bill process and require no human intervention before they are finalized and sent to a taxpayer. The other 0.1% are created by users on-line / real time. This section explains how to create the 0.1%.

The following points describe how to use this page to create a new bill:

- Navigate to the Bill - Main Information page:

- If an account already exists in the dashboard context zone, select Go To Bill + option on the account context menu. This will transfer you to this page with the respective account populated.

- If you haven't selected the account, navigate to this page using Menu > Billing (Classic) > +Bill and then select the Account ID using the adjacent search button.

- Click the Generate button to create a new bill.

- You will see a summary of the bill segments in the lower right portion of the page. If there are errors, refer to How To Correct A Bill Segment That's In Error. If there are no errors, the Bill Segment Freeze Option on the installation option controls the next step:

- If this option is set to Freeze At Bill Completion, click the Freeze / Complete button.

- If this option is set to Freeze At Will, click the Freeze button and, if everything looks clean, click the Complete button.

How To Create A Bill For A Specific Obligation

Most bills contain a bill segment for every billable obligation linked to the account. If you want to produce a bill that contains bill segments for a subset of obligations (e.g., you want to create an ad-hoc bill for an account's billable charge obligation), follow these steps:

- Navigate to the Bill - Main Information page:

- If an account already exists in the dashboard context zone, select Go To Bill + option on the account context menu. This will transfer you to this page with the respective account populated.

- If you haven't selected the account, navigate to this page using Menu > Billing (Classic) > +Bill and then select the Account ID using the adjacent search button.

- Click the save button to create a bill without bill segments for the account.

- Select Go To Bill Segment + option on the Bill's context menu to transfer to Bill Segment - Main.

- Select the Obligation ID of the obligation for which you want to create a bill segment.

- Click the Generate button to generate a bill segment.

- If an error exists, refer to How To Correct A Bill Segment That's In Error.

- If there are no errors, the Bill Segment Freeze Option on the installation option controls the next step:

- If this option is set to Freeze At Bill Completion, return to Bill - Main (using the bill context menu) and click the Freeze / Complete button.

- If this option is set to Freeze At Will, click the Freeze button and, if everything looks clean, return to Bill - Main and click the Complete button.

How To Create a Bill with no Bill Segments

You may wish to generate a bill that contains no bill segments. For example, perhaps your taxpayer is billed quarterly but pays monthly. During the months where no charges are calculated, you may choose to send a "bill" that does not show new charges, but includes the payments received. To produce a bill with no bill segments, follow these steps:

- Navigate to the Bill - Main Information page:

- If an account already exists in the dashboard context zone, select Go To Bill + option on the account context menu. This will transfer you to this page with the respective account populated.

- If you haven't selected the account, navigate to this page using Menu > Billing (Classic) > +Bill and then select the Account ID using the adjacent search button.

- Click the save button to create a bill without bill segments for the account.

- At this point either the Complete or Freeze / Complete button (based on the value of Bill Segment Freeze Option on installation options) becomes enabled. Click the applicable button for your installation to complete the bill. At this point, all the steps described for completing a bill in Bill Lifecycle are performed, including sweeping onto the bill any payments received since the last bill was generated.

How To Create An Ad-hoc Bill

The following points describe the steps necessary to create and bill an ad-hoc bill:

- If the taxpayer to be invoiced doesn't already have an appropriate billable charge obligation, create one.

- Use Maintaining Billable Charges to add a billable charge for the obligation. The billable charge contains the invoice lines and amounts.

- If you created a new billable charge obligation in step 1, you must activate it before billing can bill it. To do this, transfer to Obligation - Main Information and click the activate button.

Refer to How To Create A Bill For A Specific Obligation for instructions describing how to create a bill with a bill segment for the billable charge obligation.

How To Correct A Bill Segment That's In Error

A bill segment will exist in the Error state if a problem was encountered during the generation of a bill segment. To fix an error bill segment you must correct the cause of the error and then regenerate the bill segment. Refer to Bill Segment Errors for background information.

Note:

Error segments created during batch billing. If the error bill segment was created as part of the cyclical batch bill process, the system attempts to fix the offending segment(s) each night during the account's bill window by regenerating it. Therefore, if the cause of the error is fixed during the day, the system will automatically regenerate the bill segment when batch billing next runs; you don't have to manually correct each bill. And once a bill is error-free, it will be completed and sent to the taxpayer. Refer to Batch Billing for more information.

Correcting the cause of a bill segment error can be difficult or trivial; we hope that the error messages (along with their long descriptions) provide a good description of how to resolve the issue.

After you have corrected the cause of the error, you should regenerate the bill segment. There are two ways to do this:

- You can use the Generate action on Bill - Bill Segment to regenerate one or more bill segments. We recommend using this method if the cause of the error affected many bill segments because you can regenerate many bill segments at a time on this page. Also, be aware that this transaction shows the estimated value of error bill segments so you can gauge whether to invest a lot of time in correcting the problem. For example, if the bill segment's estimated value is $10,000, it's probably worth correcting the problem before sending the bill out. However, if the bill segment's value is small, you may decide to simply delete the error bill segment and send the bill without it (the system will attempt to create a bill for the deleted period the next time the account is billed).

- You can use the Generate action on Bill Segment - Main to regenerate an individual bill segment. We'd recommend using this method if the problem is bill segment-specific and you need to examine the information that is snapshot on the bill segment to resolve the error.

Note:

Drilling Into Bill Segment Errors. When you use the bill segments in error To Do list to work through errors, you will be transferred to Bill Segment - Main with the bill segment displayed.

After all errors have been resolved on a bill, return to Bill - Main. The Bill Segment Freeze Option on the installation option controls the next step:

- If this option is set to Freeze At Bill Completion, click the Freeze / Complete button.

- If this option is set to Freeze At Will, click the Freeze button and, if everything looks clean, click the Complete button.

How To Correct A Bill That's In Error

Besides errors on bill segments, there may also be errors detected when the system attempts to complete a bill. For example, if the system cannot find a mailing address, the bill will be in error (as opposed to one of its bill segments). Refer to Bill Errors for background information.

To correct such an error:

- Navigate to Bill - Main.

- Look at the bill's error message. Push the view button to view the long explanation that will provide suggestions as to the cause of the error (and how to fix it). Transfer to the appropriate page to fix the problem.

- After fixing the cause of the error, return to Bill - Main. The Bill Segment Freeze Option on the installation option controls the next step:

- If this option is set to Freeze At Bill Completion, click the Freeze / Complete button.

- If this option is set to Freeze At Will, click the Freeze button and, if everything looks clean, click the Complete button.

How To Cancel A Bill Segment

If a bill segment was frozen and it should never have been created in the first place, the bill segment must be canceled. There are several ways to do this:

- You can use the Cancel Frozen action on Bill - Main to cancel all frozen bill segments linked to the bill. We recommend using this method if you need to cancel everything on a bill.

- You can use the Cancel action on Bill - Bill Segments to cancel selected bill segments. We recommend using this method if you need to cancel multiple bill segments.

- You can use the Cancel action on Bill Segment - Main to cancel an individual bill segment. We'd recommend using this method if you need to examine the information on the bill segment before canceling it.

If the related bill is pending, the cancellation will cause the bill segment to be suppressed on the version of the bill sent to the taxpayer (but it remains in the database for audit and financial reporting purposes).

If the related bill is complete and you do not Reopen the bill, the financial impact of the canceled bill segment(s) will appear on the next bill created for the account (under Bill Corrections).

If the related bill is complete you may be able to Reopen the bill and then Complete it. By doing this, you can suppress a frozen bill segment on a previously completed bill. This means that if you catch a problem after completion you don't necessarily have to show the problem to the taxpayer. Rather, cancel the problem, reopen and then recomplete the bill (when you recomplete the bill the system will mark the bill segment to be suppressed on the version sent to the taxpayer because its cancellation appears on the same bill as the original charges).

How To Cancel / Rebill A Bill Segment

If a bill segment was frozen but it contains incorrect information, it should be canceled and a new bill segment should be created. We refer to this process as cancel / rebill. Refer to Cancel / Rebill Incorrect Bill Segments for more information.

Before you cancel / rebill, you must correct the cause of the problem.

After correcting the cause of the problem, you're ready to cancel and rebill the offending bill segment(s). There are several ways to do this:

- You can use the Cancel / Rebill / Freeze action on Bill - Bill Segments to cancel, rebill and freeze selected bill segments. We recommend using this method if you need to cancel / rebill multiple bill segments due to a pervasive problem.

- You can use the Rebill action on Bill Segment - Main to cancel and rebill an individual bill segment. We'd recommend using this method if you need to examine the information on the bill segment before and after canceling it. If you use this method, you must also use the Freeze action to freeze the newly created bill segment.

- If the cause of the problem impacts many bill segments related to an obligation, you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

If the related bill is pending, the cancellation will cause the erroneous bill segment to be suppressed on the version of the bill sent to the taxpayer (but it remains in the database for audit and financial reporting purposes).

If the related bill is complete and you do not Reopen the bill, the financial impact of the canceled bill segment(s) and their rebill bill segment(s) will appear on the next bill created for the account (under Bill Corrections).

If the related bill is complete you may be able to Reopen the bill and then Complete it. By doing this, you can suppress an erroneous frozen bill segment on a previously completed bill. This means that if you catch a problem after completion you don't necessarily have to show the problem to the taxpayer. Rather, cancel / rebill the problem, reopen and then recomplete the bill (when you recomplete the bill the system will mark the bill segment to be suppressed on the version sent to the taxpayer because its cancellation appears on the same bill as the original charges).

How To Remove Unwanted Adjustments (or Payments) From A Completed Bill

If the system (or a user) has created adjustments that have been swept onto a recently completed bill but you don't want them to appear on the bill perform the following steps:

- Cancel the adjustment ( Adjustments - Main Information).

- Navigate to the Bill - Main page.

- Click the Reopen button to reopen the previously completed bill.

- Click the Complete button to recomplete the bill. When the bill is recompleted, the system will see that an adjustment that was swept onto the bill when it was originally completed has been canceled and it will mark the adjustment for suppression on the printed bill.

You can remove unwanted payments using an analogous approach - Cancel the payment, Reopen the bill, Complete the bill.

Note:

Cannot reopen historical bills. You may only reopen an account's most recent bill because recompleting the bill causes the ending-balance to change, and we don't want this to happen to historical bills.

How To Add An Adjustment (or Payment) To A Completed Bill

If you want to add an adjustment to a completed bill perform the following steps:

- Add and freeze the adjustment ( Adjustments - Main Information).

- Navigate to the Bill - Main page.

- Click the Reopen button to reopen the previously completed bill.

- Click the Complete button to recomplete the bill. When the bill is recompleted, the system will sweep the recently created financial transactions onto itself.

You can add a payment to a bill using an analogous approach - Add the payment, Reopen the bill, Complete the bill.

Note:

Cannot reopen historical bills. You may only reopen an account's most recent bill because recompleting the bill causes the ending-balance to change, and we don't want this to happen to historical bills.

How To Reprint A Bill (For The Original Recipients or For Someone New)

A copy of a bill is sent to every individual / business specified in the bill's routing details. The system creates the routing details when a bill is completed. Refer to The Source Of Bill Routing Information for more information about how this information is compiled during bill completion.

If you want to reprint a bill OR if you want to send a bill to someone other than the original recipient(s):

- Navigate to the Bill - Main page.

- Transfer to the Bill - Bill Routings tab.

- Insert a new row (click the + button). Note well, you can only insert information on a bill that is Complete.

- Specify the name and address to which the bill should be sent. If you want to send the bill to someone other than the original recipient, simply specify the individual's name and address. If the recipient is a person in the system, you can select their person ID and let the system default this information for you.

- Save the bill.

Note:

If a bill is Complete but the print process hasn't yet executed, you don't have to insert a new routing row. Rather, you can simply change the name and address on the original routing details.

How To Add Ad Hoc Messages To A Bill

If you want to add a message to a completed bill:

- Navigate to the Bill - Main page.

- Transfer to the Bill - Bill Messages tab.

- Insert a new row (click the + button). Note, you can only insert a message on the most recent bill that is Complete.

- Specify the desired message code.

- Save the bill.

- Reprint the bill as per How To Reprint A Bill (For The Original Recipients or For Someone New).

Fastpath:

Refer to The Source Of Bill Messages for more information about the messages the system automatically links to a bill when the bill is completed.

How To Remove A Completed Bill

You can't physically remove a completed bill from the system. However, you can remove all financial transactions from the bill (and therefore end up with a zero value bill). You can also suppress the bill from being printed. To do this, perform the following steps:

- If the bill has bill segments, cancel each bill segment. Refer to How To Cancel A Bill Segment for instructions describing how to do this.

- If the bill has payment amounts or adjustment amounts that were entered incorrectly, navigate to the payment and/or adjustment pages and cancel the payments / adjustments.

- Navigate to the Bill - Main page.

- Click the Reopen button to reopen the previously completed bill.

- Transfer to the Bill - Bill Routings tab. Turn on the Do Not Print switch for every routing entry.

- Click the Complete button to recomplete the bill. When the bill is recompleted, the system will sweep the canceled segments onto it and the net effect should be zero current charges.

Note:

Cannot reopen historical bills. You may only reopen an account's most recent bill because recompleting the bill causes the ending balance to change, and we don't want this to happen to historical bills.

If the bill has payment amounts or adjustment amounts that are valid, but you don't want them to appear on this bill, navigate to the Bill, Financial Details page. Drill over to each respective financial transaction by clicking the drill down button. Clicking this button transfers you to Financial Transaction - Main. On this page, clear out the value of the Bill ID. Clearing out the Bill ID unlinks the financial transaction from the bill. When the system next completes a bill for the account, it will find the unbilled financial transaction and link it to the bill.

How To Display A Bill On-line

To display a bill on-line, you must first have installed software to render the bill in a format suitable for displaying. You must also configure the system to invoke this software; otherwise, you will get a message indicating that the service is not available. This option can only be configured by your technical staff.

To view a bill on-line, click the Display Bill button.

Financial Transactions On A Bill

Open Menu > Billing (Classic) > Financial Transactions on Bill to view the financial transactions on a bill.

Note:

You can also open this page using the go to buttons that prefix the financial transaction summaries on Bill - Main.

Description of page

Bill Id is the system-assigned unique identifier of the bill.

Account ID is the bill's account.

The area beneath Account ID provides you with options that control which financial transactions appear in the grid. The following points describe the various options:

- Use the Obligation Filter to define the types of obligations whose financial transactions appear in the grid. The following options are available:

- All. Use this option if you do not wish to restrict financial transactions based on obligation attributes.

- Obligation ID. Use this option to restrict financial transactions to those of a specific obligation.

- Obligation Type. Use this option to restrict financial transactions to those whose obligations are linked to a given division and obligation type.

- Use the FT Type Filter to restrict the type of financial transactions that appear in the grid. The following options are available:

- Adjustments. This option shows all financial transactions associated with adjustments.

- All. This option shows all financial transactions.

- Corrections. This option shows all financial transactions associated with corrections (i.e., cancel / rebills that have occurred after the bill was completed).

- Current Charges. This option shows all financial transactions associated with bill segments (that aren't Corrections).

- Payments. This option shows all financial transactions associated with payments.

CAUTION:

Don't forget to click the search button after changing the filters or after selecting a new Bill ID.

The grid that follows contains the financial transactions that match your search criteria. The following information is displayed:

- FT Type displays the type of financial transaction except for adjustments. For adjustments, the adjustment type's description is shown. Click on the hyperlink to transfer to Financial Transaction - Main. On this page, you can change certain aspects of the FT in question. Refer to How To Remove Unwanted Adjustments (or Payments) From A Completed Bill for a description of how to perform common maintenance functions.

- Accounting Date is the date the system uses to determine the financial transaction's accounting period in your general ledger.

- Current Amount contains the financial transaction's effect on the obligation's current balance.

- Payoff Amount contains the financial transaction's effect on the obligation's payoff balance. The Payoff Amount will be dim if it equals the Current Amount .

- Show on Bill indicates if information about the financial transaction appears on the taxpayer's bill.

- Obligation Information contains a summary of the respective obligation.

- Financial Transaction ID is the system-assigned unique identifier of the financial transaction.

At the bottom of the page is a summary of the financial transactions that match the search criteria.

Maintaining Bill Segments

A bill typically contains one bill segment for every active billable obligation linked to its account. A bill segment contains information showing how the segment was calculated and how it should be printed on the taxpayer's bill.

Note:

The actions taken to create a bill segment are dependent on the obligation's obligation type.

It's important to be aware that there are very few fields that are directly modifiable by a user. To modify most fields on a bill segment, you have to change source information (e.g., obligation, rate) and then regenerate the bill segment. For example, if you want to change the rate used to calculate a bill segment, you must change the rate history on the respective obligation and then cancel / rebill the bill segment. Refer to How To for step-by-step instructions that explain how to perform common bill segment maintenance functions.

Next in This Section

- Bill Segment Lifecycle

- Bill Segment - Main Information

- Bill Segment - RQ Details

- Bill Segment - Calc Lines

- Bill Segment - Financial Details

- Bill Segment - Bill Segment Messages

Bill Segment Lifecycle

The following diagram shows the possible lifecycle of a bill segment.

CAUTION:

This diagram only makes sense in the context of the page used to maintain bill segments. Refer to Bill Segment - Main Information for the details.

Bill segments are initially created in the Incomplete state. Bill segments in this state don't have bill lines or a financial transaction; they are simply a stub awaiting generation.

Click Generate to generate the bill segment's bill lines and its financial transaction.

- If the system cannot generate the bill segment (for any number of reasons), the bill segment is moved to the Error state. You may regenerate the bill segment after correcting the source of the error (by clicking Generate . You may also delete such a bill segment.

- If the system successfully generates a bill segment, the bill segment becomes Freezable. If the bill segment is incorrect, correct the cause of the problem (e.g., fix the meter read, change the obligation's rate) and regenerate the bill segment (by clicking Generate .

Click Delete to physically remove an Incomplete, Error or Freezable bill segment from the database.

Click Freeze to freeze a bill segment and its financial transaction. After doing this, the bill segment's state becomes Frozen and the bill segment may now appear on a taxpayer's bill. Also note, when a bill segment is frozen, its financial details will be interfaced to the general ledger the next time the GL interface executes.

You may not change a bill segment once it is frozen. However, you have two options if you want to change a frozen bill segment's financial impact:

- If you need to remove the financial effects of a bill segment, click Init Cancel . Clicking this button causes a new financial transaction to be generated and linked to the bill segment. This financial transaction reverses the financial effects of the original bill segment. The bill segment becomes Pending Cancel after the system successfully generates this financial transaction. At this point, you have two options:

- Click Cancel to freeze the cancellation. Clicking this button causes the bill segment to move to the Canceled state. Once canceled, the bill segment cannot be uncanceled or changed.

- Click Undo to return the pending cancellation to the Frozen state.

- Click Rebill if you need to recalculate the bill segment because something has changed since it was originally created (e.g., the obligation's rate was changed, a new read was entered). Clicking this button causes the following events to take place:

- The original bill segment is moved to the Pending Cancel state.

- A new bill segment is created in the Freezable (or Error) state.

At this point, you have two options.

- Click Freeze to make the new bill segment Frozen and make the original bill segment Canceled.

Note:

Multi-Cancel/Rebill Saves Time. If you need to rebill many bill segments related to an obligation (e.g., because many bill segments were created using the wrong rate), you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

Click Undo to delete the new bill segment and return the original bill segment to the Frozen state.

Bill Segment - Main Information

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How To for a description of how to perform common bill maintenance functions.

The Main page contains core bill segment information. Open Menu > Billing (Classic) > Bill Segment to view this information.

Note:

Most bill segments are created by a background process. Refer to A High Level Overview Of The Bill Creation Process for information describing how the system creates a bill segment.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, obligation type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

Account ID references the bill segment's account.

Current Amount is the bill segment's effect on the obligation's current balance. Payoff Amount is only shown if it differs from current amount. Refer to Billing - Current Balance versus Payoff Balance for more information.

Bill ID is the system-assigned unique identifier of the bill on which the bill segment appears. A concatenation of its bill date, status, due date and amount is displayed.

Obligation ID contains information about the bill segment's obligation. A concatenation of the obligation's division, obligation type, start option (if any), status and start date is displayed.

Period is the start and end dates of the bill segment.

Bill Cycle displays the bill cycle and window start date of the bill segment's bill. This information is only populated on bills when they are generated on-schedule by the batch billing background process. Bills generated manually, i.e. off-schedule, do not have this information.

Status is the bill segment's status. Refer to Bill Segment Lifecycle for the potential values and how to handle a bill segment when it exists in a given state.

The Closing switch is not used.

If the RQ Override switch is on, a user has overridden the rate quantities.

Location is the address of the main location associated with the obligation (as defined on the obligation's characteristic location).

Create Dt/Tm is the date and time on which the bill segment was created or regenerated.

In the Message area, a brief error message appears if there's a problem with the bill segment. The message area is suppressed if there are no problems with the bill.

Push the magnifying glass button to view the long explanation. The long explanation will provide information about the cause of the error (and how to fix it).

If the bill segment is a rebill of a canceled bill segment, a reference to the original bill segment is displayed. Click the adjacent go to button to transfer to the bill segment that was canceled.

If the bill segment was canceled and rebilled by another segment, a reference to the new bill segment is displayed. Click the adjacent go to button to transfer to the new bill segment that superseded the canceled segment.

The topics that follow describe each of the actions on that appear in the Bill Segment Actions area. Refer to How To for a description of typical business processes that use these buttons.

Note:

Mass update actions. This page allows you to work on individual bill segments. If you want to update many bill segments linked to a bill at once, try using the mass update actions available on Bill -Bill Segments.

Next in This Section

- Generate (Bill Segment)

- Delete (Bill Segment)

- Freeze (Bill Segment)

- Rebill (Bill Segment)

- Init Cancel (Bill Segment)

- Undo (Bill Segment)

- Cancel (Bill Segment)

Generate (Bill Segment)

Click the Generate button to create a new a bill segment.

This button is enabled when either of the following conditions is true:

- You are in add mode (i.e., you are not displaying an existing bill segment) and you have selected an Account ID, Bill ID and Obligation ID .

- You are displaying a bill segment that is Incomplete, Error, or Freezable. Refer to Bill Segment Lifecycle for more information about these status values.

You must specify the following parameters in order to generate a new bill segment:

- Cut-off Date is the last possible day of the bill segment's bill period. The current date defaults when the window opens. Refer to Ways To Control The End Date Of A Bill Segment for more information.

- Accounting Date is used to define the financial period to which the new bill segment's financial transaction will be booked. The current date defaults when the window opens.

After specifying the above parameters, click the Calculate button to create a new bill segment for the bill.

If an error exists, refer to How To Correct A Bill Segment That's In Error.

If there are no errors, the Bill Segment Freeze Option on the installation option controls the next step:

- If this option is set to Freeze At Bill Completion, return to Bill - Main (using the bill context menu) and click the Freeze / Complete button.

- If this option is set to Freeze At Will, click the Freeze button and, if everything looks clean, return to Bill - Main and click the Complete button.

Delete (Bill Segment)

The Delete button deletes a bill segment.

This button is enabled if you are displaying a bill segment that is Incomplete, Error, or Freezable. Refer to Bill Segment Lifecycle for more information about these status values.

Freeze (Bill Segment)

Clicking the Freeze button causes a freezable bill segment to become frozen. Refer to Bill Segment Lifecycle for more information about freezing.

This button is enabled if:

- the Freeze At Will Bill Segment Freeze Option on the installation option has been selected AND

- the bill segment is freezable.

Note:

Freezing a day or more after generation. If the bill segment is linked to a closed accounting period, a pop-up appears in which you can specify a new accounting date. This will only happen if the accounting period closes before you freeze the bill segment (the accounting date is stamped on a bill segment when it's initially generated).

Note:

If problems are detected after freezing. A bill segment may not be changed after it is frozen. All subsequent changes must occur by canceling the frozen bill segment and creating a new bill segment. Refer to How To Cancel A Bill Segment and How To Cancel / Rebill A Bill Segment for more information.

Rebill (Bill Segment)

If problems are detected with a frozen bill segment, it should be canceled and a new bill segment should be created. We refer to this process as cancel / rebill. Refer to Cancel / Rebill Incorrect Bill Segments for more information.

Before you cancel / rebill, you'll probably need to fix the cause of the problem.

Note:

Multi-Cancel/Rebill Saves Time. If the cause of the problem impacts many bill segments related to an obligation, you should use the Multi Cancel Rebill transaction as it allows you to cancel / rebill an unlimited number of bill segments at once.

The Rebill button causes an existing bill segment to be canceled, and a new bill segment to be created.

This button is enabled when you display a Frozen bill segment AND the bill segment's bill is not written off. Refer to Bill Segment Lifecycle for more information about these status values.

You must specify the following parameters in order to cancel and rebill a new bill segment:

- Cancel Reason defines why the bill segment is being canceled.

- Cutoff Date is the last day of the new bill segment. The cutoff date on the bill segment defaults when the window opens.

- Accounting Date is used to define the financial period to which the canceled and new bill segments' financial transactions will be booked. The current date defaults when the window opens.

- Choose Use Cut off Date as Billing Option.

- Turn on Use Old RQ for Regen if you want the system to use the details on the original bill segment when it calculates the new bill segment.

Click the Calculate button to cancel the original bill segment and create a new bill segment.

At this point, there are now two bill segments - the original bill segment is in the state of Pending Cancel, the new bill segment is in the Freezable (or Error) state. If you want to back out, click the go to button to return to the original bill segment and then click Undo (this will delete the new bill segment and return the original bill segment to the Frozen state). If the new bill segment looks correct, click Freeze to move the original bill segment to the Canceled state and the new bill segment to the Frozen state.

Init Cancel (Bill Segment)

The Init Cancel button causes the first step of the bill segment cancellation process to be executed. You'd click this button if a frozen bill segment should never have been created (i.e., you want to remove the financial impact of a bill segment from a taxpayer's balance).

This button is enabled when you display a Frozen bill segment AND the bill segment's bill is not written off. Refer to Bill Segment Lifecycle for more information about these status values.

You must specify the following parameters in order to cancel and rebill a new bill segment:

- Cancel Reason defines why the bill segment is being canceled.

- Accounting Date is used to define the financial period to which the canceled bill segment's financial transactions will be booked. The current date defaults when the window opens.

Click the Calculate button to cancel the original bill segment.

At this point, the bill segment is in the state of Pending Cancel. If you want to back out, click Undo ; the bill segment will be returned to the Frozen state. Click Cancel to move the bill segment to the Canceled state.

Undo (Bill Segment)

The Undo button returns a Pending Cancel bill segment to the Frozen state. If a Pending Cancel bill segment was created during a Cancel / Rebill, the newly created Freezable bill segment is also deleted.

This button is enabled when you display a Pending Cancel bill segment. Refer to Bill Segment Lifecycle for more information about this status.

Cancel (Bill Segment)

Clicking the Cancel button causes a Pending Cancel bill segment to become Canceled. Refer to Bill Segment Lifecycle for more information about cancellation.

This button is enabled if a Pending Cancel bill segment is displayed AND the bill segment's bill is not written off.

You must specify the following parameters in order to cancel the frozen bill segments:

- Cancel Reason defines why you are performing the cancellation.

- Accounting Date defines the financial period to which the canceled bill segments' financial transactions will be booked. The current date defaults when the window opens.

After specifying the above parameters, click the Calculate button to cancel the frozen bill segments.

If the related bill is pending, the cancellation will cause the bill segment to be suppressed on the version of the bill sent to the taxpayer (but it remains in the database for audit and financial reporting purposes).

If the related bill is complete and you do not Reopen the bill, the financial impact of the canceled bill segment will appear on the next bill created for the account (under Bill Corrections).

If the related bill is complete you may be able to Reopen the bill and then Complete it. By doing this, you can suppress a frozen bill segment on a previously completed bill. This means that if you catch a problem after completion you don't necessarily have to show the problem to the taxpayer. Rather, cancel the problem, reopen and then recomplete the bill (when you recomplete the bill the system will mark the bill segment to be suppressed on the version sent to the taxpayer because its cancellation appears on the same bill as the original charges).

Bill Segment - RQ Details

Fastpath:

The Description of Page section that appears below simply describes the fields on this page.

The RQ Details page contains information about the rate quantities (RQ) that will be priced by the obligation's rate. In addition to showing RQ details, this page shows any Calculation / Audit Read Details that are linked to the bill segment. Open Menu > Billing (Classic) > Bill Segment and navigate to the RQ Details tab to view this information.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, obligation type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The Rate Quantity details grid is a snapshot of the rate quantities amassed from:

- The RQ rules defined on the obligation's rate. Refer to Defining Measured Quantity Manipulation Rules for more information about how RQ rules can introduce additional rate quantities.

- Billable charges that supply rate quantities.

One row exists for every unique combination of unit of measure (UOM), time-of-use (TOU) code, and rate quantity identifier (RQI) associated with the obligation.

This information may be overridden on a bill segment in the Error or Freezable state. Insert one row in the rate quantity grid (click the + button) for each UOM/TOU/RQI you need to add. You may also change amounts that were populated by the system when it initially generated the bill by simply overwriting the information.

CAUTION:

The proper way to fix the RQ details on a bill segment is to correct the cause of the error. Overriding the RQ details on a bill segment is a last resort that should only be used when you can't fix the cause of the problem. Refer to How To Cancel / Rebill A Bill Segment for ways to fix common problems.

The following information is displayed in the grid:

- Unit of Measure is the unit of measure of the rate quantity.

- Time of Use is the time-of-use of the rate quantity.

- RQI is the rate quantity identifier of the rate quantity.

- Initial Rate Quantity is the initial quantity amassed by the system before application of the rate's RQ rules.

- Billable Rate Quantity is the quantity that will be priced by the obligation's rate. This amount differs from the initial quantity when the rate's RQ rules manipulate the value.

The Calculation/Audit Read Details section contains Calculation / Audit Read Details. This section only appears if the obligation has a special role of Billable Charge.

The following information may be defined for each calculation / audit read:

- Final Unit of Measure is the final unit of measure of the calculation / audit read.

- Final Time of Use is the final time-of-use code of the calculation / audit read.

- Final RQI is the final rate quantity identifier of the calculation / audit read.

- Start Date/Time is the date and time of the calculation / audit read.

- End Date/Time is the date and time of the calculation / audit read.

- Final Quantity is the quantity of the calculation / audit read. This would typically contain the amount that was billed during the Start Date/Time through the End Date/Time for the Final Unit of Measure , Final Time of Use and Final RQI .

- Unit of Measure is the initial unit of measure of the calculation / audit read (if any).

- Time of Use is the initial time-of-use code of the calculation / audit read.

- RQI is the initial rate quantity identifier of the calculation / audit read.

- Start Quantity is the "start" quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity).

- End Quantity is the "end" quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity).

- Quantity is the resulting measured quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity). It should contain the difference between the Start Quantity and the End Quantity .

- Constant is the constant of the measuring device that was multiplied by the Quantity to derive the calculation / audit read's Final Quantity

- How To Use is a code that indicates if the "calculation / audit" read was considered to be additive, subtractive, peak or check.

- Use Percent is the percentage of the total quantity that was billed.

- Meas Peak Qty indicates if the unit of measure is one that measures a peak amount.

- Multiplier is the ratio of the Final Quantity and the Quantity . This value only appears if a non-zero value exists in both of these fields.

- Sequence is the sequence number (if any).

This information may be overridden on a bill segment in the Error or Freezable state. Insert one row in the calculation / audit details grid (click the + button) for each entry you need to add. You may also information populated by the system when it initially generated the bill by simply overwriting the information.

CAUTION:

The proper way to fix the calculation/audit details on a bill segment is to correct the cause of the error. Overriding the calculation/audit details on a bill segment is a last resort that should only be used when you can't fix the cause of the problem.

Fastpath:

Refer to Calculation / Audit Read Details for more information about this section.

Bill Segment - Calc Lines

Fastpath:

The Description of Page section below simply describes the fields on this page. Refer to How To Cancel / Rebill A Bill Segment for instructions describing how to regenerate this information if the bill segment is incorrect.

The Calc Lines page contains information about the bill calculation lines produced when the system generates the bill segment. These lines are the source of the details printed on the taxpayer's bill. Open Menu > Billing (Classic) > Bill Segment and navigate to the Calc Lines tab to view this information.

Fastpath:

Most obligations use a rate to calculate the information that appears on this page. Refer to How Rates Affect The Information On Bill Segments for more information.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, obligation type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The Bill Segment Header scroll contains one entry for every version of the rate that was used to calculate the bill segment's lines. Because most bill segments use a single rate version, you typically only see one entry in the scroll.

The following information is displayed above the bill calculation line grid.

- Sequence will be 1 unless multiple versions of the rate were in effect during the bill period. If there was more than one effective rate version, there will be a separate set of calc lines for each version applied. The lines that apply to the first part of the bill period would have a Sequence of 1, the lines for the next part of the bill period would have a Sequence of 2 and so on.

- Start Date - End Date is the portion of the bill segment period that the calculation details apply.

- Amount is the sum of the bill calculation lines in the grid.

- Desc on Bill is summary information about the calculation details that will be printed on the taxpayer's bill.

- Rate Version is the ID of the rate version and its effective date. This information only appears if a rate was used to calculate the charges.

The calculation lines grid is a snapshot of how the system calculated the bill segment amount. One row exists for every calculation involved in this process. This information is for audit purposes only and may not be modified. The following information is displayed in the grid:

- A drill down button appears in the Calc Line Char column if the bill calculation line has characteristics. The Char column only appears if at least one of the calculation lines has a characteristic.

- Sequence is the system-assigned unique identifier of the calculation detail row.

- Description on Bill is the information about the bill line that appears on the taxpayer's bill.

- Calculated Amount is the calculated amount associated with the bill line.

- The Print switch controls whether information about this line will print on the taxpayer's bill.

- The Appears in Summary switch defines if this line's amount also appears on a summary line. This switch plays a part at bill print time - those lines that appear in a summary print in the left dollar column, those that don't appear in a summary print in the right dollar column.

The system automatically populates this switch as follows:

- Bill segments created by applying a rate have this switch turned on if the corresponding rate component is summarized on a summary rate component.

- Bill segments created from billable charges use the value of this switch as defined on the billable charge. Refer to Maintaining Billable Charges for more information.

- Unit of Measure (UOM) is the unit of measure of the rate quantity priced on the calculation line.

- Time of Use (TOU) is the time-of-use code of the rate quantity priced on the calculation line.

- RQI is the rate quantity identifier of the rate quantity priced on the calculation line.

- Billable Rate Quantity is the quantity priced on the calculation line. This quantity will be different from the measured quantity is there are RQ rules in effect.

- Base Amount is used by calculation lines (e.g. taxes) that are cross-referenced to other calculation lines and whose value(s), therefore, depend on the amounts calculated by those other lines. The Base Amount shows the total amount derived from the cross-referenced line(s) that the current line then used to calculate its billed amount.

- Rate Comp Seq refers to the sequence number of the rate component on the applicable rate version that was used to calculate the line.

- Measures Peak Qty is checked if the UOM priced on the calculation line is used to measure a peak quantity.

- Exempt Amount is not used at this time.

- Distribution Code is the distribution code associated with the calculation line. This distribution code is used to build the general ledger details on the bill segment's financial transaction.

- Description describes the characteristic value that was used when the line's amount was calculated. This information is only displayed if the line was calculated using a rate factor (because only rate factors use characteristic values). Refer to An Illustration Of A Rate Factor And Its Characteristics for more information.

Bill Segment - Financial Details

Fastpath:

The Description of Page section that appears below simply describes the fields on this page. Refer to How To Cancel / Rebill A Bill Segment for instructions describing how to regenerate this information if it is incorrect.

The Financial Details page contains information about the financial effects of the bill segment. Open Menu > Billing (Classic) > Bill Segment and navigate to the Financial Details tab to view this information.

Note:

Refer to The Source Of GL Accounts On A Bill Segment's Financial Transaction for how the system compiles this information.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, obligation type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The Bill Segment FT scroll contains one entry for every financial transaction (FT) associated with the bill segment. All bill segments have an FT that shows the impact of the bill segment on the general ledger. A bill segment may have an additional FT (for a maximum of two) if it is cancelled. The second FT shows the impact of the cancellation on the general ledger.

The following financial transaction information is displayed above the general ledger distribution grid.

- FT Type displays the type of financial transaction (FT).

- Show on bill indicates if information about the FT appears on the taxpayer's bill.

- FT ID is the system-assigned unique identifier of the FT. Click the go to button to transfer to the Financial Transaction - Main page. On this page you can change certain aspects of the FT in question. Refer to How To Remove Unwanted Adjustments (or Payments) From A Completed Bill for a description of how to perform common maintenance functions.

- The posted by information that appears adjacent to the FT ID shows the date on which the FT was frozen and the user ID of the user who performed the operation.

- The "Linked to bill on" message appears when the financial transaction is linked to a bill. A FT is linked to a bill the next time a bill is completed for the account. Therefore, if a user cancels a bill segment, the FT associated with the cancellation will not be linked to a bill until the next bill is completed (although the financial effect of the cancellation takes place immediately). Click the adjacent go to button to transfer to the bill on which the FT appears.

- Current Amount contains the FT's effect on the obligation's current balance.

- Payoff Amount contains the FT's effect on the obligation's payoff balance. This field is only visible when the payoff amount differs from the current amount.

- Accounting Date is the date the system uses to determine the FT's accounting period in your general ledger.

- Effective Date is the date the FT starts aging.

The journal details grid is a snapshot of the distribution codes used to generate the GL accounts that are affected by the FT. This information is for audit purposes only and may not be modified. The following information is displayed in the grid:

- Sequence is the system-assigned unique identifier of the distribution line.

- Distribution Code is the distribution code used to generate the GL account affected by the distribution line. Drill over to the FT if you need to see the actual GL account.

- Amount is the amount debited / credited (credits are shown as negative values).

- Statistics Code and Statistics Amount are only specified when a statistical quantity is associated with the distribution line.

- Description describes the characteristic value that was used when the line's amount was calculated. This information is only displayed if the distribution line was derived from bill calculation lines that were calculated using a rate factor (because only rate factor's use characteristic values). Refer to An Illustration Of A Rate Factor And Its Characteristics for more information.

- If you keep the default installation option where fund accounting is practiced, the description of the Fund associated with this distribution code is displayed.

Bill Segment - Bill Segment Messages

The Messages page is a grid containing one row for every message that appears on the bill segment. Open Menu > Billing (Classic) > Bill Segment and navigate to the Bill Segment Messages tab to view this information.

Note:

No messages until completion. A bill segment has no messages until it is completed (unless you insert them manually). At completion time, the system assembles messages from the various message sources. Refer to The Source Of Bill Messages for information about these sources.

Note:

The bill may also have messages. Be aware that only obligation-oriented messages are linked to a bill segment. There may also be account-oriented messages linked to the bill. Refer to Bill - Bill Messages for information about the page on which account-oriented messages are displayed. Refer to The Source Of Bill Messages for information about the various message sources and whether each is linked to a bill or a bill segment.

Description of Page

Bill Seg Info is a concatenation of the bill segment's division, obligation type, status, bill period and amount. Bill Segment ID is the system-assigned unique identifier of the bill segment.

The following columns are displayed in the grid:

- Msg Code is the code that identifies the bill message.

- Message On Bill is the message associated with the code.

- Priority is the bill messages priority (on the printed bill).

- Insert Code defines if the bill message causes an insert in the envelope.

Multi Cancel/Rebill

The Multi-Cancel/Rebill transaction is used to cancel / rebill (and freeze) one or more bill segments linked to an obligation.

Note:

You would typically use this transaction when something has been wrong for an extended period of time. For example, if the taxpayer was assigned the wrong rate from the beginning, you would correct the taxpayer's rate using Obligation - Rate Info and then use this transaction to cancel / rebill the taxpayer's historical bill segments.

The topics in this section describe how to use this transaction.

Next in This Section

- Multi Cancel/Rebill - Main

- Multi Cancel/Rebill - Graph

Multi Cancel/Rebill - Main

The main page is used to select the bill segments to be cancel/rebilled and to initiate the cancel/rebill request. Open Menu →Billing (Classic) →Multi Cancel/Rebill to use this transaction.

Description of Page

This page contains all non-cancelled bill segments associated with a given Obligation ID. The obligation's Obligation Info, Account ID (and name), characteristic Location (and address), Current Balance and Payoff Balance are displayed at the top of page.

When the page first opens, the grid is populated with ALL non-cancelled bill segments displayed in reverse chronology order. All frozen bill segments are pre-selected for cancel/rebill processing. The following information appears in the grid:

- Selected Switch. If this switch is turned on, the bill segment will be cancel / rebilled when the Cancel/Rebill/Freeze button is clicked. You can use the mouse to toggle the value of this switch on a specific bill segment. Alternatively, you can click the Select All button or Unselect All button to toggle the switch for all frozen bill segments. The checkbox is disabled if the bill segment's bill is written off. Note: the total number of selected bill segments is shown above the grid for confirmation purposes.

- Start Date. This is the first day of the bill segment.

- End Date. This is the last day of the bill segment.

- Create Date/Time. This is the day/time the bill segment was created.

- Amount. This is the payoff amount of the bill segment.

- Original Amount. This column only contains a value if the bill segment is a rebill of another bill segment. In this situation, one of the following values will be displayed:

- If the amount of the new bill segment differs from the amount of the original bill segment, the amount of the original bill segment will be displayed.

- If the amount of the new bill segment equals the amount of the original bill segment, the word No change will be displayed.

- Bill Segment Information. This is the standard bill segment summary information.

Note:

Sorting By Values In The Grid. Just like all grids in the system, you can click on a column heading to resort the grid by the value of the respective column. This might be useful to sort the bill segments in Amount order.

After selecting the bill segments to be cancel/rebilled, click the Cancel/Rebill/Freeze button.

Please specify the following information and then click Calculate to cancel the selected bill segment and create new bill segments:

- Cancel Reason defines why the bill segment(s) are being canceled.

- Accounting Date is used to define the financial period to which the canceled and new bill segments' financial transactions will be booked.

- Choose Use Cut off Date as Billing Option.

- If you'd prefer to have the system use the details snapshot on the original bill segments, turn on Use Old RQ.

CAUTION:

Warning! If the cause of the rebill is an incorrect rate and the new rate requires rate quantities that were not calculated when the bill was originally calculated, do not turn on Use Old RQ. Why? Because you want the system to derive new rate quantities during the rebill process.

Note:

Default note. The Accounting Date is defaulted to the current date and the Use Old RQ switch is turned on.

After specifying the above information, the system cancel / rebills each segment in chronological order (i.e., earlier segments will be cancel / rebilled before later segments). The new amount of each bill segment is shown in the Original Amount column. You can navigate to the Graph page to graphically view the financial ramifications of the cancel/rebills.

Note:

Errors. It's possible that bill segment errors will occur when you cancel / rebill the bill segments. For example, if you change the obligation's rate to a rate that is no longer effective on the bill segment period, a bill segment error will be generated. If this occurs, you must go to Bill Segment - Main for the pending cancel bill segment and use the Undo action to remove the offending bill segment (and restore the original segment to the Frozen state). Alternatively, you can drill down on the Error bill segment and use the Regenerate action after correcting the cause of the problem.

Note:

There is no Undo. Unlike cancel / rebills performed on Bill Segment - Main, there is no Undo action. This is because the multi-cancel/rebill transaction freezes the newly created bill segments after it cancel/rebills; whereas the bill segment transaction lets you examine the new bill segment before you freeze it. If you made a mistake, simply correct the cause of the mistake and then cancel / rebill again. The erroneous financial transactions will be automatically suppressed on the next bill produced for the taxpayer.

Multi Cancel/Rebill - Graph

This page contains a graph that shows the rebilled and original payoff amounts for an obligation's non-cancelled bill segments. Open Menu > Billing (Classic) > Multi Cancel/Rebill and navigate to the Graph page to view this information.

Description of Page

This page contains a graph that shows the payoff amounts for an obligation's non-cancelled bill segments (represented by the blue bars in the graph). If a bill segment is a rebill of another bill segment, the payoff amount of the original bill segment is displayed on a red-colored bar adjacent to the respective blue bar.

Note:

Click a bar. You can click on a bar to drill down to a bill segment.

Obligation Billing History

Open Menu > Billing (Classic) > Obligation Billing History to view a history of all bill segments produced for an obligation.

Description of Page

The Account ID is displayed with the account's name adjacent.

The Obligation Information shows a summary of information about the obligation. The Obligation ID is the unique identifier of this obligation.

One row is displayed for every bill segment ever produced for the selected obligation.

The following information is displayed for each bill segment:

- The Start Date and End Date of the bill segment.

- The number of Days in the bill segment period.

- The Status of the bill segment

- The Current and Payoff Amounts of the bill segment.

- The UOM (Unit of Measure) of the rate quantity designated as the "graph UOM" for the obligation's obligation type.

- The total amount of the service Billable Rate Quantity that was billed.

- The Average Daily Rate Quantity is the Billable Rate Quantity divided by the numbers of days of service.

If you need to see more detailed information about the bill segment, click the go to button to transfer to the bill segment page.

Bill Exception

If errors are detected during the billing process, it may cause a record to be written to the bill exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-BIERR background process. This process generates a To Do entry for every record in the bill exception table.

Fastpath: Refer to How to Correct a Bill That's In Error for instructions describing how to correct a bill.

Bill Segment Exception

If errors are detected during the billing process, it may cause a record to be written to the bill segment exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-BSERR background process. This process generates a To Do entry for every record in the bill segment exception table.

Fastpath: Refer to How To Correct A Bill Segment That's In Error for instructions describing how to correct a bill segment.

Maintaining Billable Charges

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.

Note:

Billable charges can be uploaded from an external system. Refer to Uploading Billable Charges and Using Billable Charges For Pass Through Billing for more information.

A billable charge must refer to 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 billable charge. This means that if an obligation has many unbilled billable charges, it will have many bill segments.

- 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 collections process monitors billable charge obligations for overdue debt and responds accordingly when overdue debt is detected.

- This obligation must reference an obligation type that has a Special Role Flag of Billable Charge. If such an obligation does not already exist for the account, one must be created before you can levy a billable charge. See "For more information" at the end of this section for links to other sections that will help you with this process.

Billable charge templates exist to minimize the effort required to create a billable charge for a taxpayer. A billable charge template contains the standard bill lines, amounts and distribution codes used to charge for a one-off charge.

A user may override the information on the template when the billable charge is created.

Note:

Templates aren't required. A billable charge can be created without a template for a truly unexpected charge. If you don't use a template, you'll have to enter the bill information manually.

Fastpath:

Refer to Setting Up Billable Charge Templates for more information.

Note:

Adding taxes and other calculation lines to a billable charge. Refer to Billable Charge - RQ Details for information about how to have the system calculate tax lines and append them to the billable charge.

Next in This Section

- Billable Charge - Main

- Billable Charge - Line Characteristics

- Billable Charge - RQ Details

- Billable Charge - Calculation Details

Billable Charge - Main

Open Menu > Billing (Classic) > Billable Charge to add or update a billable charge.

Description of Page

The Billable Charge ID is system generated. The Account ID of the account responsible for the charge is displayed at the top.

Use Obligation ID to define the ID of the billable charge obligation that will hold the billable charge's debt. The Account ID for the obligation is displayed for information purposes.

Use Start Date and End Date to define the charge's bill period.

Note:

Installment billable charges. You can create many future dated billable charges to implement unusual installment plans. For example, if you want to bill a taxpayer $250 today, $150 next month, and $1000 three months from now; you could create three billable charges with a date that reflects the earliest bill date. When a bill is produced for the account, the system will create a bill segment for every billable charge whose start date is on or before the current date.

If you want to create the billable charges from an existing template, enter the ID of the Billable Charge Template from which the billable charge information defaults. If your obligation type indicates a billable charge template, that value will be defaulted.

Use Description on Bill to define the verbiage that should print on the taxpayer's bill above the line item details.

Billable Charge Status defines the state of the billable charges. Possible values are Billable and Canceled. Click the Cancel button to cancel a billable charge.

Bill Segment ID is the ID of the bill segment on which the billable charge's charge details appear. This information is only populated AFTER the billable charge has been swept onto a bill.

The Total Bill Amount displays the sum of all billable charge lines except those that are Memo Only. The Total Line Amount displays the sum of all billable charge lines except those that Appear In Summary.

The information in the grid defines the line item details associated with the billable charge. Click the drill down button to navigate to the line characteristics. The following fields are required for each line:

Sequence

Sequence controls the order in which the line items appear on the bill segment.

Description on Bill

Specify the verbiage to print on the bill for the line item.

Charge Amount

Specify the amount to charge for the line item.

Show on Bill

Turn this switch on if the line item should appear on the taxpayer's printed bill. It would be very unusual for this switch to be off.

Appears in Summary

Turn this switch on when the amount associated with this line also appears in a summary line. This switch plays a part at bill print time - those lines that appear in a summary print in the left dollar column, those that don't appear in a summary print in the right dollar column. Also note, those lines that appear in a summary line are not included in the total amount associated with the billable charge.

Memo Only, No GL

Turn this switch on if the billable charge line does not contribute to the total amount due (e.g., this switch would be on for "information only" lines).

Distribution Code

Specify the distribution code that identifies the GL account associated with this line item. The description of the code appears adjacent.

Fastpath:

For more information about billing billable charges, refer to How To Create An Ad-hoc Bill. For more information about billable charge templates, refer toSetting Up Billable Charge Templates.

Billable Charge - Line Characteristics

Characteristics may be associated with billable charge lines. Typically, this is done to categorize billable charge lines for reporting purposes.

Open Menu > Billing (Classic) > Billable Charge and navigate to the Line Characteristics tab to maintain characteristics that are associated with billable charge.

Description of Page

The Billable Charge Line scroll defines the billable charge line to which you wish to assign characteristic values. The following fields display:

Characteristic Type

The type of characteristic.

Characteristics Value

The value of the characteristic.

Note:

You can only choose characteristic types defined as permissible on a billable charge line. Refer to Setting Up Characteristic Types & Their Values for more information.

Billable Charge - RQ Details

Optionally, you may specify rate quantities associated with a billable charge. These are most commonly used when you want the system to calculate charges in addition to the billable charge lines (e.g., adding tax to the billable charge lines).

Note:

The obligation must specify a rate. If you want the system to calculate additional charges based on the rate quantities defined on this page, the related billable charge obligation must reference a rate. This rate must have rate components that calculate charges based on the rate quantities specified on this page. When the obligation is next billed, the system will sweep on the billable charges and then call the rate and pass it the rate quantities defined on this page. The rate will calculate the additional charges and these will be appended to the bill segment.

Open Menu > Billing (Classic) > Billable Charge and navigate to the RQ Details tab to maintain a billable charges rate quantities.

Description of Page

The following fields display:

Sequence

Specify the sequence number of the RQ.

Unit of Measure

Select the unit of measure of this RQ. One or more of Unit of Measure, Time of Use, or Rate Quantity Identifier must be selected.

Time of Use

Select the time of use period.

Rate Quantity Identifier

Select the RQ identifier.

Rate Quantity

Specify the number of units of this rate quantity.

Billable Charge - Calculation Details

Optionally, you may specify calculation details associated with a billable charge. These are most commonly used when you need to print the details that were used to calculate the bill lines that appear on the main tab.

Open Menu > Billing (Classic) > Billable Charge and navigate to the Calculation Details tab to maintain a billable charge's rate quantities.

Description of Page

The grid is a snapshot of the details that were billed using the bill lines shown on the main tab. One row exists for every calculation detail that should be swept onto the related bill segment when the system creates a bill segment for this billable charge. The following information is displayed in the grid:

- Final Unit of Measure is the final unit of measure of the calculation / audit read.

- Final Time of Use is the final time-of-use code of the calculation / audit read.

- Final RQI is the final rate quantity identifier of the calculation / audit read.

- Final Quantity is the quantity of the calculation / audit read. This would typically contain the amount that was billed during the Start Date/Time through the End Date/Time for the Final Unit of Measure, Final Time of Use and Final RQI.

- Sequence is the sequence number (if any).

- Unit of Measure is the initial unit of measure of the calculation / audit read (if any).

- Time of Use is the initial time-of-use code of the calculation / audit read.

- RQI is the initial rate quantity identifier of the calculation / audit read.

- Start Quantity is the "start" quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity).

- End Quantity is the "end" quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity).

- Quantity is the resulting measured quantity (if any). This value would typically only be displayed if the calculation / audit read is subtractive (i.e., you must subtract the end quantity from the start quantity to determine billable quantity). It should contain the difference between the Start Quantity and the End Quantity.

- Constant is the constant of the measuring device that was multiplied by the Quantity to derive the calculation / audit read's Final Quantity.

- How To Use is a code that indicates if the "calculation / audit" read is considered to be additive, subtractive, peak or check.

- Use Percent is the percentage of the total quantity that was billed.

- Measures Peak Qty indicates if the unit of measure is one that measures a peak amount.

- Start Date/Time is the date and time of the calculation / audit read.

- End Date/Time is the date and time of the calculation / audit read.

- Multiplier is the ratio of the Final Quantity and the Quantity. This value only appears if a non-zero value exists in both of these fields.

Note:

The multiplier is calculated by dividing the Final Quantity by the Quantity (if the Quantity is 0, then the result is 0). This is not stored on the database. There is a chance that the value is not precise due to round-off.

Uploading Billable Charges

This section describes how the system uploads billable charges from an external source. This mechanism is used when you need to "pass through" charges that have been calculated by a third party but appear on your bill.

Next in This Section

- Billable Charge Upload Background Processes

- BCUP-PRG - Purge Billable Charge Upload Objects

- Billable Charge Upload Staging

- Billable Charge Upload Exception

Billable Charge Upload Background Processes

The following diagram illustrates the processes involved in the uploading of billable charges into the system.

The topics in this section describe how these processes work.

Next in This Section

- Process X - Populate BC Upload Staging

- BCU1 - Validate & Populate Billable Charge Upload Staging

- BCU2 - Create Billable Charge

Process X - Populate BC Upload Staging

Process X refers to the mechanism used by your organization to populate the various staging tables (shown in the yellow section of the following ERD).

The topics in this section describe each of these tables.

Next in This Section

- Billable Charge Upload Staging Layout

- Billable Charge Line Upload Staging Layout

- Billable Charge Line Characteristic Upload Staging Layout

- Billable Charge Rate Quantity Upload Staging Layout

- Billable Charge Calculation Details Upload Staging Layout

Billable Charge Upload Staging Layout

You must create an upload staging record for each billable charge. The name of this table is CI_BCHG_UP. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

BCHG_UP_ID

30

Y

Char

This is the unique identifier of the record. This value does NOT have to be a random number, but it does need to be unique. If your process that inserts records on this table is capable of calling a COBOL routine, call CIPCKEYG and it will supply a 12 digit random number for you.

BCHG_UP_STAT_FLG

2

Y

Char

This must be set to P for Pending.

NT_XID_CD

30

N

Char

Leave this column blank.

SA_EXT_REF_ID

36

N

Varchar2

Leave this column blank.

BCHG_EXT_REF_ID

50

N

Varchar2

This is the identifier of the billable charge in the sender's system.

CRE_DTTM

26

N

Date/Time

The date and time the upload staging row was inserted (this can be used for audit purposes).

START_DT

10

Y

Date

The start date of the period encompassed by the billable charge.

END_DT

10

Y

Date

The end date of the billable charge period.

DESCR_ON_BILL

80

Y

Varchar2

This is the description that should prefix the charges on the printed bill.

SA_ID

10

See note

Char

This must correspond with an obligation ID of a billable charge obligation.

BILLABLE_CHG_ID

12

N

Char

Leave this column blank. It will be assigned by the system when it creates a billable charge record.

Billable Charge Line Upload Staging Layout

You must create a billable charge line upload record for each line to be uploaded. The name of this table is CI_BCHG_LINE_UP. The following table describes each column on this table.

Note:

Defaulting from Billable Charge Line Type (BCHG_UP_XTYP). Please pay special attention to the Comments column below as many fields, if left blank, will default from each record's billable charge upload line type (BCHG_UP_XTYP).

Column Name

Length

Req'd

Data Type

Comments

BCHG_UP_ID

30

Y

Char

This is the foreign key to the billable charge upload staging record.

LINE_SEQ

3

Y

N

This is the unique line number of the billable charge line. This value must be unique within the billable charge.

DESCR_ON_BILL

80

Y

Varchar2

This is the description that will be printed on the bill for the line.

CHARGE_AMT

13.2

N

N

This is the amount associated with the billable charge line.

BCHG_LINE_XID

20

N

Varchar2

This is the unique identifier of the billable charge line in the sender's system.

BCHG_UP_XTYPE

30

N

Char

This is the type of billable charge line. This is a foreign key reference to the billable charge line type control table. This control table is used to populate the remaining fields (if they are blank). If this field is blank, the remaining fields must be specified as they cannot be defaulted from the billable charge line type control table. Refer to Billable Charge Line Type for more information.

CURRENCY_CD

3

See note

Char

This is a foreign key reference to the currency code of the billable charge line. This field must be specified if CHARGE_AMT is non-zero.

SHOW_ON_BILL_SW

1

See note

Char

This should be Y if the line should appear on the taxpayer's printed bill. This should be N if the line should not appear on the taxpayer's printed bill. If left blank, this value will be populated from the line's BCHG_UP_XTYPE.

APP_IN_SUMM_SW

1

See note

Char

This should be Y if the line appears in a summary line. This should be N if the line does not appear in a summary line. This switch plays a part at bill print time - those lines that appear in a summary print in the left dollar column, those that don't appear in a summary print in the right dollar column. If left blank, this value will be populated from the line's BCHG_UP_XTYPE.

MEMO_SW

1

See note

Char

This should be Y if the line does NOT affect the general ledger. This should be N if the line affects the general ledger. If left blank, this value will be populated from the line's BCHG_UP_XTYPE.

DST_ID

10

See note

Char

If the line affects the general ledger, the set ID (the previous field) and the distribution code of the GL account must be specified. If left blank, this value will be populated from the line's BCHG_UP_XTYPE.

Billable Charge Line Characteristic Upload Staging Layout

If you want to upload characteristics on your billable charge lines, you must create a billable charge line characteristic upload record for each characteristic on each line. The name of this table is CI_B_LN_UP_CHAR. The following table describes each column on this table.

Column Name

Length

Req'd

Data Type

Comments

BCHG_UP_ID

30

Y

Char

This is the foreign key to the billable charge upload staging record.

LINE_SEQ

3

Y

N

This is the foreign key to the billable charge line upload staging record

CHAR_TYPE_CD

8

Y

Char

This is the unique identifier of the billable charge line characteristics. This value must be unique within the billable charge line characteristics.

CHAR_VAL

16

N

Char

A characteristic value must be supplied if the ad hoc switch on characteristic type is N. Otherwise, it is not allowed.

ADHOC_CHAR_VAL

30

N

Varchar2

An ad hoc characteristic value must be supplied if the ad hoc switch on characteristic type is Y. Otherwise, it is not allowed.

Billable Charge Rate Quantity Upload Staging Layout

You must create a billable charge rate quantity upload record for each rate quantity to be uploaded. The name of this table is CI_BCHG_UP_SQ. The following table describes each column on this table. Refer to "pass through" charges for more information about how this type of information is used.

Column Name

Length

Req'd

Data Type

Comments

BCHG_UP_ID

30

Y

Char

This is the foreign key to the billable charge upload staging record.

SEQ_NUM

3

Y

N

Sequence of the rate quantity within the Billable Charge Upload

UOM_CD

4

N

Char

The unit of measure of the Billable Charge Upload RQ row. If specified, it must reference a valid value on CI_UOM. Note, at least one of the following fields should be specified: SQI_CD, TOU_CD, UOM_CD.

TOU_CD

8

N

Char

The time of use of the Billable Charge Upload RQ row. If specified, it must reference a valid value on CI_TOU. Note, at least one of the following fields should be specified: SQI_CD, TOU_CD, UOM_CD.

SQI_CD

8

N

Char

The rate quantity identifier of the Billable Charge Upload RQ row. If specified, it must reference a valid value on CI_SQI. Note, at least one of the following fields should be specified: SQI_CD, TOU_CD, UOM_CD.

SVC_QTY

12.6

N

N

Quantity of the rate used for the UOM / TOU / RQI combination

Billable Charge Calculation Details Upload Staging Layout

You must create a billable charge read details upload record for each calculation detail to be uploaded. The name of this table is CI_BCHG_UP_READ. The following table describes each column on this table. Refer to "pass through" charges for more information about how this type of information is used.

Column Name

Length

Req'd

Data Type

Comments

BCHG_UP_ID

30

Y

Char

This is the foreign key to the billable charge upload staging record.

SP_ID

10

Y

Char

Leave this column blank. It is not used.

SEQNO

5

Y

Number

This should be a value greater than zero.

END_READ_DTTM

26

Y

DateTime

This is the date and time of the end quantity

END_REG_READ_ID

12

N

Char

Leave this column blank. It is not used.

END_REG_READING

9.6

Y

Number

This is the end quantity.

FINAL_REG_QTY

12.6

Y

Number

This is the final quantity

FINAL_SQI

8

N

Char

The rate quantity identifier of the FINAL_REG_QTY. If specified, it must reference a valid value on CI_SQI. Note, at least one of the following fields should be specified: FINAL_SQI, FINAL_UOM_CD.

FINAL_TOU_CD

8

N

Char

The time-of-use code of the FINAL_REG_QTY. If specified, it must reference a valid value on CI_TOU.

FINAL_UOM_CD

4

N

Char

The unit of measure of the FINAL_REG_QTY. If specified, it must reference a valid value on CI_UOM. Note, at least one of the following fields should be specified: FINAL_SQI, FINAL_UOM_CD.

HOW_TO_USE_FLG

2

Y

Char

See the field description in the data dictionary for the valid values ( CI_BCHG_UP_READ).

MSR_PEAK_QTY_SW

1

Y

Char

Y or N

MSR_QTY

12.6

Y

Number

Quantity. This is the difference between end quantity and start quantity.

REG_CONST

6.6

Y

Number

This is the constant value used to adjust the quantity. Set this to a value of 1 if it is not known.

SQI_CD

8

N

The rate quantity identifier of end quantity and start quantity. If specified, it must reference a valid value on CI_SQI. Note, at least one of the following fields should be specified: SQI_CD, TOU_CD, UOM_CD.

START_READ_DTTM

26

Y

DateTime

This is the date and time of the start quantity.

START_REG_READ_ID

12

Y

Char

Leave this column blank. It is not used.

START_REG_READING

9.6

Y

Number

This is the start quantity

TOU_CD

8

N

Char

The time-of-use code of end quantity and start quantity. If specified, it must reference a valid value on CI_TOU.

UOM_CD

4

Y

Char

The unit of measure of end quantity and start quantity.

USAGE_FLG

2

Y

Char

Leave this column blank. It is not used.

USE_PCT

3

Y

Number

This is the percentage of the quantity that was billed (this will typically be 100).

BCU1 - Validate & Populate Billable Charge Upload Staging

This process populates various fields (e.g., the GL distribution code, memo only switch) on the billable charge upload line records from the billable charge line type specified on each respective record.

Any validation / population errors detected during this process are written to the BC Upload Exception table. You can fix errors using BC Upload Staging page (don't forget to change the record's status back to Pending).

BCU2 - Create Billable Charge

This process creates a billable charge and billable charge lines (shown in the yellow section of the following ERD) for all billable charge upload records in the Pending state.

If the billable charge's obligation is Closed, it will Reactivate it so that the billable charges will be swept onto the next bill produced for the account.

Note:

This process will override the values of the various switches referenced on billable charge upload staging line if the respective obligation's obligation type has an override value for the line's billable charge line type. Refer to Obligation Type - Billable Charge Overrides for more information.

Any errors detected during this process are written to the Billable Charge Upload Exception table. You can fix errors using Billable Charge Upload Staging page and then changing the record's status back to Pending.

BCUP-PRG - Purge Billable Charge Upload Objects

Completed billable charge upload staging objects should be periodically purged from the system by executing the BCUP-PRG background process. This background process allows you to purge all Completed billable charge upload staging objects older than a given number of days.

We want to stress that there is no system constraint as to the number of Completed billable charge upload objects that may exist. You can retain these objects for as long as you desire. However we recommend that you periodically purge Completed billable charge upload objects as they exist only to satisfy auditing and reporting needs.

Billable Charge Upload Staging

The Billable charge Upload Staging page has three purposes:

- You can view historical billable charge upload records.

- You can correct billable charge upload records that are in error.

- You can add new billable charge upload records. These will be uploaded by the billable charge upload process (although it's probably easier to just add the billable charges using the Maintaining Billable Charges page).

The topics in the section describe how to maintain this information.

Next in This Section

- Billable Charge Upload - Main

- Billable Charge Upload - Lines

- Billable Charge Upload - RQ Details

- Billable Charge Upload - Calculation Details

Billable Charge Upload - Main

Open this page using Menu > Billing (Classic) > Billable Charge Upload Staging .

Description of Page

Fastpath:

Refer to Billable Charge Upload Staging for more information about these fields.

Note:

Correcting Errors. If a Billable Charge Upload record's status is Error, you should correct the problem and then change its status back to Pending. The next time the billable charge upload process runs, it will revalidate the record and, if valid, it will create a billable charge record.

Billable Charge Upload - Lines

Open this page using Menu > Billing (Classic) > Billable Charge Upload Staging and navigate to the Line tab.

Description of Page

Fastpath:

Refer to Billable Charge Line Upload Staging for more information about these fields.

Billable Charge Upload - RQ Details

Open this page using Menu > Billing (Classic) > Billable Charge Upload Staging and navigate to the RQ Details tab.

Description of Page

Fastpath:

Refer to Billable Charge Rate Quantity Upload Staging for more information about these fields.

Billable Charge Upload - Calculation Details

Optionally, you may specify calculation details associated with a billable charge. These are most commonly used when you need to print the details that were used to calculate the bill lines that appear on the main tab.

Open Menu > Billing (Classic) > Billable Charge Upload Staging and navigate to the Calculation Details tab to maintain a billable charge's rate quantities.

Description of Page

Fastpath:

Refer to Billable Charge Calculation Details Upload Staging for more information about these fields.

Billable Charge Upload Exception

If errors are detected during the billable charge upload process, a record is written to the billable charge upload exception table with a message indicating the nature of the severe error.

To view the messages associated with the exception records, schedule the TD-BCUPL background process. This process generates a To Do entry for every record in the billable charge upload exception table.

You can fix this error using the Billable Charge Upload Staging page and change the status of the record from Error to Pending. When the billable charge upload process next runs, it attempts to upload this record again.

To Do Processing

There are numerous events that trigger the creation of email-like messages describing work that requires human attention. For example, if a bill segment has an error, a message is created to highlight such. We refer to each message as a To Do Entry. In this section, we describe how to view, manage and work To Do entries.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Next in This Section

- The Big Picture of To Do Processing

- Managing To Do Entries

- How To

The Big Picture of To Do Processing

The topics in this section provide background information on To Do processing functionality.

Next in This Section

- To Do Role

- To Do Priority

- Work Distribution

- A User's Current To Do

- Related To Do Entries

- Complete A To Do

To Do Role

Each To Do entry is assigned a specific To Do Role. The role defines the users who may work on the entry. The permissible roles that may be assigned to a To Do entry are defined on the entry's To Do type. Refer to To Do Entries Reference A Role to learn more about initial role assignment.

After an entry is created, its role may be changed to any role defined as valid for the entry's To Do type. Manual changes of a To Do entry's role are recorded on the To Do entry log.

To Do Priority

A To Do entry is associated with a priority level representing its processing order compared to other entries. Refer to The Priority Of A To Do Entry for more information on how an entry's priority is initially assigned.

A user may manually override a To Do entry's priority at any time. Once overridden, automatic recalculation of the priority is no longer performed so as not to override the value explicitly set by the user. Manual overrides of a To Do entry's priority are recorded on the To Do entry log.

Work Distribution

To Do entries may be manually assigned to users either by their supervisors or picked up by the users themselves. The system can also be configured to dynamically assign the highest priority work to users on demand whenever they are available for fixing errors.

Note: Assignment on demand is in a plug-in. You can customize the next assignment plug-in on the installation options to follow your organization's work distribution rules. For example, when a user asks for the next assignment, business rules may be used to only consider To Do entries the user has the proper skills to resolve, prioritizing them based age, impacted dollar amount, etc.

One of the main benefits of the assignment on demand approach is that work is allocated real-time based on most current information such as skills, priority, user availability, etc. This also means that work remains unassigned until a user is actually going to work on it making it available to any qualified user.

Manual assignments of To Do entries are possible as follows:

- Supervisors may use the supervisor function pages to review and assign To Dos to users.

- A user may use the To Do list pages to review and assign To Dos to themselves or forward any of their To Dos to someone else.

- All of the above assignment functions may also be performed using the To Do Search page.

Assignment "on demand" is possible from the Current To Do zone on the Dashboard portal. Refer to this zone to learn about all the functions it provides.

A User's Current To Do

Users have the option of drilling down on an entry from various list queries in the system. Refer to Working On A To Do Entry for more information on drilling into an entry.

Drilling down on an entry from the following To Do list queries (using the entry's message description only) also sets the entry as the user's Current To Do entry:

- To Do List

- To Do Search

Additionally, users may have the option to click on the Current To Do icon, , on the Current To Do dashboard zone to request their next task. The returned To Do entry automatically becomes the user's Current To Do.

Regardless of how a To Do entry became current its information is displayed on the Current To Do zone.

Fastpath: Refer to Current To Do zone to learn about all the functions it provides to efficiently resolve the current To Do and other entries that may potentially be related to it.

If a To Do entry becomes current as a result of drilling down from a list query, the system supports the ability to drill down to the Next and Previous entries respective to the Current To Do entry in that list.

Note: The Previous To Do button (Alt+Y) and Next To Do button (Alt+Z) in the Current To Do zone allow you to scroll through additional To Do items in your current work list without returning to the list query transaction. These buttons set the respective To Do entry to now being current and take you to its related transaction or to a script associated with the To Do Entry's message (not to the To Do entry itself). This is yet another way of drilling down on an entry.

If a To Do entry becomes current using the Current To Do zone’s next assignment functionality, that entry is not associated with any work list to scroll through. The Next and Previous To Do buttons are therefore disabled in this case.

Note: Current Work List. Current work list refers to the list from which the current To Do entry was selected. Each new election of a current To Do overrides the previous work list with the new list the entry was selected from. If not selected from a list then the current work list is considered empty.

Related To Do Entries

A user working on a To Do may want to know of other To Dos that may be related to the same problem. If can be worked by the same user they may get resolved faster. It seems almost impossible to programmatically determine whether two To Dos really stem from the same problem. The user should therefore be presented with a list of potentially related To Dos from which he/she can select the truly relevant ones.

A To Do entry is considered potentially related to a given To Do if they reference a common entity. For example, if a given To Do references a certain account then any To Do referencing that same account is considered related to it.

Note: The system considers any To Do characteristic of Foreign Key type to represent a reference to an "entity". In other words, if a To Do has at least one common Foreign Key characteristic type / value with a given to do it is considered related to it.

The To Do Search page supports a Related To Do filter that lists all related To Dos for a given entry. Various pages showing To Do information often provide an indication as to how many non-complete entries may be related to a given To Do entry. Clicking on the indication's hyperlink transfers the user to the To Do Search query pre-populating it to list the related entries for the specific To Do entry.

Fastpath: Refer to the To Do Search page for more information on all the functions it supports.

Complete A To Do

After you finish working on an entry, you can mark it as Complete. At this point, you may want to review potentially related To Do entries and complete those that have been addressed by resolving the problem associated with the current entry.

If you cannot resolve the problem, you can forward the To Do to another user, thus assigning the To Do to another user.

Fastpath: Refer to How To Complete To Dos for more information.

Note: It is possible for the system to automatically mark an entry as Complete. Refer to The Lifecycle Of A To Do Entry for more information.

Managing To Do Entries

This section describes the various pages available to view and work on To Do entries.

Next in This Section

- To Do Supervisor Functions

- To Do List Functions

- To Do Entry

- To Do Search

To Do Supervisor Functions

This section describes To Do transactions that aid supervisors in the monitoring and assignment of To Do entries.

Next in This Section

- Supervisor To Do Summary

- Supervisor User Summary

- Supervisor To Do Assignment

Supervisor To Do Summary

This Supervisor To Do Summary page summarizes To Do entries by To Do Type. Only entries that are Open (i.e., not assigned to a specific user) or Being Worked On are summarized.

Note: Only To Do entries that are assigned to a role to which you belong are summarized on this page. Refer to To Do Entries Reference A Role for more information.

Use Menu > To Do > Supervisor To Do Summary to open this page.

Description of Page

This page summarizes all To Do entries that are Open or Being Worked On.

- To Do Type contains the description of the To Do type.

- Priority provides a total count of To Do entries of a given type by priority. For each distinct priority the description includes the priority value followed by the corresponding number of entries. If all entries are of the same priority no additional count is displayed.

- Total contains the total of Open and Being Worked On entries. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Open and Being Worked On entries for the given To Do Type.

- Open contains the number of To Do Entries whose status is Open. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Open entries for the given To Do Type.

- Being Worked On contains the number of To Do entries whose status is Being Worked On. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Being Worked On entries for the given To Do Type.

The "age bars" that appear to the right of the totals highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable.

Supervisor User Summary

The Supervisor User Summary page summarizes To Do entries by the user who is assigned to work on the entries. Only entries that are Being Worked On are summarized.

Note: Only To Do entries that are assigned to a role to which you belong are summarized on this page. Refer to To Do Entries Reference A Role for more information.

Use Menu > To Do > Supervisor User Summary to open this page.

Description of Page

This page contains a grid that displays all assigned To Do entries by User ID and To Do type. It indicates how many To Do entries of the displayed Type are assigned to the user (Assigned this Type) and how many To Do entries in total are assigned to the user (Assigned Total).

Clicking the hyperlinks transfer you to the Supervisor To Do Assignment transaction. On this transaction, you can assign / reassign To Do entries to a specific user. The difference is that clicking the To Do Type hyperlink causes only Open entries to be displayed on the Assignment transaction. Clicking the count in the Assigned this Type column causes Being Worked On entries assigned to the displayed user to be shown.

Supervisor To Do Assignment

This page lists To Do entries of a given type and allows a supervisor to assign / reassign them to a designated user. Use Menu > To Do > Supervisor To Do Assignment to open this page.

Description of Page

This page contains Open or Being Worked On To Do entries of a given type. These entries can be assigned to a specified user one-by-one or several at a time. The following points describe this functionality:

- You can select a different To Do Type by typing in a value or pressing the search button in the upper right corner. An Info description of the To Do type appears on the left.

- You can change the list of entries displayed according to their status. Select the Filter by status to be All (blank), Open, or Being Worked On.

- For Being Worked On entries, you may also Filter by User to limit the search to a specific user assigned to the To Do entries.

- If you want to re-sort the entries by a different value, click the search button adjacent to Extra Information. Each row's respective sort value is displayed in the Extra Information column.

Note: Extra Information. Each To Do list's default Extra Information is defined on the list's To Do Type. Also note that each To Do list's available Extra Information differs.

- Click the Select All button to select all entries displayed in the grid. Click the Clear All to remove the selections in the grid.

- Use the checkbox if you want to assign specific entries.

- Entries are further sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system. Click the Create Date/Time hyperlink to:

- View more detailed information about the entry.

- Add comments to the To Do entry.

- Add a log entry of type User Details to record information about the To Do entry.

- Forward the To Do entry to another user.

- Send Back a To Do entry that was forwarded to you by another user.

- Click the number of Related entries hyperlink to navigate to the To Do Search query to list potentially related entries to the current entry.

- Worked By shows the user currently assigned to the To Do entry.

- To Do Entry Status is the current status of the To Do entry.

- Message contains a description of the To Do entry. Use the message description hyperlink to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

- You can assign entries to a user:

- Enter a user ID or search for a user using the Assign To User field. You can only select a user that is associated with a role that is associated with this To Do Type. Note that the current number of assignments is displayed adjacent.

- Select one or more entries to assign to this user and click the Assign button. The entries' status becomes Being Worked On.

To Do List Functions

This section describes To Do pages that aid users in the assignment and working of entries in To Do lists.

Next in This Section

- To Do Summary

- To Do List

To Do Summary

This page summarizes To Do entries that meet the following qualifications:

- The entry is Open and you belong to the entry's To Do role. Refer to To Do Entries Reference A Role for more information about roles.

- The entry is Being Worked On and you are the user to which it is assigned.

Use Menu > To Do > To Do Summary or press Alt+X to open this page.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Description of Page

This page is dedicated to a grid that summarizes the To Do entries on which you can work. The following information is displayed:

- To Do Type contains the description of the To Do type.

- Priority provides a total count of To Do entries of a given type by priority. For each distinct priority the description includes the priority value followed by the corresponding number of entries. If all entries are of the same priority no additional count is displayed.

- Total contains the total of Open and Assigned to You entries. The hyperlink navigates to the To Do List transaction, setting it to display all Open and Being Worked On entries assigned to you for the given To Do Type.

- Open contains the number of To Do Entries whose status is Open. The hyperlink navigates to the To Do List transaction, setting it to display all Open entries for the given To Do Type.

- Assigned to You contains the number of To Do entries that are assigned to you whose status is Being Worked On. The hyperlink navigates to the Supervisor To Do Assignment transaction, setting it to display all Being Worked On entries for the given To Do Type.

The "age bars" that appear to the right of the totals highlight the age of the To Do entries. The colors red, yellow and green are used to highlight the relative number of old, middle-aged and new To Do entries. The age associated with each of these colors is user-configurable.

To Do List

This page lists To Do entries of a given type that are either Open (e.g., not assigned to a specific user) or are assigned to you.

Note: Restricted by role. Only those entries assigned to a role to which you belong may be seen on this page. Refer to To Do Entries Reference A Role for more information.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Use Menu > To Do > To Do List to open this page.

Description of Page

This page contains a grid that summarizes the To Do entries of a given type on which you can work.

The Info section contains a concatenation of the To Do Type's description and the user's name.

The area beneath Info provides you with options that control which To Do entries appear and the order in which they are displayed. The following points describe the various options:

- Use Sort By to define how you want the To Do entries sorted. The following options are available:

- Assigned Date - On or After. This option sorts the To Do entries in chronological order (based on the date the entry was assigned to you) starting from the input Date. If you choose this option, the system assumes you want to start from the earliest To Do entry. If you want to start from a date other than the earliest To Do entry, enter the desired Date and click the adjacent search button.

- Assigned Date - On or Before. This option sorts the To Do entries in reverse chronological order (based on the date the entry was assigned to you) starting from the input Date. If you choose this option, the system assumes you want to start from the today's date. If you want to start from a date other than today's date, enter the desired Date and click the adjacent search button.

- Create Date - On or After. This option sorts the To Do entries in chronological order (based on the date the entry was created) starting from the input Date. If you choose this option, the system assumes you want to start from the earliest To Do entry. If you want to start from a date other than the earliest To Do entry, enter the desired Date and click the adjacent search button.

- Create Date - On or Before. This option sorts the To Do entries in reverse chronological order (based on the date the entry was created) starting from the input Date. If you choose this option, the system assumes you want to start from the today's date. If you want to start from a date other than today's date, enter the desired Date and click the adjacent search button.

- Extra Information. This option sorts the To Do entries by the value of the Extra Info.

- Use Extra Info to choose data related to the To Do Entry that should be used to sort the To Do entries. This information is displayed in each entry's Extra Information column.

Note: Extra Info. Each To Do list's available Extra Info is defined on the list's To Do Type Sort Keys. Also note that each To Do list's available Extra Info differs based on the configuration of the To Do Type.

- Use Filter by to restrict the To Do entries based on their status. The following options are available:

- All. This option shows all entries that are Open or Being Worked On.

- Being Worked On. This option shows all entries that are Being Worked On (and assigned to you).

- Open. This option shows all entries that are Open.

The grid that follows contains the To Do entries that match your criteria. The following information appears:

- Click the Select All button to select all entries displayed in the grid. Click the Clear All button to remove the selections in the grid.

- Use the checkbox if you want to mark specific entries as Completed or Being Worked On using the Complete or Assign buttons at the bottom.

- A Comments icon appears if there are comments on the To Do item and a Log Entry icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do item. This column appears if at least one To Do has either comments or a special log entry.

- Entries are further sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system.

- Click the Create Date/Time hyperlink or either of the special icons to navigate to the To Do entry page.

- Click the number of Related entries hyperlink to navigate to the To Do Search query to list potentially related entries to the current entry.

- Assigned Date/Time contains the date and time the To Do entry was assigned to a user. This field is only populated on entries that are Being Worked On. If a user assigned the To Do entry, the user ID and name of the user who assigned the To Do entry are displayed beneath the Date/Time.

- Message contains a description of the To Do entry. Use the message description hyperlink to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Note: Current To Do. Drilling into an entry from this page sets it to be the user's current To Do. Refer to A User's Current To Do for more information on how to efficiently scroll through additional entries in your current work list.

CAUTION:

Automatic Assignment! When you drill into an entry using the message description hyperlink from this page, the system changes the status of the entry to Being Worked On and assigns it to you.

- To Do Entry Status is the current status of the To Do entry.

- Extra Information contains the data for the entry that corresponds to the Extra Info chosen in the sort options above.

- To Do ID contains the unique identifier of the To Do entry.

- If you want to mark one or more entries as Being Worked On, check the desired entries and then click the Assign button.

- If you want to mark one or more entries as Completed, check the desired entries and then click the Complete button. Completed entries do not appear on the To Do list (but they are retained on the database for audit purposes).

To Do Entry

The topics in this section describe the pages on which a To Do entry and its associated To Do log are maintained.

Next in This Section

- To Do Entry - Add Dialog

- To Do Entry - Main

- To Do Entry - Keys/Values

- To Do Entry Actions

To Do Entry - Add Dialog

The To Do Entry transaction features a dialog that can add new To Dos (if the system is configured with manual To Do types). This dialog appears if you open the Menu > To Do > To Do Entry > Add (it also appears if you click the clear button when on the To Do Entry page).

Description of Page

The To Do Type is the type of To Do entry that you want to create. Only To Do types that are set up for manual usage appear in the list.

The default To Do Type Priority is displayed adjacent. Use Override Priority to override the default priority assigned by the system.

Type a Subject for your To Do entry. Depending on how the To Do type is set up, the subject may appear as the message in the To Do entry and To Do lists.

Enter a Comment to provide a longer description of and more details about the To Do entry.

Send To indicates whether the new To Do will be assigned to a Role (the default) or User.

The Role indicates the role to which this To Do entry will be assigned. Only users of the specified role will be able to view and work on the To Do entry. The role is defaulted from the To Do type. If you want to assign the To Do to a different role, change the specified role. You can only assign the To Do entry to one of the roles specified on the To Do type.

User appears if Send To is set to User. Use this option if you want to assign the To Do to a specific user. The user must be a member of the selected role.

If the To Do type defines valid characteristic types, the Characteristics collection is visible. If any of the characteristic types are flagged as Default on the To Do type, the characteristic type with its default value (if applicable) are displayed. If applicable use the characteristics to define other information related to this new To Do entry. In Oracle Utilities Customer Care and Billing, for example, you can link the account and premise that you are attempting to start service for.

Click OK to add the To Do Entry.

To Do Entry - Main

You use this page to perform various actions or modify details about a To Do entry. Use Menu > To Do > To Do Entry > Search to open this page.

Note: Restricted by role. You may only change To Do entries that are assigned to you or ones that are Open and assigned to a role to which you belong. Refer to To Do Entries Reference A Role for more information about roles.

Description of Page

To Do contains a concatenation of important information about the To Do entry. To Do ID is the system-assigned unique identifier of the entry. These values only appear after the case is added to the database.

Note: Formatting may be performed by a plug-in. Refer to To Do Info May Be Formatted By An Algorithm for more information.

To Do Type displays the entry's To Do Type and its description. Refer to To Do Entries Reference A To Do Type for more information about To Do types.

Role displays the role of the users who may be assigned to the entry along with a description of the role. Refer to To Do Entries Reference A Role for more information about roles.

Message is a display-only field that describes why the entry exists. If the To Do entry is in the status of Open or Being Worked On, the message description allows you to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Status indicates if the entry is Open, Being Worked On, or Complete. Refer to The Lifecycle Of A To Do Entry for more information status.

Use Priority to manually override the To Do entry's current priority. Any manual change to the priority is recorded on the To Do entry log.

Assigned To displays the user who is working the entry.

Sent By displays the user who assigned this To Do to the current user.

Created By only appears if a background process that uses To Do entries to report object-specific errors created the To Do entry. The field displays the background process description and batch run number in which the entry was created. Refer to To Dos Created for Object-Specific Error Conditions for more information.

Extract Info only appears if the To Do is being sent out of the system. Extract Info describes the status of the extract (for example whether it has been processed or not). Refer to To Do Entries May Be Routed Out Of The System for more information.

Use Comments to describe anything interesting or unusual about the To Do entry. The Comments field is disabled if the To Do entry is complete.

If the To Do entry has non-complete related entries a summary description appears below the comments line. The description states the total number of related entries, how many are still Open, how many are assigned to you and how many assigned to others. Use this hyperlink to navigate to the To Do Search query to list these entries.

The Actions buttons allow you to Complete the To Do, Forward the To Do to another user or Role, or Send Back a To Do that has been forwarded to you by another user. All buttons are disabled once a To Do is complete. Refer to To Do Entry Actions and the How To section for more information on using these actions.

The Characteristics collection is visible for manual To Do entries or for automatic To Do entries that have characteristics. Characteristic Type indicates the type of characteristic. Specify a valid Characteristic Value for the characteristic type.

Note: Only characteristic types defined as permissible on a To Do entry may be linked to a To Do. Refer to Setting Up Characteristic Types & Their Values for more information about characteristic types. In addition, for manual To Do types, the characteristic type must also be defined as valid for the To Do entry's To Do type.

The Log grid displays log entries (in reverse chronological order) that audit the progress of a To Do entry. You cannot modify or delete log entries that have been created by the system. You can manually add a log entry of type User Details and you may remove a log entry before it is saved. Once a User Details log entry is saved, you cannot modify or delete it.

The Log grid displays the following information:

Log Date/Time displays the date and time when the log entry was created.

Log Type indicates the To Do entry event for which the log entry was created. For example, when the To Do entry is created, the Log Type indicates Created. For more information refer to the Log Entry Events table below.

The Details column contains user-specified or system-generated information about the log entry. This field is blank for some types of log entries.

Log User displays the user who caused the log entry to be created.

Assigned To displays the user to whom the To Do entry was assigned (if any).

To Do Entry - Keys/Values

The Keys / Values page contains detailed information about the sort keys and drill keys associated with a To Do entry. This information may not be modified. It is shown to assist support personnel.

Use Menu > To Do > To Do Entry > Search to search for the desired To Do entry, then navigate to the Keys/Values page.

Description of Page

The Sort Keys grid contains an entry's sort keys and values. This information is display-only.

Fastpath: Refer to To Do Type - Sort Keys for more information.

The Drill Keys grid contains an entry's drill keys and values. This information is display-only.

Fastpath: Refer to To Do Type - Drill Keys for more information.

To Do Entry Actions

You can perform the following actions on a To Do Entry.

Next in This Section

- Complete

- Forward

- Send Back

- Log Entry Events

Complete

Clicking Complete causes the To Do entry's status to be Completed. When you complete a To Do, a log entry is created that indicates when the To Do was completed and by whom. This button is enabled for To Do entries with a status of Open or Being Worked On.

Fastpath: Refer to The Lifecycle Of A To Do Entry for more information.

Forward

Clicking Forward causes the Forward To Do Entry dialog to appear, allowing you to forward the To Do to another user or role. This button is enabled for Open To Do entries assigned to a role to which you belong or Being Worked On To Do entries assigned to you.

Send To indicates whether the To Do will be forwarded to a Role or User (the default).

User appears if Send To is set to User. The User indicates the user to which this To Do entry will be forwarded. The user must be a member of one of the roles specified for the To Do type.

Role is enabled if Send To is set to Role or if set to User and a User is specified. It indicates the role to which this To Do entry will be forwarded. Only users of the specified role will be able to view and work on the To Do entry. The role is defaulted from the To Do type. You can only forward the To Do entry to one of the roles specified on the To Do type. If forwarding to a user the role must also be valid for the specified user.

The Details field provides an explanation of why a user is forwarding the To Do. This information appears in the To Do log.

Click OK to forward the To Do entry.

Send Back

Clicking Send Back causes the Send Back To Do Entry dialog to appear, allowing you to send back the To Do to the user who forwarded it to you. This button is enabled if the To Do entry's status is Being Worked On and it was forwarded to you by another user.

User is a display only field that indicates the user who assigned you the To Do.

Role may be used to also change the entry's To Do Role. The role must be a permissible role specified on the To Do type that is also valid for the user this entry is sent back to. By default, if the sent to user is not a member of the entry's current role, the system automatically defaults the role to the first permissible role that is also valid for the user.

The Details field provides an explanation of a why the user is sending back the To Do or any other desired information. This information appears in the To Do log.

Click OK to send the To Do back to the assigning user.

Log Entry Events

The following table contains the events that cause a log entry to be created by the system.

Event

Log Type

To Do Entry Status

Content of Details

Content of Assigned To (on To Do entry and To Do Log)

Log User ID

Contents of Sent By (on To Do entry)

A To Do is created (by the system or by a user)

Created

Open

ID of user who created the To Do

A To Do is created (by the system or by a user) in Being Worked On status

Created

Being Worked On

User ID of user who was assigned this To Do

ID of user who created the To Do

Creating user's ID

A To Do is completed (by the system or by a user)

Completed

Complete

ID of user who completed the To Do

A user takes an open To Do

Assigned

Being Worked On

Selected by user

Assigned To User ID

Assigned To User ID

ID of user who assigned the To Do

A supervisor assigns a To Do to a user (also happens if they reassign)

Assigned

Being Worked On

Assigned to user

Assigned To User ID

ID of user who assigned the To Do

ID of user who assigned the To Do

A user forwards an entry to a user

Forwarded

Being Worked On

Log details entered by user

Forwarded To User ID

ID of user who forwarded the To Do

ID of user who forwarded the To Do

A user forwards an entry to a role

Forwarded

Open

Forwarded to role Role Description (Role ID) + Log details entered by user

ID of user who forwarded the To Do

ID of user who forwarded the To Do

A user sends back a To Do

Sent back

Being Worked On

Log details entered by user

Sent Back To User ID

ID of user who sent back the To Do

ID of user who sent back the To Do

A user adds a log entry

User Details

Status remains the same

Log details entered by user

ID of user who added the entry

A user manually overrides priority

Override Priority

Status remains the same

Priority changed from < old value> to < new value>

Assigned To User ID

ID of user who made the change

To Do Search

This page allows you to search for To Do entries using various search criteria, and perform various actions on selected ones.

Note: No restriction by role. This page returns all To Do entries that meet the search criteria, regardless of the To Do entry's role. Using the search, a user may drill into the details of a To Do entry even if the To Do is not assigned to the user. Refer to To Do Entries Reference A Role for more information about roles.

Fastpath: We recommend familiarizing yourself with the topics described in The Big Picture of To Do Lists to fully appreciate how To Do entries are managed by the system.

Next in This Section

- To Do Search - Main

- To Do Search Actions

To Do Search - Main

Use Menu > To Do > To Do Search to open this page.

The top half of the page is where you enter the criteria used to search for To Do entries.

Note: Multiple search criteria may be specified. You can search for To Do entries using a combination of search criteria. For example, if you enter both a To Do Type of TD-NOMR and a Status of Being Worked On, only those To Do entries for To Do type TD-NOMR that are currently Being Worked On are displayed.

CAUTION:

Try to be as specific as possible when entering search criteria. Why? Because entering open-ended search criteria may have a severe impact on response times.

The following table describes each of the different search filters.

Search Filter

Description

Related To Do

If you're searching for potentially related entries for a given To Do entry, choose Specific To Do for the Related To Do Filter. Enter the To Do ID.

A filter value of Not Applicable defaults.

To Do Type

If you're searching for a To Do entry and you know the value of a To Do Type linked to the To Do entry, choose Specific To Do Type for the To Do Type Filter. Enter the To Do Type.

A filter value of All defaults.

Char Type

If you're searching for a To Do entry and you know the value of a characteristic linked to the To Do entry, choose Specific Char Type for the Char Type Filter. Enter the Characteristic Type and Characteristic Value.

A filter value of Not Applicable defaults.

Only characteristic types that include a characteristic entity of To Do Entry and that have been marked to allow searching by characteristic value are available.

User

Use this search method if you know the Created By User, Assigned To User or Completed By User for the To Do entry. Enter the appropriate User Id.

A filter value of Not Applicable defaults.

Date Range

Use this field if you're searching for a To Do entry and know the Date Created or Date Completed.

A filter value of Date Created defaults. The Start Date/Time defaults to the current date, 12:00AM and the End Date/Time defaults to the current date, 11:59PM.

If you enter a Date Range Filter of All, the system ignores this search method.

Status

Use this search method to restrict the search to To Do entries with a specific status value. You may search for To Do entries in the status of Open, Being Worked On or Completed. You may also perform a combination search for To Do entries that have a status value of either Open or Being Worked On.

A filter value of All defaults.

Note: The system allows any combination of values. The system does not try to validate your search combinations, even if they do not make sense. For example, if you enter a User Filter value of Completed By User and a Status Filter value of Open, you will not get an error. In this case, the system will find no records that match your criteria (because To Do entries that are Open do not have a Completed By User).

The system shows the total number of To Do entries that satisfy your search results immediately below the grid.

The first group of To Do entries is displayed in the grid at the bottom of the page.

- Click the Select All button to select all entries displayed in the grid. Click the Clear All to remove the selections in the grid.

- Use the checkbox if you want to assign, reopen or complete specific entries. Only Open or Being Worked On entries may be selected.

Fastpath: Refer to To Do Search Actions and the How To section for more information on using these actions.

- A Comment icon appears if there are comments on the To Do item and a Log Entry icon appears if there is a log entry of type Forwarded, Sent Back or User Details on the To Do item. This column appears if at least one To Do item has either comments or a special log entry. Use either icon to navigate to the To Do entry page.

- Entries are sorted by their Priority. Highest in priority are listed first.

- Create Date/Time contains the date and time the To Do entry was created by the system. Use the hyperlink to navigate to the To Do entry page.

- Click the number of Related entries hyperlink to redisplay this page listing potentially related entries to the current entry.

- Last Assigned Date/Time contains the date and time the To Do entry was most recently assigned to a user, if applicable, along with the Assigned To user.

- Message contains a description of the To Do entry. If the To Do entry is in the status of Open or Being Worked On, the message description allows you to drill into the page on which the entry's respective object is displayed. If the To Do type has been configured to associate a script with this To Do entry's message number, then instead of being taken to the respective page, the associated script is launched. Refer to Working On A To Do Entry for more information.

Note: Current To Do. Drilling into the page by clicking the Message hyperlink does not automatically assign Open To Do entries to the user (as the To Do List page does when clicking on the Message). But it does treat this as the user's current to do, enabling To Do related toolbar icons. Refer to A User's Current To Do for more information.

- Status contains the current status of the To Do entry.

- Completion Date/Time contains the date and time the To Do entry was completed and the user who completed the entry, if applicable.

- To Do Type contains a description of the To Do type for the To Do entry.

To Do Search Actions

You can perform the following actions on selected To Do Entries.

Next in This Section

- Assign Selected Entries

- Reopen Selected Entries

- Complete Selected Entries

Assign Selected Entries

Use the Assign button to assign or reassign the selected entries to a user. Enter a user ID or search for a user using the Assign To User field. By default this field is populated with the current user's ID. Note that the user's current number of assignments is displayed adjacent.

Upon successful processing, the selected entries are assigned to the specified user and the status of Open entries becomes Being Worked On. Additionally, a corresponding log entry is added to each To Do.

Note: Only users with Supervisor Assignment access rights may reassign entries that are not currently assigned to them.

Reopen Selected Entries

Use the Reopen button to unassign the selected entries from their users forwarding them back to their role.

Upon successful processing, the selected entries become Open and a corresponding log entry is added to each To Do.

Complete Selected Entries

Use the Complete button to complete the selected entries.

Upon successful processing, the selected entries become Completed and a corresponding log entry is added to each To Do.

Fastpath: Refer to The Lifecycle Of A To Do Entry for more information.

How To

The following sections describe how to perform common tasks for To Dos.

Next in This Section

- How To Assign a To Do to a User

- How To Work on To Do Entries

- How To Add a New To Do

- How To Complete To Dos

- How To Forward a To Do

- How To Send Back a To Do

- How To Add a Log Entry to a To Do

How To Assign a To Do to a User

There are several ways to assign a To Do entry to a user:

- A supervisor can use the Supervisor Functions pages to review, assign and reassign To Dos to users.

- The Supervisor To Do Summary page summarizes by type the total, Open (unassigned) and Being Worked On (assigned) entries for roles to which you belong.

- The Total, Open or Being Worked On column hyperlinks transfers you to the Supervisor To Do Assignment page where you can assign / reassign one or more of the corresponding entries to a specific user.

- Use the To Do List Functions pages to review and assign To Dos to yourself.

- The To Do Summary page summarizes by type the total, Open (unassigned) and Being Worked On (assigned to you) entries for roles to which you belong.

- The Open column hyperlink transfers you to the To Do List page where you can assign one or more of the Open entries to yourself.

- You may also use the To Do Search page to find certain To Do entries based on various criteria and assign selected entries to a user.

- Forwarding an entry to a user using the To Do Entry page is yet another way of assigning an entry to a user.

- The Current To Do zone next assignment functionality can be configured to dynamically assign an Open To Do to the requesting user based on your organization's work assignment rules. Refer to this zone for more information.

How To Work on To Do Entries

Depending on your organization's work distribution practice, there are several ways to work on To Do entries.

When work is manually assigned, a typical approach may be to review the entries in a list and work them one entry at a time.

- You can use the To Do List page to review and work on To Do entries by list type.

- You may also use the To Do Search page to find certain To Do entries based on various criteria and work on selected entries. For example, you may want to review and work on entries related to a given To Do.

Regardless of the above methods to define your work list, when ready to work on a specific entry, drill into its respective page using the message description hyperlink. Drilling into an entry from the above work lists makes it your current To Do entry. This entry's key information is displayed on the Current To Do dashboard zone and you may use special action bar buttons to scroll through your work list to the next and previous entries respective to your current To Do.

Fastpath: Refer to Working On A To Do Entry for more information.

When work is assigned "on demand", click the Current To Do icon, , on the Current To Do dashboard zone to request your next task. The returned To Do entry automatically becomes your current To Do. The entry's key information is displayed on the zone but since the entry was no selected from a work list the next and previous action bar buttons are disabled.

Fastpath: Refer to Current To Do zone to learn about all the functions it provides to efficiently resolve the current To Do and potentially other To Do entries that may be related to it.

Resolve the current To Do by fixing the problem indicated in the message and mark the entry as Complete.

Fastpath: Refer to How To Complete To Dos for more information.

How To Add a New To Do

If your system is configured with manual To Do types, you can add a To Do entry online. Online To Do entries may be used like electronic help tickets in the system. In Oracle Utilities Customer Care and Billing, for example, if you are having a problem starting service, you can create a To Do that describes the problem. The To Do can be assigned to a help resolution group that could either resolve the problem or send the To Do back to you with information describing how to resolve the problem.

Fastpath: Refer to To Do Entry - Add Dialog for more information.

How To Complete To Dos

When you complete a To Do, a log entry is added that indicates when the To Do was completed and by whom.

There are multiple ways in which you can complete a To Do.

- The To Do List page allows you to complete one or more selected entries of a specific To Do Type.

- The To Do Search page allows you to search for To Do entries using various search criteria and complete selected ones.

- Use the To Do Entry page to complete a single To Do Entry.

- You may also use the Current To Do zone to complete the current entry you are working on and/or all related entries assigned to you.

- The system automatically completes some To Do entries. For To Do entries that are logically associated with the state of some object, the system automatically marks the entry Complete when the object is no longer in the respective state. In Oracle Utilities Customer Care and Billing for example, an entry that's created when an account doesn't have a bill cycle is completed when the account has a bill cycle.

Note: The automatic completion of To Do entries occurs when the To Do entry process responsible for creating entries of a given type is executed. Therefore, if these processes run only once per day, these entries remain Being Worked On even if the object is no longer in the respective state.

How To Forward a To Do

If you have been assigned a To Do that you are unable to resolve, you can forward it to another user or role for help or additional instructions. When a To Do is forwarded, a log entry indicates who forwarded the To Do, to whom it was forwarded, and the specified reason.

- Use the Forward button on the To Do Entry page to forward a To Do entry to a role or a user.

- You may also use the Reopen button on the To Do Search page to forward selected entries back to their current role.

How To Send Back a To Do

If you have been forwarded a To Do by another user, you may send back the To Do with instructions to the forwarding user. When a To Do is sent back, a log entry is created that indicates when the To Do was sent back and by whom.

Use the Send Back button on the To Do Entry page to send back a To Do entry.

How To Add a Log Entry to a To Do

You can use the Comments section of a To Do entry to add a comment to the To Do as long as the To Do is Open or Being Worked On. However, the Comments field is disabled if the To Do entry is complete.

Alternatively, you can add a User Details log entry to a To Do at any time (even after it's completed). Refer to To Do Entry page for more information.

Reports

The following section describes the functionality provided for submitting reports on-line and for viewing reports submitted through a scheduler.

Fastpath: For information about this functionality, see The Big Picture of Reports.

Next in This Section

- On-line Report Submission

- Viewing Historic Reports

On-line Report Submission

The on-line report submission page enables you to request a specific report to be run. This is only available if your system is able to integrate with your third party reporting system on-line. The system comes configured to integrate with BI Publisher and Business Objects Enterprise.

Next in This Section

- Report Submission - Main

Report Submission - Main

This page allows you to submit a report on-line. Navigate to this page using Menu > Batch > Report Submission..

Description of Page

To submit a report, choose the Report Code for the process you wish to submit. Refer to Defining Report Definitions for information about defining reports in the system.

A description of the report is displayed.

The parameters defined for the report on the report definition page are displayed in the grid. To see a description of a parameter, use the search button adjacent to the parameter label.

Note: Default note. The default values displayed for the parameters are defined on the report definition page.

When you have entered the appropriate parameter values, click the Submit button to submit the report. Refer to How To Request Reports for more information.

Note: Reports submitted via the on-line report submission page are NOT logged in the report history repository and are therefore not visible from the report history page. Only reports submitted through your third party reporting tool's batch scheduler are logged in the report history.

Viewing Historic Reports

If your third party reporting tool stores historic copies of reports in a repository, you may configure the system to allow a user to view these historic reports on-line.

Note: The system comes with the ability to display reports stored in the Business Objects Enterprise report repository. Only reports scheduled through Business Objects Enterprise's batch schedule are stored in the repository.

Next in This Section

- Report History - Main

Report History - Main

This page allows you to view a report stored in your third party reporting tool's report repository. Navigate to this page using Menu > Batch > Report History.

Description of Page

The top part of the page shows the Report Code, Description and Long Description for the selected report.

To select a report, search by either Report Code or Description and click the adjacent search button. The reports matching your search criteria are displayed. Choose the desired report from the selection list.

Note: Displaying Report History. When you choose a report, the system interfaces with your reporting software to display a list of historical occurrences of this report. Refer to Interface with Business Objects Enterprise's Batch Scheduler for more information.

Table of Contents

Cover Page

Legal Notices

PSRM Business User Guide

User Interface Standard Features

System-Wide Standards

Page Components

Characteristics Common to All Pages

The Application Toolbar

Home Button

Menu Button

Admin Button

Back Button

History Button

Forward Button

About Button

User Menu

Preferences

Logout

Help Button

Page Title Area

Page Actions Toolbar

Bookmark Button

Next/Previous Item Buttons

Duplicate Button

Delete Button

Clear Button

Save Button

Refresh Button

Object Display Area

Text Box

Date Only Field

Date and Time Field

Search Button

Context Menu Button

Go To Button

Broadcast Button

Work Lists

Scroll Bars with Dynamic Height

Sorting Functionality

Get More Functionality

Adding and Removing Rows Using Arrows

Reorganizing Items Using the Up and Down Arrows

Trees

Required Field Indicators

Accordion Windows

Row Summary and Chunk Management

Dashboard Area

Script Area

Maintenance Pages

The Unique Identifier Area

Confirmation & Error Messages

Warning If Unsaved Changes Messages Exist

Query Pages

The Search Area

Portal Pages

Portals Are Made Up Of Zones

Each User Can Customize Which Zones Appear

Users Must Be Granted Security Access To Each Zone

Zones May Appear Collapsed When A Page Opens

Dashboard Portal

Bookmarks Zone

Current To Do Zone

Favorite Links Zone

Favorite Scripts Zone

Favorite Searches Zone

Switch Language Zone

To Do Summary Zone

Work List Zone

User Preferences

User - Main

User - To Do Roles

User - Access Security

User - Bookmarks

User - Portal Preferences

User - Favorite Links

User - Favorite Scripts

User - Characteristics

User - User Portal

Initiating Scripts

Accelerator Key Summary

Portal and Zone Features

Zone Types and Characteristics

Explorer Zones

Search Criteria / Filter Area

Description Bar

Results Area

Title Bar

Explorer Zone Menu

Clear Filters

Export to Excel

Print

Reset Zone

Save Search Options

Save As

Open Saved Search

Save

Set As Default

Remove As Default

Add To Favorites

Remove From Favorites

Delete

Show Filters

Show Column Configuration Area

The Open Zone Maintenance Icon

Configurable Columns

Multi-Query Zones

Map Zones

Open Map Maintenance Icon

Common Characteristics of Zones

Zone Visibility

Control Zone Headers

Common Base Portals and Zones

All-In-One Portal

List Zone

Separate Query and Maintenance Portals

Query Portal Search Zone

Zones Common to Maintenance Portals

Object Display Zone

Log Zone

Taxpayer Information

Understanding the Account Model

Persons

Accounts

Tax Roles

Obligations

Assets

Addresses

360 Degree Search and View

360 Degree Search

360 Degree View

360 Degree View - Main

360 Degree View - Account

Timeline Zone

360 Degree View - Tax Role

Timeline Zone

360 Degree View - Financial

Credit Allocation Detail Zone

Dashboard Portal

Current Context Zone

Customer Contact Zone

Financial Information Zone

Alert Zone

Maintaining The Account Model

Maintaining Persons

Person Query

Person Portal

Person - Main Information

Person - Relationships

Maintaining Accounts

Account - Main Information

Account - Auto Pay

Account - Person Information

Account - Bill Messages

Account - Collections

How are compliance rating transactions created?

How is compliance rating calculated?

What impact does compliance rating have in the system?

Account - Characteristics

Account - Alerts

Maintaining Direct Debit Mandates

Account's Direct Debit Mandates Portal

Direct Debit Mandate Portal

Direct Debit Mandate - Main

Direct Debit Mandate - Log

Using The Account / Person Replicator

Information Replicated for New Persons

Information Replicated for New Accounts

Maintaining Tax Roles

Tax Role Query

Tax Role Portal

Tax Role - Main

Tax Role - Log

Maintaining Obligations

Obligation - Main Information

Obligation - Rate Info

Obligation - Chars, Qty & Rec. Charges

Obligation - Recurring Charges

Obligation - Miscellaneous

Maintaining Addresses

Address Query

Address Portal

Address - Main Information

Address - Relationships

Address - Log

The Big Picture Of Customer Contacts

Customer Contacts Are Associated With Persons

How Customer Contacts Are Created

Customer Contacts Are Used To Trigger Letters

A Customer Contact May Trigger Reminders

Maintaining Customer Contacts

Customer Contact - Main

Customer Contact - Log

Customer Contact - Characteristics

Reprinting Letters

Appendix A - Legacy Functionality

Navigating The Account Model Using Control Central

Control Central - Main

Search Facilities

Search Options

Wild Cards

Search Results

Control Central - Account Information

Account Financial History Zone

Alert Zone

Bill Graph Zone

Context Zone

Credit Allocation Detail Zone - Account

Compliance Information Zone

Taxpayer Information Zone

Financial Information Zone

Location Information Zone

Timeline Zone

Control Central - Taxpayer Information

Person Tree Zone

Active Account Summary Zone

Credit Allocation Detail Zone - Taxpayer Info

Timeline Zone

Control Central - Account Tree

Control Central - Location Tree

Control Central - Bill/Payment Tree

How To Add A New Taxpayer From Control Central

Maintaining Persons (Legacy)

Person - Main Information

Person - Correspondence Information

Person - Characteristics

Person - Persons

Person - Web Self Service

Person - Miscellaneous

Maintaining Locations

Location - Main Information

Location - Characteristics

Location - Geographic Data

Location - Alternate Address

Additional Location Management Tools

Using The Location Replicator

Location Replicator - Main

Location Replicator - Location

Location Management

Define Location Hierarchy

Manage Groups of Locations

Location Management Page

Setting Up Bill Print Groups

Bill Print Group - Main

Bill Print Group - Obligation Sub Group

Forms Processing

Understanding Forms

About Registration Forms

About Tax Forms

Validating Forms

About Suspended Forms

Forms May Wait for Information

About Form Versions

About Uploading Forms

Form Batch Header Details

Form Upload Staging Details

About Processing Batches of Forms

Form Control Overview

Maintaining Registration Forms

Registration Form Query

Registration Form Portal

Registration Form - Main

Registration Form - Exceptions

Registration Form - Versions

Registration Form - Log

Common Registration Form Procedures

Manually Adding Registration Forms

Correcting Suspended Registration Forms

Re-editing Registration Forms

Manually Posting a Valid Registration Form

Canceling Registration Forms

Maintaining Tax Forms

Tax Form Query

Tax Form Portal

Tax Form - Main

Tax Form - Exceptions

Tax Form - Versions

Tax Form - Log

Common Tax Form Procedures

Manually Adding Tax Forms

Correcting Suspended Tax Forms

Re-editing Tax Forms

Manually Posting a Valid Tax Form

Canceling Tax Forms

Adjusting Tax Forms

Changing the Receive Date

Transferring Tax Forms

Reversing Tax Forms

Auditing Tax Forms

Maintaining Form Batch Headers

Form Batch Header Query

Form Batch Header Portal

Adding Form Batch Headers

Validating Form Batch Headers

Correcting Suspended Form Batch Headers

Canceling Batches of Forms

Reviewing Batches Where Records Were Rejected

Maintaining Form Upload Staging

Form Upload Staging Query

Form Upload Staging Portal

Forms Upload Staging - Main

Forms Upload Staging - Log

Adding Form Upload Staging Records

Validating Form Upload Staging Records

Correcting Suspended Form Upload Staging Records

Canceling Forms Upload Staging Records

Maintaining Form Controls

Form Control Query

Form Control Portal

Form Control - Main

Form Control - Log

Common Form Control Procedures

Asset

Understanding Assets

About Assets

About Valuation

About Valuation Upload

Maintaining Assets

Asset Query

Asset Portal

Asset- Main

Asset - Ownership

Asset - History

Asset - Log

Maintaining Valuations

Valuation Portal

Valuation - Main

Valuation - Log

Valuation Errors Query

Penalty and Interest

Background Topics

Dynamic Credit Allocation

Bringing Penalty and Interest Up to Date

Forecasting Penalty and Interest

Waiving Penalty and Interest

Waiver Type

Creating and Activating a Waiver

Canceling a Waiver

Waiver Log Information

Detailed P&I View

Maintaining Waivers

Waiver Query

Waiver Portal

Billing

Maintaining Bills

Bill Query

Billing Portal

Bill - Log

Common Bill Procedures

Manually Adding A Bill

Canceling Bills

Overriding Due Dates

Maintaining Batch Control

Payments

The Big Picture of Payments

A Payment Event Has Payments And Tenders

Multiple Tenders Used To Pay For Multiple Accounts

An Overview Of The Payment Event Creation & Allocation Process

Payments and Penalty and Interest

Payment Date and Effective Date for Payment Events

Distributing A Payment Event

Distributing A Payment Amongst An Account's Obligations

Overpayment

Canceling A Tender Versus Canceling A Payment

NSF Cancellations

Transferring A Payment

Unbalanced Payment Events

Tender Management and Workstation Cashiering

Managing Your Cash Drawers

Turn Ins

Balancing By Tender Type

Cash Back

Managing Payments Interfaced From External Sources

Exceptions

Payment Exceptions

Payment Event Exceptions

Resolving Exceptions Automatically

Payment Financial Transaction Considerations

Payment - Current Balance versus Payoff Balance

The Source Of GL Accounts On A Payment Financial Transaction

A Payment May Affect More Than Just Taxpayer Balances

Open Item Accounting and Match Events

FT Freeze Repercussions

Automatic Payments

How To Set Up A Taxpayer To Pay Automatically

What Are Automatic Payments?

How And When Are Automatic Payments Created?

Determining Bank Details

Automatic Payment Dates

How To Implement Maximum Withdrawal Limits

How Are Automatic Payments Cancelled?

Match Events Are Created For Open-Item Customers When An Automatic Payment Is Created

Pay Plans and Automatic Payment

Issuing A Payment Advice Instead Of Creating An Automatic Payment

How To Set Up A Taxpayer To Receive Payment Advices

Payment Advice Option Is For Bill-Related Automatic Payments Only

Maintaining Payment Events

Payment Lifecycles

Payment Event Lifecycle

Tender Lifecycle

Payment Lifecycle

Payment Event - Add Dialog

Payment Event - Main Information

Payment Event - Tenders

Payment Event Action Codes

Payment Actions

Distribute (Payments)

Redistribute (Payments)

Print

Freeze (Payments)

Payment Event Actions

Transfer

Delete A Payment Event

Tender Actions

Cancel A Tender

Payment Event QuickAdd

Multiple Payment Events Dialog

Single Payment Event Dialog

Payment QuickAdd

Maintaining Payments

Payment - Main

Payment - Pay Segments

Payment - Manual Distribution

Payment - Characteristics

Payment Action Codes

Distribute (A Payment)

Redistribute (A Payment)

Freeze (A Payment)

Cancel (A Payment)

Transfer (A Payment)

Transfer Payment (No Distribution Details Exist)

Transfer Payment (Distribution Details Exist)

Delete (A Payment)

How To

How To Add A New Payment Event

How To Cash A Check

How To Allocate The Tender Amount To Multiple Accounts

How To Print Receipts And Endorsements

How To Cancel A Tender

How To Transfer A Payment From One Account To Another

How To Distribute A Payment To A Specific obligation

How To Get An Unbalanced Tender Control In Balance (Fixing Over/Under)

Financial Transactions On A Payment

Payment History

Payment / Tender Search

Payment Event Exception

Payment Exception

Maintaining Deposit Controls

The Lifecycle Of A Deposit Control

Deposit Control - Main

Deposit Control - Tender Control

Deposit Control - Tender Deposit

Deposit Control - Turn Ins

Maintaining Tender Controls

The Lifecycle Of A Tender Control

Tender Control - Main

Tender Control - Tenders

Tender Control - Turn Ins

Tender Control - Exceptions

Tender Control - Characteristics

Interfacing Payments From External Sources

Interfacing Payments Using Distribution Rules

Payment Event Upload

Payment Event Upload Overview

Process X - Populate Payment Event Upload Staging

The Lifecycle of a Payment Event Upload Staging Record

Process C1-PEPL0 - Upload Payments (Step 1)

Process C1-PEPL1 - Upload Payments (Step 2)

Process C1-PEPL2 - Upload Payments (Step 3)

Process C1-PEPL3 - Upload Payments (Step 4)

To Do Entries for Exceptions

Payment Event Upload Staging Maintenance

Payment Event Upload Staging - Main

Payment Event Upload Staging - Characteristics

Interfacing Payments Using Account Distribution

Populating The Payment Upload Staging Records

Process X - Populate Payment Upload Staging

Process PUPL - Upload Payments

PYUP-PRG - Purge Payment Upload Objects

Maintaining Deposit Control Staging

Deposit Control Staging - Main

Deposit Control Staging - Tender Control Staging

Payment Upload Staging

Payment Upload Staging - Tender Detail

Payment Upload Staging - Payment Advice

Payment Upload Exception

Adjustments

The Big Picture Of Adjustments

Adjustments - Current Balance versus Payoff Balance

When Current Balance Equals Payoff Balance

When Current Balance Differs From Payoff Balance

Adjustment Type And Balances

The Lifecycle Of An Adjustment

Transfer Adjustments

Adjustments and Penalty and Interest

Adjustment Amount

Adjustment Type Controls Everything

Adjustment Approval

Accounts Payable

An Adjustment May Affect More Than Just Taxpayer Balances

Maintaining Adjustments

Adjustment Query

Adjustment Portal

Adjustment - Main

Adjustment - Log

Multiple Miscellaneous Adjustments

Multiple P&I Adjustments

How and When To Use An Adjustment

How To Create A Transfer Adjustment

How To Create A Generated Adjustment

How To Cancel An A/P Adjustment After It Has Been Selected By A/P

How To Use An Adjustment To Change The GL Distribution

Maintaining Adjustments Interfaced From External Sources

Maintaining Adjustment Staging Control

Maintaining Adjustment Upload Staging

Maintaining Adjustments (Legacy)

Adjustments - Main Information

Adjustments - Characteristics

Adjustments - Transfer Adjustment

Adjustments - A/P Request

Adjustments - Approval

Financial - Adjustment Calculation Line Characteristics

Financial Transactions

The Big Picture Of Financial Transactions

Bill Segment Financial Transactions

Payment Segment Financial Transactions

Adjustment Financial Transactions

Financial Transactions And Effective Date

Current Balance versus Payoff Balance

Adjustments - Current Balance versus Payoff Balance

Billing - Current Balance versus Payoff Balance

Payment - Current Balance versus Payoff Balance

The Source Of GL Accounts On Financial Transactions

Obscure Things That Can Happen

A Stopped Obligation May Be Closed

A Closed Obligation May Be Reactivated

A Reactivated Obligation May Be Closed

One Or More Algorithms May Be Executed

Financial Transaction

Financial Transaction - Main

Financial Transaction - FT Process

Financial Transaction - Characteristics

Account Financial History

Account Bill / Payment History

Obligation Financial History

Obligation Cash Accounting Balance

Balance Control

Match Event

Match Event - Main

Match Event - FT Details

Match Event - Subtotals

How To Perform Common Match Event Functions

How To Find The Match Event Associated With A Financial Transaction

How To Dispute An Item

How To Match A Small Mismatch

Overpayment Processing

Overpayment Overview

Maintaining Overpayment Processes

Overpayment Process Query

Overpayment Process Portal

Overpayment Process - Main

Overpayment Process - Log

Common Overpayment Procedures

Refund Control Overview

Maintaining Refund Controls

Refund Control Query

Refund Control Portal

Refund Control Main

Refund Control - Log

Common Refund Control Procedures

Bank Event

Understanding Bank Events

About Bank Events

Creating Bank Events

Maintaining Bank Events

Bank Event Query

Bank Event Portal

Bank Event - Main

Bank Event- Log

Rates

All Rates Share A Common Structure

How To Create A New Rate

Control Tables That Must Be Set Up Before Creating A Rate Schedule

Defining Frequency Codes

Setting Up Rate Quantity (RQ) Rules

Base Package RQ Rules

Defining Rate Quantity (RQ) Identifiers

Setting Up Unit Of Measure Codes

Setting Up Time-Of-Use Codes

Setting Up A Rate Schedule

Rate Schedule - Main

Rate Schedule - RQ Rules

Rate Schedule - Bill Messages

Rate Schedule Merge

Removing A Row

Adding A New Row

Removing An Uncommitted Row

Moving Rows Up and Down

Setting Up Rate Factors

An Overview Of Rate factors

The Structure Of A Rate Factor

An Illustration Of A Rate Factor And Its Characteristics

Deriving / Passing In Characteristic Values

Defining Rate Factors

Defining General Rate Factor Information

Setting Up Rate Factor Characteristics

Defining Rate Factor Values

Rate Factor Value - Main

Rate Factor Value - GL Distribution

Defining Rate Versions

Lifecycle of a Rate Version

Rate Version - Main

Rate Version - Bill Print Info

How To Use Description on Bill

Designing Rate Components

Rate Component Design Methodology

Rate Component Rounding

Rounding Precision Is Defined On A Rate Component

Rounding Method Is Defined On A Rate Component

Rounding And FCPO Rate Components

Interim Rounding For Apply To Rate Components

Rounding At The End

The Big Picture Of Rate Component Eligibility Rules

A Rate Component Is Eligible By Default

Criteria Groups versus Eligibility Criteria

Defining Logical Criteria

Examples Of Rate Component Eligibility Rules

A Rate Component With A Time Span Comparison

A Rate Component With Tax Type Comparison

Defining Rate Components

Rate Component - Main Information

How To

How To Set Up Flat Charge Rate Components

How To Set Up Rate Quantity Rate Components

How To Set Up Apply To Rate Components

How To Set Up Maximum Charge Rate Components

How To Set Up Minimum Charge Rate Components

How To Set Up Exact Charge Rate Components

How To Set Up Summary Rate Components

How To Set Up Calculation Algorithm Rate Components

Rate Component - Cross Reference

Rate Component - GL Distribution

Rate Component - Characteristics

Rate Component - Eligibility

Rate Version Merge

Resequencing Rate Components

Removing A Row From A Grid

Adding A New Row To A Rate

Removing An Uncommitted Row From A Rate

Moving Positional Rows Up and Down

Rate Component Cross Reference Information

Rate Check

Rate Check - Main

Rate Check Results - Calc Lines

Rate Check Results - RQ Details

Rate Check Results - Calculation Details

Rate Check Results - Characteristics

Effective Dates & Proration

Types of Proration

Rate Calculation Period Proration

Rate Factor Proration

An Obligation Rate Changes Are Not Prorated

Proration Factors

Normal Days

Calculation Period Factor

RF Value Period Factor

Overriding Proration Factors

Rate Quantity Proration

Step Proration

Step Multipliers

Rate Component Value Proration

Rate Factor Value Proration

How To Add A New Rate Quantity Rule Algorithm

Bankruptcy

Understanding Bankruptcy

About Bankruptcies

Alerts

A Person's Other Bankruptcies Are Highlighted

Maintaining Bankruptcies

Bankruptcy Query

Bankruptcy Portal

Bankruptcy - Main

Bankruptcy - Log

Creating Proofs Of Claim

Creating Pay Plans

Audit Case

Understanding Audit Case

About Audit Cases

Alerts

Maintaining Audit Cases

Audit Case Query

Audit Case Portal

Audit Case - Main

Audit Case - Log

Sending Letters

Creating Audit Case Reviews

Appeal

Understanding Appeals

Appeal Type

Issues Detected

Reviewing an Appeal

Maintaining Appeals

Appeal Query

Appeal Portal

Appeal - Main

Appeal - Log

Creating Appeal Reviews

Review

Understanding Reviews

Review Types and Review Process Controls

Navigating to a Review

Maintaining Reviews

Review Portal

Review - Main

Review - Log

Pay Plans

The Big Picture Of Pay Plans

Pay Plans Are Obligations

Which Obligations Are Covered By A Pay Plan?

Recommending Scheduled Payments

Maintaining Pay Plans

Pay Plan - Main

Pay Plan - History

Pay Plan - Characteristics

How To

How To Create A Pay Plan

How To Activate A Pay Plan

How To Break Pay Plans

How To Cancel Pay Plans

How To Set Up Automatic Payment For A Pay Plan

Suppression

Understanding Suppressions

Suppression Type

Releasing a Suppression

Maintaining Suppressions

Suppression Query

Suppression Portal

Suppression - Main

Suppression - Log

Work Management

Process Flows

Background Topics

Process Flow Type

Log Information

Process Flow Monitor

C1-PFLM- Process Flow Monitor (Periodic)

Maintaining Process Flows

Process Flow Query

Process Flow Portal

Process Flow - Main

Process Flow - Log

Entity Correction

Background Topics

Common Entity Correction Functionality

Additional Information Required

Use Cases

Maintaining Entity Corrections

Entity Correction Query

Entity Correction Portal

Entity Correction - Main Information

Entity Correction - Log

Common Entity Correction Procedures

Case Management

Background Topics

Case Type

Creating Cases

Log Information

Alerts

ToDo's and Cases

Maintaining Cases

Case - Main

Case - Case Portal

Case - Log

Overdue Financial Obligations

Overdue Processing Background Information

Overdue Process Maintenance

Overdue Process - Main

Overdue Process - Events

Overdue Process - Log

Maintaining Collection Cases

Collection Case Query

Collection Case Portal

Collection Case Actions

Collection Case

Collection Case Log

Collection Case Overdue Processes

How To Perform Common Overdue Process Functions

How To Create An Overdue Process

How To Change Overdue Events

How To Cancel An Overdue Process

Collection Referral

Overdue Control

Overdue Control Overview

Maintaining Overdue Controls

Overdue Control Query

Overdue Control Portal

Overdue Control - Main

Overdue Control - Log

Common Overdue Control Procedures

Billing

The Big Picture of Billing

An Illustration Of A Simple Bill

A High Level Overview Of The Bill Creation Process

Bill Errors

Bill Segment Errors

Bill Completion Errors

Cancel / Rebill Incorrect Bill Segments

How Rates Affect The Information On Bill Segments

Bill Frequency - Bill Cycle vs Bill Segment Duration

Ways To Control The Start Date Of A Bill Segment

Ways To Control The End Date Of A Bill Segment

Using The Bill Period Schedule Method

Using The Anniversary Method

Using Billable Charges

Preventing Short Bill Segments

Prorating Charges When a Rate is Applied

Batch Billing

Window Billing And The Bill Cycle Schedule

Confirming A Batch Of Bills Before Completing Them

Canceling A Batch Of Bills After They're Complete

Reopening A Batch Of Bills After They're Complete

Fixing Errors Detected In Batch Billing

Completing Pending Bills

Billing Financial Transaction Considerations

Billing - Current Balance versus Payoff Balance

When Current Balance Equals Payoff Balance

When Current Balance Differs From Payoff Balance

Bill Segment Type Controls Which Balance(s) Are Affected

The Source Of GL Accounts On A Bill Segment's Financial Transaction

The Source Of Bill Routing Information

Bill Messages

The Source Of Bill Messages

Substituting Field Values Into A Message

A Bill May Affect More Than Just Taxpayer Balances

FT Freeze Repercussions

Using Billable Charges for Pass Through / Convergent Billing

Printing Bills

Bill Routings Are Created For Each Recipient Of A Bill

Bill Route Types Control The Information Merged Onto Bills

Technical Implementation Of Online Bill Images

Technical Implementation Of Printing Bills In Batch

Reproducing The Bill Print Flat File

How To Reprint A Specific Bill

Who Gets A Copy Of A Bill?

Final Bills and Bill Print

Idiosyncratic Manual Bill Cancellation

Maintaining Bills

Bill Lifecycle

Bill - Main Information

Generate

Freeze

Cancel Frozen

Freeze / Complete

Complete

Delete

Reopen

Cancel Bill

Bill - Bill Segments

Generate (Bill - Bill Segments)

Freeze (Bill - Bill Segments)

Delete (Bill - Bill Segments)

Cancel/Rebill/Freeze (Bill - Bill Segments)

Cancel (Bill - Bill Segments)

Bill - Bill Routings

Bill - Bill Messages

Bill - Characteristics

How To

How To Create A Bill For All Obligations Linked To An Account

How To Create A Bill For A Specific Obligation

How To Create a Bill with no Bill Segments

How To Create An Ad-hoc Bill

How To Correct A Bill Segment That's In Error

How To Correct A Bill That's In Error

How To Cancel A Bill Segment

How To Cancel / Rebill A Bill Segment

How To Remove Unwanted Adjustments (or Payments) From A Completed Bill

How To Add An Adjustment (or Payment) To A Completed Bill

How To Reprint A Bill (For The Original Recipients or For Someone New)

How To Add Ad Hoc Messages To A Bill

How To Remove A Completed Bill

How To Display A Bill On-line

Financial Transactions On A Bill

Maintaining Bill Segments

Bill Segment Lifecycle

Bill Segment - Main Information

Generate (Bill Segment)

Delete (Bill Segment)

Freeze (Bill Segment)

Rebill (Bill Segment)

Init Cancel (Bill Segment)

Undo (Bill Segment)

Cancel (Bill Segment)

Bill Segment - RQ Details

Bill Segment - Calc Lines

Bill Segment - Financial Details

Bill Segment - Bill Segment Messages

Multi Cancel/Rebill

Multi Cancel/Rebill - Main

Multi Cancel/Rebill - Graph

Obligation Billing History

Bill Exception

Bill Segment Exception

Maintaining Billable Charges

Billable Charge - Main

Billable Charge - Line Characteristics

Billable Charge - RQ Details

Billable Charge - Calculation Details

Uploading Billable Charges

Billable Charge Upload Background Processes

Process X - Populate BC Upload Staging

Billable Charge Upload Staging Layout

Billable Charge Line Upload Staging Layout

Billable Charge Line Characteristic Upload Staging Layout

Billable Charge Rate Quantity Upload Staging Layout

Billable Charge Calculation Details Upload Staging Layout

BCU1 - Validate & Populate Billable Charge Upload Staging

BCU2 - Create Billable Charge

BCUP-PRG - Purge Billable Charge Upload Objects

Billable Charge Upload Staging

Billable Charge Upload - Main

Billable Charge Upload - Lines

Billable Charge Upload - RQ Details

Billable Charge Upload - Calculation Details

Billable Charge Upload Exception

To Do Processing

The Big Picture of To Do Processing

To Do Role

To Do Priority

Work Distribution

A User's Current To Do

Related To Do Entries

Complete A To Do

Managing To Do Entries

To Do Supervisor Functions

Supervisor To Do Summary

Supervisor User Summary

Supervisor To Do Assignment

To Do List Functions

To Do Summary

To Do List

To Do Entry

To Do Entry - Add Dialog

To Do Entry - Main

To Do Entry - Keys/Values

To Do Entry Actions

Complete

Forward

Send Back

Log Entry Events

To Do Search

To Do Search - Main

To Do Search Actions

Assign Selected Entries

Reopen Selected Entries

Complete Selected Entries

How To

How To Assign a To Do to a User

How To Work on To Do Entries

How To Add a New To Do

How To Complete To Dos

How To Forward a To Do

How To Send Back a To Do

How To Add a Log Entry to a To Do

Reports

On-line Report Submission

Report Submission - Main

Viewing Historic Reports

Report History - Main